Stop ondsindede pakker, før de når produktion

En udvikler kan bringe ondsindet kode ind i et projekt uden at skrive en eneste mistænkelig linje. At installere en pakke kan være nok. Afhængigheden kan se legitim ud, have et velkendt navn og alligevel køre uønsket kode under installationen.

Det gør pakkesikkerhed til et problem længe før en applikation når produktion. Den første risikable handling kan ske på en udviklers Windows-arbejdsstation, inde i en CI-runner eller under et automatiseret build. Kontroller, der kun placeres tæt på udrulning, efterlader en stor del af den vej eksponeret.

Risikoen starter på udviklermaskinen

Moderne projekter trækker store afhængighedstræer ind. En udvikler installerer måske bevidst ti pakker, mens pakkemanageren henter hundredvis af transitive afhængigheder bag om dem. De færreste inspicerer hver pakke i den kæde, og at gøre det manuelt ville gøre normal udvikling smerteligt langsom.

Angribere udnytter den tillid. Nogle ondsindede pakker forsøger at stjæle miljøvariabler, legitimationsoplysninger, browserdata eller autentificeringstokens. Andre downloader endnu en payload eller udfører kode via installationsscripts, før udvikleren overhovedet åbner pakken.

På Windows kan det berørte miljø omfatte PowerShell-sessioner, legitimationsoplysninger til pakkemanageren, SSH-nøgler, cloudværktøjer og filer, der er tilgængelige for den aktuelle brugerkonto. WSL føjer endnu et udviklingsmiljø til den samme maskine i stedet for at fjerne den underliggende forsyningskæderisiko.

En dårlig afhængighed ser ikke altid dårlig ud

Pakkeangreb er sværere at få øje på, når den ondsindede komponent ligner noget, udviklere allerede forventer at se. Indgangspunkterne varierer:

• Typosquatting: En pakke bruger et navn, der adskiller sig fra en populær afhængighed med et tegn eller to;
• Dependency confusion: En offentlig pakke kolliderer med en intern afhængighed og kan blive valgt af et automatiseret build;
• Kompromitterede vedligeholderkonti: En betroet pakke modtager en ondsindet udgivelse, efter at en angriber har fået udgivelsesadgang;
• Ondsindede opdateringer: Et tidligere harmløst projekt ændrer adfærd i en senere version;
• Skjulte transitive afhængigheder: Farlig kode kommer flere niveauer under den pakke, en udvikler valgte.

Popularitet er ikke en sikkerhedsgaranti. Et kompromitteret projekt kan arve årevis af omdømme fra tidligere rene udgivelser, mens en ny ondsindet pakke kan akkumulere downloads, før mistænkelig adfærd bliver bemærket.

At scanne senere kan være for sent

Mange teams scanner allerede afhængigheder, og de kontroller betyder stadig noget. Software composition analysis kan identificere kendte sårbarheder. Repository-scannere kan markere eksponerede hemmeligheder eller risikabel kode. CI-sikkerhedskontroller kan forhindre, at et problematisk build bliver rullet ud.

Timing ændrer, hvad disse kontroller kan forhindre.

Hvis en udvikler kører en installationskommando i Windows Terminal og den anmodede pakke indeholder et ondsindet installationsscript, kan koden blive udført lokalt, før den første seriøse CI-kontrol finder sted. Et rent produktionsmiljø gør ikke tyveri af legitimationsoplysninger på den maskine, hvor bygningen startede, ugjort.

Scanning for kendte sårbarheder besvarer også et andet spørgsmål. Den er god til at finde versioner, der er forbundet med kendte sikkerhedsproblemer, men en nyudgivet ondsindet pakke har måske endnu ikke en CVE eller en etableret sårbarhedsregistrering.

Kontrol af pakker, før de får lov at komme igennem

Én tilgang er at placere en kontrol mellem udvikleren eller byggesystemet og pakkeregistret. I stedet for at lade hver anmodet pakke komme direkte ind i miljøet, evaluerer kontrollen den først og kan blokere software, der opfylder mistænkelige kriterier.

Dette er den grundlæggende idé bag en afhængighedsfirewall.

Det nyttige er, hvor beslutningen træffes. En pakke kan evalueres før installation i stedet for at blive opdaget som et problem, efter at den allerede er kommet ind i miljøet. Signaler kan omfatte mistænkelige udgivelsesmønstre, nyoprettede pakker, der imiterer etablerede pakker, eller anden adfærd, der fortjener ekstra granskning.

Det gør ikke kontrollen ufejlbarlig. Falske positiver betyder også noget. Nyudgivne pakker kan være legitime, og usædvanlig udgivelsesaktivitet er ikke automatisk ondsindet. Hvis pakkekontroller konstant afbryder legitime opdateringer, kan udviklere begynde at lede efter måder at omgå dem på.

Windows-udvikling tilføjer sin egen eksponering

Windows-udviklingsopsætninger kombinerer ofte Git, Node.js, Python, PowerShell, Visual Studio Code, Docker Desktop, WSL, cloud-CLI’er og lokalt gemte legitimationsoplysninger på én arbejdsstation. Det gør kontotilladelser og lokal sikkerhed relevante for pakkerisiko.

Nogle få almindelige valg reducerer den tilgængelige angrebsflade:

• Hold rutinemæssig udvikling under ikke-administratorkonti, hvor det er muligt;
• Undgå at køre ukendte installationskommandoer med forhøjede PowerShell-rettigheder;
• Adskil produktionslegitimationsoplysninger fra lokale udviklerlegitimationsoplysninger;
• Gennemgå pakker, der pludselig indfører installations- eller postinstallationsscripts;
• Brug isolerede miljøer til software, der endnu ikke har opnået tillid.

Windows-sikkerhedsfunktioner kan hjælpe på operativsystemlaget, men de kan ikke afgøre, om hver tredjepartspakke i et afhængighedstræ hører hjemme i et bestemt projekt.

Lockfiler hjælper, men de kan ikke afgøre, hvad der er sikkert

Lockfiler gør pakkeversioner mere forudsigelige og reducerer uventede ændringer mellem installationer. De besvarer ikke, om den låste version i sig selv er ondsindet.

Den samme begrænsning gælder for andre kontroller, når de bruges alene. Versionsfastlåsning giver konsistens. Kodegennemgang fanger ændringer, udviklere faktisk kan se. Sårbarhedsscanning finder kendte svagheder. Endpointbeskyttelse overvåger aktivitet på maskinen.

Teams kan også kræve MFA for at udgive interne pakker, fjerne forladte afhængigheder, overvåge ændringer i lockfiler, begrænse unødvendige installationsscripts og undersøge pludselige ejerskabsændringer i kritiske tredjepartsprojekter.

Den stærkere tilgang er lagdelt. Ingen enkelt kontrol dækker hele vejen fra pakkeregister til udviklermaskine, byggesystem og produktionsmiljø.

Stop pakken på det tidligste nyttige tidspunkt

Produktionssikkerhed starter før produktion. Når en ondsindet afhængighed dukker op i et udrullet build, kan den allerede have passeret gennem udviklerlaptops, pakkecaches, byggesystemer og CI-infrastruktur.

At flytte pakkekontroller tættere på installationen reducerer det vindue uden at fjerne behovet for senere scanning. For Windows-baserede teams betyder beskyttelse af arbejdsstationen noget, fordi udviklingsmaskiner ofte befinder sig tæt på kildekode, legitimationsoplysninger, cloudværktøjer og interne systemer.

Det praktiske spørgsmål er ikke, om ét værktøj kan garantere, at hver pakke er sikker. Det er, hvor tidligt udviklingsprocessen kan afvise en pakke, der aldrig burde have fået lov til at køre.