Teknologi

Slik sniker skadelig kode seg inn i programvaren du stoler på via forsyningskjeden

Susan Hill

Et angrep på forsyningskjeden bryter seg ikke inn i programvaren du bruker. Det forgifter en av delene programvaren er bygd av, og venter så på at den vanlige oppdateringsprosessen skal bære den inn på maskinen din. Appen installeres feilfritt, signaturen stemmer fortsatt, og oppdateringen kommer via den offisielle kanalen. Den skadelige koden blir med på lasset. Det er nettopp denne snuoperasjonen som gjør teknikken så effektiv: den gjør tilliten som får programvare til å virke, om til punktet som blir utnyttet.

Nesten ingenting av det du kjører i dag, er skrevet i sin helhet av selskapet hvis navn står på det. En enkelt app kan dra med seg hundrevis eller tusenvis av åpne pakker, hver vedlikeholdt av fremmede og hver med flere pakker bak seg. Utviklere leser sjelden den koden; de stoler på registeret den kom fra, og versjonsnummeret som følger med. Den som sniker seg inn i et hvilket som helst ledd i kjeden, når på én gang alle nedstrøms, og derfor kan én enkelt forgiftet komponent ramme titusenvis av prosjekter før noen oppdager det.

Inngangene samler seg i noen få mønstre. Typosquatting plasserer en skadelig pakke med et navn ett tastetrykk fra det populære og venter på skrivefeilen. Avhengighetsforvirring utnytter hvordan byggeverktøy slår opp navn, og lurer dem til å hente en offentlig pakke i stedet for selskapets private. Kontokapring overtar en ekte vedlikeholders innloggingsdetaljer og sprer skadevare som en rutineoppdatering; tidlig i 2026 publiserte den vidt utbredte pakken axios en kort stund en kompromittert versjon etter at maskinen til hovedvedlikeholderen var brutt via sosial manipulasjon. Og forgiftning av byggekjeden retter seg mot de automatiske systemene som setter sammen og slipper programvaren, der ett enkelt korrupt steg når hvert prosjekt som er avhengig av det.

Byggekjeden har blitt det mest ettertraktede målet nettopp fordi den ligger oppstrøms alt annet. Da den populære GitHub Actions-komponenten tj-actions/changed-files ble kompromittert i 2025, skrev angriperne om versjonsetikettene dens slik at de pekte på skadelig kode, og hentet ut hemmeligheter fra byggeloggene til mer enn tjue tusen kodelagre: tilgangsnøkler, tokens og private nøkler, alt i klartekst. En senere kampanje, som forskere kalte Megalodon, gjorde GitHub Actions om til en selvspredende bakdør som nådde 5561 kodelagre på rundt seks timer. Maskinen som bygger programvaren din, kan undergraves like lett som programvaren selv.

Verktøyene utviklere bruker hver dag, ligger også innenfor virkeområdet. GlassWorm, som ble funnet første gang sent i 2025, spredte seg via utvidelser til Visual Studio Code i markedsplassene OpenVSX og Microsoft. Den skjulte lasten sin med usynlige Unicode-tegn, slik at de skadelige linjene bokstavelig talt var uleselige i editoren og slapp forbi den menneskelige gjennomgangen. Vel installert stjal den innloggingsdetaljer til npm, GitHub og Git og brukte dem til automatisk å smitte flere pakker og utvidelser, trekket som definerer en orm. Fordi editorer oppdaterer utvidelser stille i bakgrunnen, fikk ofrene de forgiftede versjonene uten å klikke på noe. En annen forgiftet VS Code-utvidelse ble brukt til å stjele rundt 3800 av GitHubs egne interne kodelagre.

Det som gjør disse angrepene så vanskelige å fange, er at hvert enkelt steg ser legitimt ut. Pakken er signert. Oppdateringen kommer fra det ekte registeret. Vedlikeholderkontoen er ekte. Tradisjonelle forsvar leter etter filer som allerede er kjent som skadelige, og åpenbar skadevare, men angrep på forsyningskjeden gjemmer seg i betrodd, forventet og ofte usynlig kode som ankommer akkurat når og hvordan programvare skal ankomme. Verre ennå: det gamle sikkerhetsrådet om å oppdatere med en gang er nettopp mekanismen angriperen regner med. For første gang er det ikke lenger entydig trygt å installere den nyeste versjonen.

Forsvarerne har samlet seg om en håndfull metoder som virker. Låsefiler fester hver avhengighet til en nøyaktig, verifisert versjon, slik at en installerer bare henter det som er gjennomgått, framfor rett og slett det nyeste. Å slå av automatiske installasjonsskript kutter den vanligste veien der en skadelig pakke kjører kode i det øyeblikket den lander. Å feste GitHub Actions til en bestemt commit-hash i stedet for en bevegelig etikett, gjør trikset med å skrive om etiketter virkningsløst. En programvarefortegnelse, en detaljert liste over hver komponent i et bygg, lar et team innen minutter vite om det er utsatt når neste hendelse blir avslørt. Mange av organisasjonene som slapp unna de siste angrepene, gjorde ingenting eksotisk: de bygde fra en innsjekket låsefil og arbeidet bak en registerproxy som satte nypubliserte pakker i karantene.

For folk som ikke skriver kode, er beskyttelsen for det meste indirekte, men lærdommen er det ikke. Programvarens forsyningskjede er i dag en slagmark i front, og det er selskapene som bygger appene på telefonen og laptopen din, som må sikre den. Det fornuftige svaret er verken panikk eller den gamle refleksen om å oppdatere alt så snart et varsel dukker opp. Det er å foretrekke programvare fra team som offentliggjør hva de leverer og hvordan de bygger det, og å behandle en betrodd kilde som noe som må fortjenes ved hvert ledd, snarere enn en egenskap som glir nedover kjeden av seg selv.

Bransjens svar tar form rundt proveniens: et kryptografisk bevis for hvor en kodebit kommer fra og hvordan den ble bygd, kontrollert automatisk før noe som helst installeres. Det er den samme ideen som sikret nettrafikken for en generasjon siden, nå brukt på programvarens eget samlebånd. Inntil det beviset er allment, forblir hver installasjon en tillitshandling overfor mennesker du aldri kommer til å møte.

Diskusjon

Det er 0 kommentarer.