Stanser ondsinnede pakker før de når produksjon

En utvikler kan få ondsinnet kode inn i et prosjekt uten å skrive en eneste mistenkelig linje. Å installere en pakke kan være nok. Avhengigheten kan se legitim ut, ha et kjent navn og likevel kjøre uønsket kode under installasjon.

Det gjør pakkesikkerhet til et problem lenge før en applikasjon når produksjon. Den første risikofylte handlingen kan skje på en utviklers Windows-arbeidsstasjon, i en CI-runner eller under et automatisert bygg. Kontroller som bare er plassert nær distribusjon, etterlater mye av den veien eksponert.

Risikoen starter på utviklermaskinen

Moderne prosjekter henter inn store avhengighetstrær. En utvikler kan bevisst installere ti pakker mens pakkebehandleren henter hundrevis av transitive avhengigheter i bakgrunnen. Få personer inspiserer hver pakke i den kjeden, og å gjøre det manuelt ville gjort normal utvikling smertefullt treg.

Angripere utnytter den tilliten. Noen ondsinnede pakker prøver å stjele miljøvariabler, påloggingsinformasjon, nettleserdata eller autentiseringstokener. Andre laster ned en annen nyttelast eller kjører kode gjennom installasjonsskript før utvikleren i det hele tatt åpner pakken.

På Windows kan det berørte miljøet omfatte PowerShell-økter, påloggingsinformasjon for pakkebehandleren, SSH-nøkler, skyverktøy og filer som er tilgjengelige for gjeldende brukerkonto. WSL legger til et annet utviklingsmiljø på samme maskin i stedet for å fjerne den underliggende risikoen i leverandørkjeden.

En dårlig avhengighet ser ikke alltid dårlig ut

Pakkeangrep er vanskeligere å oppdage når den ondsinnede komponenten ligner noe utviklere allerede forventer å se. Inngangspunktene varierer:

• Typosquatting: En pakke bruker et navn som skiller seg fra en populær avhengighet med ett eller to tegn;
• Avhengighetsforvirring: En offentlig pakke kolliderer med en intern avhengighet og kan bli valgt av et automatisert bygg;
• Kompromitterte vedlikeholderkontoer: En tiltrodd pakke får en ondsinnet utgivelse etter at en angriper har fått publiseringstilgang;
• Ondsinnede oppdateringer: Et tidligere harmløst prosjekt endrer atferd i en senere versjon;
• Skjulte transitive avhengigheter: Farlig kode kommer inn flere nivåer under pakken utvikleren valgte.

Popularitet er ingen sikkerhetsgaranti. Et kompromittert prosjekt kan arve årevis med omdømme fra tidligere rene utgivelser, mens en ny ondsinnet pakke kan samle nedlastinger før mistenkelig atferd blir lagt merke til.

Å skanne senere kan være for sent

Mange team skanner allerede avhengigheter, og disse kontrollene betyr fortsatt noe. Analyse av programvaresammensetning kan identifisere kjente sårbarheter. Repository-skannere kan flagge eksponerte hemmeligheter eller risikabel kode. CI-sikkerhetskontroller kan hindre at et problematisk bygg blir distribuert.

Tidspunktet endrer hva disse kontrollene kan forhindre.

Hvis en utvikler kjører en installasjonskommando i Windows Terminal og den forespurte pakken inneholder et ondsinnet installasjonsskript, kan koden kjøres lokalt før den første alvorlige CI-kontrollen skjer. Et rent produksjonsmiljø opphever ikke tyveri av påloggingsinformasjon på maskinen der bygget startet.

Skanning etter kjente sårbarheter svarer også på et annet spørsmål. Den er god til å finne versjoner som er knyttet til kjente sikkerhetsproblemer, men en nylig publisert ondsinnet pakke har kanskje ennå ikke noen CVE eller etablert sårbarhetsregistrering.

Kontrollere pakker før de slippes gjennom

Én tilnærming er å plassere en kontroll mellom utvikleren eller byggesystemet og pakkeregisteret. I stedet for å slippe hver forespurt pakke direkte inn i miljøet, vurderer kontrollen den først og kan blokkere programvare som oppfyller mistenkelige kriterier.

Dette er grunntanken bak en avhengighetsbrannmur.

Det nyttige er hvor beslutningen skjer. En pakke kan vurderes før installasjon i stedet for å bli oppdaget som et problem etter at den allerede har kommet inn i miljøet. Signaler kan omfatte mistenkelige publiseringsmønstre, nyopprettede pakker som imiterer etablerte pakker, eller annen atferd som fortjener ekstra gransking.

Det gjør ikke kontrollen ufeilbarlig. Falske positive har også betydning. Nyutgitte pakker kan være legitime, og uvanlig publiseringsaktivitet er ikke automatisk ondsinnet. Hvis pakkekontroller stadig avbryter legitime oppdateringer, kan utviklere begynne å se etter måter å omgå dem på.

Windows-utvikling gir sin egen eksponering

Windows-utviklingsmiljøer kombinerer ofte Git, Node.js, Python, PowerShell, Visual Studio Code, Docker Desktop, WSL, sky-CLI-er og lokalt lagret påloggingsinformasjon på én arbeidsstasjon. Det gjør kontotillatelser og lokal sikkerhet relevante for pakkerisiko.

Noen få vanlige valg reduserer den tilgjengelige angrepsflaten:

• Utfør rutinemessig utvikling under ikke-administratorkontoer der det er mulig;
• Unngå å kjøre ukjente installasjonskommandoer med utvidede PowerShell-rettigheter;
• Hold produksjonspåloggingsinformasjon atskilt fra lokal utviklerpåloggingsinformasjon;
• Gjennomgå pakker som plutselig innfører installasjons- eller etterinstallasjonsskript;
• Bruk isolerte miljøer for programvare som ennå ikke har opparbeidet tillit.

Windows-sikkerhetsfunksjoner kan hjelpe på operativsystemnivået, men de kan ikke avgjøre om hver tredjepartspakke i et avhengighetstre hører hjemme i et bestemt prosjekt.

Låsefiler hjelper, men de kan ikke avgjøre hva som er trygt

Låsefiler gjør pakkeversjoner mer forutsigbare og reduserer uventede endringer mellom installasjoner. De svarer ikke på om den låste versjonen i seg selv er ondsinnet.

Den samme begrensningen gjelder for andre kontroller når de brukes alene. Versjonslåsing gir konsistens. Kodegjennomgang fanger opp endringer utviklere faktisk kan se. Sårbarhetsskanning finner kjente svakheter. Endepunktbeskyttelse overvåker aktivitet på maskinen.

Team kan også kreve MFA for publisering av interne pakker, fjerne forlatte avhengigheter, overvåke låsefilendringer, begrense unødvendige installasjonsskript og undersøke plutselige eierskifter i kritiske tredjepartsprosjekter.

Den sterkere tilnærmingen er lagdelt. Ingen enkeltkontroll dekker hele veien fra pakkeregister til utviklermaskin, byggesystem og produksjonsmiljø.

Stopp pakken på det tidligste nyttige punktet

Produksjonssikkerhet starter før produksjon. Innen en ondsinnet avhengighet vises i et distribuert bygg, kan den allerede ha passert gjennom utviklerlaptoper, pakkecacher, byggesystemer og CI-infrastruktur.

Å flytte pakkekontroller nærmere installasjon reduserer det vinduet uten å eliminere behovet for senere skanning. For Windows-baserte team er det viktig å beskytte arbeidsstasjonen fordi utviklingsmaskiner ofte befinner seg nær kildekode, påloggingsinformasjon, skyverktøy og interne systemer.

Det praktiske spørsmålet er ikke om ett verktøy kan garantere at hver pakke er trygg. Det er hvor tidlig utviklingsprosessen kan avvise en pakke som aldri burde ha fått lov til å kjøre.