Shai-Hulud
En selvspredende orm som kjører når en infisert npm-pakke installeres, stjeler npm-, GitHub- og skytokens og publiserer infiserte versjoner av offerets andre pakker. De fleste infeksjonene kjørte i CI.
Slik sjekker du byggene dine →Red team vs. blue team
Leverandørkjedeangrep: slik kommer angripere seg inn, og slik stopper du dem
Angripere går sjelden etter bedriften din. De går etter pakken, Action-en eller byggeverktøyet som bedrifter overalt er avhengige av, og prøver deretter exploiten på alle samtidig. De trenger ikke avhengighetslisten din. Det gjør du.
Hva er et angrep på programvareleverandørkjeden?
Et angrep på programvareleverandørkjeden kompromitterer noe et produkt er bygget av, for eksempel en pakke med åpen kildekode, en CI/CD-komponent eller byggesystemet, i stedet for å angripe produktet direkte. Moderne programvare er for det meste andre folks kode: Det meste kommer fra pakker med åpen kildekode, og de fleste av dem er transitive avhengigheter som ingen i teamet har valgt. Kompromitter én mye brukt komponent, så når du hver organisasjon som bygger på den.
Det endrer hvordan angripere velger mål. De undersøker ikke avhengighetene til én bedrift. De velger en pakke eller et verktøy med stor utbredelse, utnytter det overalt og ser hva som svarer.
Typer angrep på programvareleverandørkjeden
Utnyttelse av en sårbar avhengighet
En feil i en populær pakke med åpen kildekode blir offentliggjort, og angripere utnytter den i hvert produkt som leverer den sårbare versjonen, vanligvis som en transitiv avhengighet ingen valgte direkte.
Ondsinnede pakkeutgivelser
En angriper overtar en vedlikeholderkonto, eller en orm stjeler publiseringstokens, og gir ut en forgiftet versjon av en betrodd pakke. Den kjører i det øyeblikket et bygg installerer den, som med npm-ormen Shai-Hulud.
Bakdører i oppstrømsprosjekter
En bidragsyter opparbeider seg tillit i et prosjekt med åpen kildekode over tid, og smugler deretter ondsinnet kode inn i en utgivelse som distribusjoner og produkter nedstrøms tar i bruk, som med bakdøren i xz utils.
Typosquatting og dependency confusion
Pakker med navn som ligger nær populære pakker, fanger opp skrivefeil. Dependency confusion går lenger: En offentlig pakke med samme navn som en intern pakke i en bedrift blir installert i stedet for den.
Kompromitterte CI/CD-komponenter
En GitHub Action eller et annet byggeverktøy blir kapret, og hver pipeline som bruker det, kjører angriperens kode med hemmelighetene sine innen rekkevidde, som med tj-actions og Codecov.
Manipulering av bygg og artefakter
Selve bygget endres, eller artefakten byttes ut mellom bygg og utrulling, så et rent kildetre likevel gir en kompromittert utgivelse, som med SolarWinds.
Eksempler på leverandørkjedeangrep
SolarWinds er det mest kjente leverandørkjedeangrepet: ondsinnet kode lagt inn i bygget og levert til kundene som en vanlig oppdatering. De nyeste angrepene går i stedet etter pakkeregistre og CI-pipelines, der én kompromittert pakke eller Action når hvert bygg som bruker den. Nyeste først:
tj-actions/changed-files
CISA rapporterte at alle versjoner av denne populære GitHub Action-en var kompromittert i tre dager, med hemmeligheter eksponert i workflow-logger. Workflows som refererte til den med tag, kjørte angriperens kode.
Bakdøren i xz utils
Andres Freund fant en bakdør i xz-versjonene 5.6.0 og 5.6.1 etter å ha lagt merke til at SSH-pålogginger brukte for mye CPU. Den var innført i selve oppstrømsprosjektet.
Log4Shell
En feil i Apache Log4j 2 lot en angriper som kontrollerte en loggmelding, kjøre vilkårlig kode, vurdert til CVSS 10.0. Det vanskelige for de fleste team var å finne hvilke applikasjoner som inneholdt log4j-core, vanligvis som en avhengighet av en avhengighet.
Codecov Bash Uploader
Angripere endret Bash Uploader-skriptet som team kjørte i CI-pipelinene sine, slik at det sendte CI-miljøet, inkludert påloggingsinformasjon, tokens og nøkler, til en server utenfor Codecovs infrastruktur. Det kjørte ubemerket fra 31. januar til en kunde rapporterte det 1. april.
SolarWinds Orion
Angripere hadde langvarig, skjult tilgang til byggeprosessen for SolarWinds Orion og la inn ondsinnet kode i Orion-utgivelsene 2019.4 til og med 2020.2.1 HF1, som kundene installerte som vanlige oppdateringer. CISA utstedte et nøddirektiv som svar.
Red team vs. blue team
Slik fungerer leverandørkjedeangrep, stadium for stadium
Hvert stadium med angriperens ord, og forsvaret som svarer.
Stadium 1 av 3
Rekognosering
Du trenger ikke å kjenne målet. Velg pakken, så velger målene seg selv.
Red team
Sats på avhengighetene alle har
Du trenger ikke lockfilen deres. Populære pakker ligger dypt i det transitive treet til nesten alt, og de fleste team kan ikke si hvilke de leverer. Offentlige spor snevrer det inn: versjoner i JavaScript-bundles og HTTP-headere, offentlige repositorier og container-images. Og det bygget deres henter utenfor lockfilen, for eksempel binærfilen et postinstall-skript laster ned eller lagene under base-imaget, har skanneren deres aldri sett, så ingen patcher det.
Blue team
Kjenn hver avhengighet hvert bygg hentet inn
CRACI ser trafikken som kommer inn i hvert bygg, og registrerer hver pakke og fil det henter inn, inkludert de skjulte avhengighetene som lockfile-baserte verktøy går glipp av, på alle nivåer i det transitive treet. SBOM-en din kommer fra bygget som ble levert, så du har listen en angriper aldri trengte, før noen begynner å lete.
SBOM-er fra bygget →Red team
Slå til i det en ny CVE kommer
En ny advisory forteller deg nøyaktig hvilke versjoner som er sårbare. Bygg exploiten, skann etter alt som svarer, og la skanningen fortelle deg hvem de er. Du begynner samme dag, mens teamet deres fortsatt spør «er vi berørt?» i en Slack-tråd.
Blue team
«Er vi berørt?» besvart fra byggeregistreringen
CRACI vurderer overvåkede SBOM-er kontinuerlig på nytt mot nye sårbarhetsdata. Byggehistorikken viser hvilke bygg som inneholdt den sårbare avhengigheten, direkte eller transitiv, så du vet hvor den ble levert, og hvor lenge.
Er vi berørt? →Stadium 2 av 3
Kom deg inn
Utnytt feilen før den er patchet, eller hopp over feilen og sitt på med pipelinen deres.
Red team
Generer angrepet samme dag det offentliggjøres
AI gjør en advisory og en patch-diff om til et fungerende angrep før sikkerhetsteamet deres har triagert saken. Offentliggjøringen er startskuddet ditt. Sprintplanleggingen deres er neste uke.
Blue team
Slutt å levere den sårbare versjonen
Policy gates kan blokkere ethvert bygg som inneholder en bestemt CVE, så den sårbare versjonen slutter å bli levert i det øyeblikket du bestemmer deg, uansett hvor dypt i treet den ligger.
CVE-utbedring →Red team
Skriv om én tag, kjør i tusen pipelines
Workflows stoler på tags som @v4, og tags kan flyttes. Kompromitter én populær GitHub Action, så kjører hver workflow som bruker den, koden din, med hemmelighetene deres innen rekkevidde.
Blue team
Vit nøyaktig hvilken Action hvert bygg kjørte
CRACI registrerer de GitHub Actions en workflow kjører, i byggets SBOM, festet til commiten som faktisk kjørte. Når en Action blir kompromittert, kan du se hvilke bygg som kjørte den skadelige koden, i stedet for å gjette ut fra en tag.
Sjekkliste for CI/CD-sikkerhet →Stadium 3 av 3
Kom deg ut
Ta hemmelighetene og bli værende for mer.
Red team
Ring hjem fra CI-en deres
En ondsinnet pakkeutgivelse kjører installasjonsskriptet sitt inne i bygget deres, der tokenene og skylegitimasjonen ligger. CI-runnere kan vanligvis nå hele internett, så hemmelighetene er på vei til serveren din før noen vet at pakken er dårlig.
Blue team
Et bygg kan bare nå det det trenger
En default deny-egress-policy lar et bygg nå pakkekildene og publiseringsmålene sine og blokkerer alt annet. Skadevare som sender hemmelighetene dine til en angripers vert, blir blokkert, selv som pasient null i et angrep ingen har sett før, og du får et varsel om policybruddet.
Egress-policyer →Red team
Bli værende på runneren til neste jobb
Selvhostede runnere med lang levetid er en gave: Plant noe i arbeidsområdet eller verktøycachen, og vent på at neste jobb, og neste sett med hemmeligheter, kommer til deg.
Blue team
Én isolert virtuell maskin per jobb
Hver CRACI-jobb kjører i sin egen isolerte virtuelle maskin, så ingenting én jobb legger igjen, venter på den neste. Det finnes heller ingen runnerflåte du må patche og herde.
Administrerte vs. selvhostede runnere →Etter offentliggjøring
Kappløpet starter når advisoryen blir offentlig
Angriperen trenger ikke å vite at du kjører avhengigheten. De prøver exploiten overalt og ser hva som svarer. Teamet ditt må vite hvor den avhengigheten ble levert. Forskjellen er om du må lete, og det blir flere kappløp å løpe hvert år: Se hvor mange CVE-er som publiseres hver dag.
Red team
- Advisory publisert
- Exploit generert
- Skanner etter alt som kjører en sårbar versjon
- Inne i hvert treff, også ditt
Blue team, uten byggeregistrering
- Advisory publisert
- «Er vi berørt?»
- Søker i repositorier, lockfiler og images
- Finner den transitive kopien ingen listet opp
- Finner ut hvilke utgivelser som leverte den
- Patcher
Blue team, med CRACI
- Advisory publisert
- Overvåkede SBOM-er vurderes på nytt
- Byggehistorikken viser byggene og perioden
- Policy gate blokkerer nye bygg med CVE-en
Slik forhindrer du angrep på programvareleverandørkjeden
Ingen enkelt kontroll stopper alle leverandørkjedeangrep. Kombiner disse i lag, så blir hvert stadium ovenfor vanskeligere. Pipeline-siden finner du i detalj i sjekklisten for sikkerhet i CI/CD-pipelinen.
- Vit hva hvert bygg leverer. Ha en SBOM for hvert bygg, inkludert transitive avhengigheter og alt som hentes utenfor lockfilen. En skanning av repositoriet er ikke en oversikt over utgivelsen.
- Følg med på det som er levert, ikke bare standardgrenen. Sjekk utgitte bygg på nytt mot nye advisories, og ta vare på byggehistorikken som forteller deg siden når du var eksponert.
- Fest avhengigheter og Actions. Bruk lockfiler, og fest GitHub Actions til en fullstendig commit-SHA. GitHub kaller det den eneste måten å bruke en action som en uforanderlig utgivelse på.
- Stopp sårbare versjoner i bygget. Sett gates på bygg for sårbarhetene du har bestemt ikke skal leveres, så en retting ikke i det stille kan gå tapt igjen.
- Default deny for egress i CI. La bygg bare nå pakkekildene og publiseringsmålene sine, så ondsinnet kode ikke kan sende hemmeligheter ut, selv i et angrep ingen har sett før.
- Isoler jobber og begrens hemmeligheter. Kjør hver jobb på en ny, isolert maskin, og gi hver jobb bare de tokenene og tillatelsene den trenger.
- Verifiser artefakter før du ruller ut. Signer provenance under bygget, og sjekk at det som kjører i produksjon, er nøyaktig det som ble bygget.
- Roter hemmeligheter etter en hendelse. Hvis en kompromittert pakke eller Action kjørte i pipelinen din, må du behandle hver hemmelighet den kunne nå, som eksponert. Det var CISAs råd etter tj-actions-kompromitteringen.
De trenger ikke listen. Det gjør du.
Angripere følger med på hver advisory og prøver exploiten på alle samme dag en sårbarhet blir offentliggjort. De har aldri trengt avhengighetslisten din. Det gjør du. CRACI gir teamet ditt den listen, hentet fra selve bygget, og stenger dørene angripere regner med: åpen egress og delte runnere.
Leverandørkjedeangrep: ofte stilte spørsmål
Hva er et angrep på programvareleverandørkjeden?
Et angrep på koden, verktøyene eller tjenestene et produkt bygges av, for eksempel en pakke med åpen kildekode, en CI/CD-komponent eller byggesystemet, i stedet for på selve produktet. Én kompromittering når hver organisasjon som bruker den berørte komponenten.
Hva er eksempler på angrep på programvareleverandørkjeden?
Shai-Hulud-ormen (siden 2025) spredte seg gjennom infiserte npm-pakker og stjal CI-hemmeligheter. Kompromitteringen av tj-actions/changed-files (CVE-2025-30066) kapret en populær GitHub Action. Bakdøren i xz utils (CVE-2024-3094) ble smuglet inn i et komprimeringsbibliotek oppstrøms. Log4Shell (CVE-2021-44228) utnyttet en feil i et mye brukt loggebibliotek for Java. Bash Uploader fra Codecov (2021) ble endret for å sende CI-påloggingsinformasjon til en ekstern server, og SolarWinds Orion (2020) leverte ondsinnet kode lagt inn i bygget.
Hva er det mest kjente leverandørkjedeangrepet?
SolarWinds. I 2020 la angripere med skjult tilgang til byggeprosessen for SolarWinds Orion ondsinnet kode inn i utgivelsene, og kundene installerte den som en vanlig oppdatering. Det viste at et rent kildetre ikke er nok: Selve bygget må være pålitelig og verifiserbart.
Vet angripere hvilke avhengigheter bedriften min bruker?
Vanligvis ikke, og de trenger det ikke. De fleste angrep retter seg mot en pakke, ikke en bedrift: Når en advisory er ute, prøver angripere exploiten mot alt som kan kjøre en sårbar versjon, og ser hva som svarer. Offentlige spor, for eksempel versjoner i JavaScript-bundles eller repositorier med åpen kildekode, hjelper dem å sikte. Asymmetrien er at du trenger listen: For å vite om du er berørt, må du vite hva hvert bygg leverte, inkludert det som ble hentet utenfor lockfilen.
Hvordan forhindrer du angrep på programvareleverandørkjeden?
Ingen enkelt kontroll stopper dem alle. Ha en SBOM over det hvert bygg leverer, og overvåk den mot nye advisories, fest avhengigheter og GitHub Actions, blokker sårbare versjoner i bygget, begrens hva CI-jobber kan koble seg til, isoler jobber og begrens hemmelighetene deres, og verifiser at artefaktene du ruller ut, er de du bygde.
Hvordan kan jeg beskytte meg mot leverandørkjedeangrep via npm?
Commit en lockfile og installer fra den i CI, og slå av installasjonsskript der et bygg ikke trenger dem (npms --ignore-scripts). Ta vare på en oversikt over hvilke pakkeversjoner hvert bygg faktisk installerte, så du raskt kan sjekke når en ny bølge som Shai-Hulud blir kjent. Begrens hva CI-jobber kan koble seg til, så et ondsinnet installasjonsskript ikke kan sende tokenene dine ut, og roter hvert token en infisert versjon kan ha nådd.
Hva betyr red team vs. blue team her?
I sikkerhetsøvelser spiller red team angriperen, og blue team forsvarer. Denne siden bruker samme inndeling: hvert stadium i et leverandørkjedeangrep med angriperens ord, besvart av forsvaret.
Oppdager CRACI ondsinnede pakker?
Kjente pakker, ja. En ondsinnet utgivelse som har en publisert CVE, for eksempel xz-bakdøren, flagges som enhver annen sårbarhet, og en policy gate kan blokkere bygg som inneholder den. CRACI analyserer ikke hvordan pakker oppfører seg, og vurderer ikke omdømme, så en helt ny ondsinnet pakke forblir uflagget til det finnes en advisory. Det er det egress-policyen er til for: Med default deny kan bygget bare nå vertene det trenger, så pakken kan ikke sende hemmelighetene dine ut, selv i et angrep ingen har sett før.