Kwaadaardige pakketten stoppen voordat ze de productie bereiken

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

Daardoor wordt pakketbeveiliging al een probleem lang voordat een applicatie productie bereikt. De eerste risicovolle actie kan plaatsvinden op een Windows-werkstation van een ontwikkelaar, binnen een CI-runner of tijdens een geautomatiseerde build. Controles die alleen vlak voor deployment worden uitgevoerd, laten een groot deel van dat pad onbeschermd.

Het risico begint op de machine van de ontwikkelaar

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

Aanvallers misbruiken dat vertrouwen. 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 in plaats van het onderliggende supplychainrisico weg te nemen.

Een slechte afhankelijkheid ziet er niet altijd slecht uit

Pakketaanvallen zijn moeilijker te herkennen wanneer de kwaadaardige component lijkt op iets wat ontwikkelaars al verwachten te zien. De ingangen variëren:

• Typosquatting: Een pakket gebruikt een naam die één of twee tekens verschilt 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 publicatierechten heeft verkregen;
• Kwaadaardige updates: Een voorheen onschadelijk project vertoont in een latere versie ander gedrag;
• Verborgen transitieve afhankelijkheden: Gevaarlijke code komt enkele niveaus onder het door de ontwikkelaar geselecteerde pakket binnen.

Populariteit is geen veiligheidsgarantie. Een gecompromitteerd project kan jarenlange 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 blijven belangrijk. Software composition analysis kan bekende kwetsbaarheden identificeren. Repositoryscanners kunnen blootgestelde geheimen of risicovolle code markeren. Beveiligingscontroles in CI kunnen voorkomen dat een problematische build wordt uitgerold.

Timing verandert wat die controles kunnen voorkomen.

Als een ontwikkelaar in Windows Terminal een installatieopdracht uitvoert 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 referenties op de machine waar de build begon niet ongedaan.

Scannen op bekende kwetsbaarheden beantwoordt ook een andere vraag. Het is sterk in het vinden van versies die verband houden met bekende beveiligingsproblemen, maar een nieuw gepubliceerd kwaadaardig pakket heeft mogelijk nog geen CVE of vastgelegd kwetsbaarheidsdossier.

Pakketten controleren voordat ze worden doorgelaten

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 het software blokkeren 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 als probleem te worden ontdekt nadat het de omgeving al is binnengekomen. Signalen kunnen verdachte publicatiepatronen omvatten, nieuw aangemaakte pakketten die bestaande pakketten imiteren, of ander gedrag dat extra controle verdient.

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

Windows-ontwikkeling zorgt voor extra blootstelling

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

Een paar eenvoudige keuzes verkleinen het beschikbare aanvalsoppervlak:

• Houd routinematige ontwikkeling waar mogelijk onder accounts zonder beheerdersrechten;
• Vermijd het uitvoeren van onbekende installatieopdrachten met verhoogde PowerShell-bevoegdheden;
• Scheid productiereferenties van lokale ontwikkelaarsreferenties;
• Controleer 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 beslissen 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. Codereviews vangen wijzigingen die ontwikkelaars daadwerkelijk kunnen zien. Scans op kwetsbaarheden vinden bekende zwakke plekken. Endpointbeveiliging bewaakt de activiteit op de machine.

Teams kunnen ook MFA verplicht stellen voor het publiceren van interne pakketten, niet-onderhouden afhankelijkheden verwijderen, wijzigingen in lockfiles bewaken, onnodige installatiescripts beperken en plotselinge eigendomswijzigingen 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 uitgerolde build verschijnt, kan die al door laptops van ontwikkelaars, 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 het beschermen van het werkstation belangrijk, omdat ontwikkelmachines zich vaak dicht bij broncode, referenties, cloudtools en interne systemen bevinden.

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