Stoppa skadliga paket innan de når produktion

En utvecklare kan föra in skadlig kod i ett projekt utan att skriva en enda misstänkt rad. Att installera ett paket kan räcka. Beroendet kan se legitimt ut, ha ett välbekant namn och ändå köra oönskad kod under installationen.

Det gör paketsäkerhet till ett problem långt innan en applikation når produktion. Den första riskabla åtgärden kan inträffa på en utvecklares Windows-arbetsstation, i en CI-runner eller under ett automatiserat bygge. Kontroller som placeras först i närheten av driftsättning lämnar stora delar av den vägen exponerade.

Risken börjar på utvecklarens maskin

Moderna projekt drar in stora beroendeträd. En utvecklare kan medvetet installera tio paket medan pakethanteraren hämtar hundratals transitiva beroenden bakom dem. Få personer inspekterar varje paket i den kedjan, och att göra det manuellt skulle göra normal utveckling plågsamt långsam.

Angripare utnyttjar det förtroendet. En del skadliga paket försöker stjäla miljövariabler, autentiseringsuppgifter, webbläsardata eller autentiseringstoken. Andra laddar ned ytterligare en nyttolast eller kör kod via installationsskript innan utvecklaren ens öppnar paketet.

På Windows kan den drabbade miljön omfatta PowerShell-sessioner, autentiseringsuppgifter för pakethanterare, SSH-nycklar, molnverktyg och filer som är tillgängliga för det aktuella användarkontot. WSL lägger till ytterligare en utvecklingsmiljö på samma maskin snarare än tar bort den underliggande risken i leveranskedjan.

Ett dåligt beroende ser inte alltid dåligt ut

Paketattacker är svårare att upptäcka när den skadliga komponenten liknar något som utvecklare redan förväntar sig att se. Ingångarna varierar:

• Typosquatting: Ett paket använder ett namn som skiljer sig från ett populärt beroende med ett eller två tecken;
• Dependency confusion: Ett publikt paket kolliderar med ett internt beroende och kan väljas av ett automatiserat bygge;
• Komprometterade underhållarkonton: Ett betrott paket får en skadlig version efter att en angripare fått publiceringsåtkomst;
• Skadliga uppdateringar: Ett tidigare ofarligt projekt ändrar beteende i en senare version;
• Dolda transitiva beroenden: Farlig kod kommer in flera nivåer under det paket som en utvecklare valde.

Popularitet är ingen säkerhetsgaranti. Ett komprometterat projekt kan ärva flera års rykte från tidigare rena versioner, medan ett nytt skadligt paket kan samla på sig nedladdningar innan misstänkt beteende upptäcks.

Att skanna senare kan vara för sent

Många team skannar redan beroenden, och dessa kontroller har fortfarande betydelse. Analys av programvarusammansättning kan identifiera kända sårbarheter. Reposkannrar kan flagga exponerade hemligheter eller riskabel kod. CI-säkerhetskontroller kan stoppa ett problematiskt bygge från att driftsättas.

Tidpunkten förändrar vad dessa kontroller kan förhindra.

Om en utvecklare kör ett installationskommando i Windows Terminal och det begärda paketet innehåller ett skadligt installationsskript kan koden köras lokalt innan den första allvarliga CI-kontrollen sker. En ren produktionsmiljö ångrar inte stöld av autentiseringsuppgifter på den maskin där bygget började.

Skanning efter kända sårbarheter besvarar också en annan fråga. Den är bra på att hitta versioner som är förknippade med kända säkerhetsproblem, men ett nyligen publicerat skadligt paket kanske ännu inte har en CVE eller etablerad sårbarhetspost.

Kontrollera paket innan de släpps igenom

Ett tillvägagångssätt är att placera en kontroll mellan utvecklaren eller byggsystemet och paketregistret. I stället för att låta varje begärt paket nå miljön direkt utvärderar kontrollen det först och kan blockera programvara som uppfyller misstänkta kriterier.

Detta är grundidén bakom en beroendebrandvägg.

Den användbara delen är var beslutet fattas. Ett paket kan utvärderas före installation i stället för att upptäckas som ett problem efter att det redan har kommit in i miljön. Signalerna kan omfatta misstänkta publiceringsmönster, nyskapade paket som imiterar etablerade sådana eller annat beteende som förtjänar extra granskning.

Det gör inte kontrollen ofelbar. Falska positiva resultat spelar också roll. Nyligen publicerade paket kan vara legitima, och ovanlig publiceringsaktivitet är inte automatiskt skadlig. Om paketkontroller ständigt avbryter legitima uppdateringar kan utvecklare börja leta efter sätt att kringgå dem.

Windows-utveckling medför sin egen exponering

Windows-utvecklingsmiljöer kombinerar ofta Git, Node.js, Python, PowerShell, Visual Studio Code, Docker Desktop, WSL, moln-CLI:er och lokalt lagrade autentiseringsuppgifter på en och samma arbetsstation. Det gör kontobehörigheter och lokal säkerhet relevanta för paketrisken.

Ett fåtal vardagliga val minskar den tillgängliga attackytan:

• Håll rutinmässig utveckling under konton utan administratörsbehörighet där det är möjligt;
• Undvik att köra okända installationskommandon med utökade PowerShell-behörigheter;
• Separera produktionsautentiseringsuppgifter från lokala utvecklarautentiseringsuppgifter;
• Granska paket som plötsligt inför installations- eller efterinstallationsskript;
• Använd isolerade miljöer för programvara som ännu inte har förtjänat förtroende.

Windows säkerhetsfunktioner kan hjälpa till på operativsystemsnivå, men de kan inte avgöra om varje tredjepartspaket i ett beroendeträd hör hemma i ett visst projekt.

Låsfiler hjälper, men de kan inte avgöra vad som är säkert

Låsfiler gör paketversioner mer förutsägbara och minskar oväntade förändringar mellan installationer. De besvarar inte om den låsta versionen i sig är skadlig.

Samma begränsning gäller andra kontroller när de används ensamma. Versionslåsning ger konsekvens. Kodgranskning fångar förändringar som utvecklare faktiskt kan se. Sårbarhetsskanning hittar kända svagheter. Slutpunktsskydd övervakar aktivitet på maskinen.

Team kan också kräva MFA för publicering av interna paket, ta bort övergivna beroenden, övervaka ändringar i låsfiler, begränsa onödiga installationsskript och undersöka plötsliga ägarförändringar i kritiska tredjepartsprojekt.

Den starkare metoden är skiktad. Ingen enskild kontroll täcker hela vägen från paketregister till utvecklarmaskin, byggsystem och produktionsmiljö.

Stoppa paketet vid den tidigaste användbara punkten

Produktionssäkerhet börjar före produktion. När ett skadligt beroende dyker upp i ett driftsatt bygge kan det redan ha passerat genom utvecklarbärbara datorer, paketcachar, byggsystem och CI-infrastruktur.

Att flytta paketkontroller närmare installationen minskar det fönstret utan att eliminera behovet av senare skanning. För Windows-baserade team är skyddet av arbetsstationen viktigt eftersom utvecklingsmaskiner ofta befinner sig nära källkod, autentiseringsuppgifter, molnverktyg och interna system.

Den praktiska frågan är inte om ett enda verktyg kan garantera att varje paket är säkert. Det är hur tidigt utvecklingsprocessen kan avvisa ett paket som aldrig borde ha tillåtits att köras.