Malafide pakketten stoppen voordat ze productie bereiken

Een ontwikkelaar kan kwaadaardige code in een project binnenbrengen zonder ook maar één verdachte regel te schrijven. Het installeren van een pakket kan al voldoende zijn. De afhankelijkheid kan er legitiem uitzien, een vertrouwde naam hebben en tijdens de installatie toch ongewenste code uitvoeren.

Daardoor is pakketbeveiliging al een probleem lang voordat een applicatie productie bereikt. De eerste riskante handeling kan plaatsvinden op een Windows-werkstation van een ontwikkelaar, in een CI-runner of tijdens een geautomatiseerde build. Controles die alleen vlak bij de implementatie zijn geplaatst, laten een groot deel van dat pad onbeschermd.

Het risico begint op de ontwikkelmachine

Moderne projecten halen grote afhankelijkheidsbomen binnen. Een ontwikkelaar kan bewust tien pakketten installeren terwijl de pakketbeheerder daarachter honderden transitieve afhankelijkheden ophaalt. Weinig mensen inspecteren elk pakket in die keten, en dat handmatig doen zou normale ontwikkeling pijnlijk traag maken.

Aanvallers buiten dat vertrouwen uit. Sommige kwaadaardige pakketten proberen omgevingsvariabelen, inloggegevens, browsergegevens of authenticatietokens te stelen. Andere downloaden een extra payload of voeren code uit via installatiescripts voordat de ontwikkelaar het pakket überhaupt opent.

Op Windows kan de getroffen omgeving PowerShell-sessies, referenties van de pakketbeheerder, SSH-sleutels, cloudtools en bestanden omvatten die beschikbaar zijn voor het huidige gebruikersaccount. WSL voegt een extra ontwikkelomgeving aan dezelfde machine toe, zonder het onderliggende supplychainrisico weg te nemen.

Een slechte afhankelijkheid ziet er niet altijd slecht uit

Pakketaanvallen zijn moeilijker te herkennen wanneer het kwaadaardige onderdeel lijkt op iets dat ontwikkelaars al verwachten te zien. De toegangspunten variëren:

• Typosquatting: Een pakket gebruikt een naam die één of twee tekens afwijkt van een populaire afhankelijkheid;
• Dependency confusion: Een openbaar pakket botst met een interne afhankelijkheid en kan door een geautomatiseerde build worden geselecteerd;
• Gecompromitteerde onderhoudersaccounts: Een vertrouwd pakket krijgt een kwaadaardige release nadat een aanvaller publicatietoegang heeft verkregen;
• Kwaadaardige updates: Een voorheen onschuldig project verandert in een latere versie van gedrag;
• Verborgen transitieve afhankelijkheden: Gevaarlijke code komt meerdere niveaus onder het pakket terecht dat een ontwikkelaar heeft geselecteerd.

Populariteit is geen veiligheidsgarantie. Een gecompromitteerd project kan jaren aan reputatie erven van eerdere schone releases, terwijl een nieuw kwaadaardig pakket downloads kan verzamelen voordat verdacht gedrag wordt opgemerkt.

Later scannen kan te laat zijn

Veel teams scannen afhankelijkheden al, en die controles doen er nog steeds toe. Software composition analysis kan bekende kwetsbaarheden identificeren. Repositoryscanners kunnen blootgestelde geheimen of riskante code markeren. CI-beveiligingscontroles kunnen voorkomen dat een problematische build wordt geïmplementeerd.

Timing verandert wat die controles kunnen voorkomen.

Als een ontwikkelaar een installatieopdracht uitvoert in Windows Terminal en het aangevraagde pakket een kwaadaardig installatiescript bevat, kan de code lokaal worden uitgevoerd voordat de eerste serieuze CI-controle plaatsvindt. Een schone productieomgeving maakt diefstal van inloggegevens op de machine waar de build begon niet ongedaan.

Scans op bekende kwetsbaarheden beantwoorden bovendien een andere vraag. Ze zijn goed in het vinden van versies die verband houden met bekende beveiligingsproblemen, maar een nieuw gepubliceerd kwaadaardig pakket heeft mogelijk nog geen CVE of vastgelegd kwetsbaarheidsrecord.

Pakketten controleren voordat ze worden toegelaten

Eén aanpak is om een controle te plaatsen tussen de ontwikkelaar of het buildsysteem en het pakketregister. In plaats van elk aangevraagd pakket rechtstreeks in de omgeving toe te laten, beoordeelt de controle het eerst en kan software worden geblokkeerd die aan verdachte criteria voldoet.

Dit is het basisidee achter een dependency firewall.

Het nuttige deel is waar de beslissing plaatsvindt. Een pakket kan vóór de installatie worden beoordeeld, in plaats van pas als probleem te worden ontdekt nadat het de omgeving al is binnengekomen. Signalen kunnen verdachte publicatiepatronen zijn, nieuw aangemaakte pakketten die gevestigde pakketten imiteren, of ander gedrag dat extra controle verdient.

Dat maakt de controle niet onfeilbaar. Valse positieven tellen ook. Nieuw uitgebrachte pakketten kunnen legitiem zijn, en ongebruikelijke publicatieactiviteit is niet automatisch kwaadaardig. Als pakketcontroles legitieme updates voortdurend onderbreken, kunnen ontwikkelaars naar manieren gaan zoeken om ze te omzeilen.

Windows-ontwikkeling zorgt voor eigen blootstelling

Windows-ontwikkelomgevingen combineren vaak Git, Node.js, Python, PowerShell, Visual Studio Code, Docker Desktop, WSL, cloud-CLI’s en lokaal opgeslagen inloggegevens op één werkstation. Daardoor zijn accountmachtigingen en lokale beveiliging relevant voor het pakketrisico.

Een paar eenvoudige keuzes verkleinen het beschikbare aanvalsoppervlak:

• Voer routineontwikkeling waar mogelijk uit onder accounts zonder beheerdersrechten;
• Voer geen onbekende installatieopdrachten uit met verhoogde PowerShell-bevoegdheden;
• Scheid productiereferenties van lokale ontwikkelaarsreferenties;
• Beoordeel pakketten die plotseling installatie- of post-installatiescripts introduceren;
• Gebruik geïsoleerde omgevingen voor software die het vertrouwen nog niet heeft verdiend.

Windows-beveiligingsfuncties kunnen helpen op de laag van het besturingssysteem, maar ze kunnen niet bepalen of elk pakket van derden in een afhankelijkheidsboom in een bepaald project thuishoort.

Lockfiles helpen, maar ze kunnen niet bepalen wat veilig is

Lockfiles maken pakketversies voorspelbaarder en verminderen onverwachte wijzigingen tussen installaties. Ze geven geen antwoord op de vraag of de vastgelegde versie zelf kwaadaardig is.

Dezelfde beperking geldt voor andere controles wanneer ze afzonderlijk worden gebruikt. Versiepinning zorgt voor consistentie. Codereview vangt wijzigingen die ontwikkelaars daadwerkelijk kunnen zien. Scans op kwetsbaarheden vinden bekende zwakheden. Endpointbeveiliging bewaakt activiteit op de machine.

Teams kunnen daarnaast MFA verplicht stellen voor het publiceren van interne pakketten, niet-onderhouden afhankelijkheden verwijderen, wijzigingen in lockfiles monitoren, onnodige installatiescripts beperken en plotselinge eigenaarswijzigingen in kritieke projecten van derden onderzoeken.

De sterkere aanpak is gelaagd. Geen enkele controle dekt het volledige pad van pakketregister naar ontwikkelmachine, buildsysteem en productieomgeving.

Stop het pakket op het vroegst nuttige punt

Productiebeveiliging begint vóór productie. Tegen de tijd dat een kwaadaardige afhankelijkheid in een geïmplementeerde build verschijnt, kan die al door ontwikkellaptops, pakketcaches, buildsystemen en CI-infrastructuur zijn gegaan.

Pakketcontroles dichter bij de installatie plaatsen verkleint dat venster zonder de noodzaak van latere scans weg te nemen. Voor Windows-gebaseerde teams is bescherming van het werkstation belangrijk, omdat ontwikkelmachines vaak dicht bij broncode, inloggegevens, cloudtools en interne systemen staan.

De praktische vraag is niet of één tool kan garanderen dat elk pakket veilig is. Het is hoe vroeg het ontwikkelproces een pakket kan afwijzen dat nooit had mogen worden uitgevoerd.