Red team vs blue team
Angripare riktar sig sällan mot ditt företag. De riktar sig mot paketet, Actionen eller byggverktyget som företag överallt är beroende av, och testar sedan exploiten på alla samtidigt. De behöver inte din beroendelista. Det gör du.
En attack mot mjukvarans leveranskedja komprometterar något som en produkt byggs av, till exempel ett open source-paket, en CI/CD-komponent eller byggsystemet, i stället för att angripa produkten direkt. Modern programvara består till största delen av andras kod: det mesta kommer från open source-paket, och de flesta av dem är transitiva beroenden som ingen i teamet har valt. Komprometterar du en brett använd komponent når du varje organisation som bygger på den.
Det ändrar hur angripare väljer mål. De undersöker inte ett enskilt företags beroenden. De väljer ett paket eller verktyg med stor spridning, utnyttjar det överallt och ser vad som svarar.
En brist i ett populärt open source-paket offentliggörs, och angripare utnyttjar den i varje produkt som levererar den sårbara versionen, oftast som ett transitivt beroende som ingen har valt direkt.
En angripare tar över ett underhållarkonto, eller en mask stjäl publiceringstokens, och släpper en förgiftad version av ett betrott paket. Den körs i samma ögonblick som ett bygge installerar den, som med npm-masken Shai-Hulud.
En bidragsgivare bygger upp förtroende i ett open source-projekt över tid och smyger sedan in skadlig kod i en release som nedströms distributioner och produkter tar in, som med bakdörren i xz utils.
Paket med namn som liknar populära paket fångar upp skrivfel. Dependency confusion går längre: ett publikt paket med samma namn som ett företags interna paket installeras i dess ställe.
En GitHub Action eller ett annat byggverktyg kapas, och varje pipeline som använder det kör angriparens kod med sina hemligheter inom räckhåll, som med tj-actions och Codecov.
Själva bygget ändras, eller så byts artefakten ut mellan bygget och driftsättningen, så att ett rent källkodsträd ändå ger en komprometterad release, som med SolarWinds.
SolarWinds är den mest kända attacken mot leveranskedjan: skadlig kod som förts in i bygget och levererats till kunder som en vanlig uppdatering. De senaste attackerna går i stället på paketregister och CI-pipelines, där ett enda komprometterat paket eller en enda komprometterad Action når varje bygge som använder dem. Nyast först:
En självspridande mask som körs när ett infekterat npm-paket installeras, stjäl tokens för npm, GitHub och molntjänster och publicerar infekterade versioner av offrets andra paket. De flesta infektioner kördes i CI.
Så kontrollerar du dina byggen →CISA rapporterade att varje version av denna populära GitHub Action var komprometterad i tre dagar, med hemligheter exponerade i arbetsflödesloggar. Arbetsflöden som refererade till den via tagg körde angriparens kod.
Andres Freund hittade en bakdörr i xz-versionerna 5.6.0 och 5.6.1 efter att ha märkt att SSH-inloggningar använde för mycket CPU. Den hade förts in i själva uppströmsprojektet.
En brist i Apache Log4j 2, klassad som CVSS 10.0, lät en angripare som kontrollerade ett loggat meddelande köra godtycklig kod. Det svåra för de flesta team var att hitta vilka applikationer som innehöll log4j-core, oftast som ett beroende till ett beroende.
Angripare ändrade Bash Uploader-skriptet som team körde i sina CI-pipelines, så att det skickade CI-miljön, inklusive inloggningsuppgifter, tokens och nycklar, till en server utanför Codecovs infrastruktur. Det pågick obemärkt från den 31 januari tills en kund rapporterade det den 1 april.
Angripare hade långvarig, dold åtkomst till byggprocessen för SolarWinds Orion och förde in skadlig kod i Orion-releaserna 2019.4 till och med 2020.2.1 HF1, som kunderna installerade som vanliga uppdateringar. CISA utfärdade ett nöddirektiv som svar.
Red team vs blue team
Varje steg med angriparens ord, och försvaret som svarar på det.
Steg 1 av 3
Du behöver inte känna till målet. Välj paketet, så väljer målen sig själva.
Red team
Du behöver inte deras lockfile. Populära paket ligger djupt i det transitiva trädet för nästan allting, och de flesta team kan inte säga vilka de levererar. Publika ledtrådar ringar in det: versioner i JavaScript-buntar och HTTP-huvuden, publika repon och containeravbilder. Och det som deras bygge hämtar utanför lockfilen, som binären ett postinstall-skript laddar ner eller lagren under deras basavbild, har deras skanner aldrig sett, så ingen patchar det.
Blue team
CRACI ser trafiken som kommer in i varje bygge och registrerar varje paket och fil som bygget drar in, inklusive de dolda beroenden som lockfile-baserade verktyg missar, i alla led av det transitiva trädet. Din SBOM kommer från bygget som levererades, så du har listan som en angripare aldrig behövde, innan någon börjar leta.
SBOM:er från bygget →Red team
Ett nytt säkerhetsmeddelande talar om exakt vilka versioner som är sårbara. Bygg exploiten, skanna efter allt som svarar och låt skanningen tala om vilka de är. Du börjar samma dag, medan deras team fortfarande frågar ”är vi berörda?” i en Slack-tråd.
Blue team
CRACI omvärderar bevakade SBOM:er löpande mot nya sårbarhetsdata. Bygghistoriken visar vilka byggen som innehöll det sårbara beroendet, direkt eller transitivt, så att du vet var det levererades och hur länge.
Är vi berörda? →Steg 2 av 3
Utnyttja bristen innan den är patchad, eller hoppa över bristen och åk med i deras pipeline.
Red team
AI gör om ett säkerhetsmeddelande och en patch-diff till en fungerande attack innan deras säkerhetsteam har triagerat ärendet. Offentliggörandet är ditt startskott. Deras sprintplanering är nästa vecka.
Blue team
Policykontroller kan blockera alla byggen som innehåller en specifik CVE, så att den sårbara versionen slutar levereras i samma ögonblick som du bestämmer det, hur djupt i trädet den än ligger.
Åtgärda CVE:er →Red team
Arbetsflöden litar på taggar som @v4, och taggar kan flyttas. Komprometterar du en populär GitHub Action kör varje arbetsflöde som använder den din kod, med sina hemligheter inom räckhåll.
Blue team
CRACI registrerar de GitHub Actions som ett arbetsflöde kör i byggets SBOM, låsta till den commit som faktiskt kördes. När en Action komprometteras kan du se vilka byggen som körde den skadliga koden i stället för att gissa utifrån en tagg.
Säkerhetschecklista för CI/CD →Steg 3 av 3
Ta hemligheterna och stanna kvar för mer.
Red team
En skadlig paketrelease kör sitt installationsskript inne i deras bygge, där tokens och molnbehörigheter finns. CI-runners kan oftast nå hela internet, så hemligheterna ger sig av till din server innan någon vet att paketet är skadligt.
Blue team
En egress-policy som nekar som standard låter ett bygge nå sina paketkällor och publiceringsmål och blockerar allt annat. Skadlig kod som skickar dina hemligheter till en angripares värd blockeras, även som patient noll i en attack som ingen har sett tidigare, och du får en varning om policyöverträdelsen.
Egress-policyer →Red team
Långlivade självhostade runners är en gåva: plantera något i arbetsytan eller verktygscachen och vänta på att nästa jobb, och nästa uppsättning hemligheter, kommer till dig.
Blue team
Varje CRACI-jobb körs i en egen isolerad virtuell maskin, så inget som ett jobb lämnar efter sig väntar på nästa. Det finns inte heller någon flotta av runners för dig att patcha och härda.
Hanterade vs självhostade runners →Efter offentliggörandet
Angriparen behöver inte veta att du kör beroendet. Angriparen testar exploiten överallt och ser vad som svarar. Ditt team behöver veta var beroendet levererades. Skillnaden är om du måste gå och leta, och det blir fler kapplöpningar för varje år: se hur många CVE:er som publiceras varje dag.
Red team
Blue team, utan byggregistrering
Blue team, med CRACI
Ingen enskild kontroll stoppar varje attack mot leveranskedjan. Kombinera de här, så blir varje steg ovan svårare. För pipeline-sidan i detalj, se säkerhetschecklistan för CI/CD-pipelines.
Angripare bevakar varje säkerhetsmeddelande och testar exploiten på alla samma dag som en sårbarhet offentliggörs. De har aldrig behövt din beroendelista. Det gör du. CRACI ger ditt team den listan, hämtad från själva bygget, och stänger dörrarna som angripare räknar med: öppen egress och delade runners.
En attack mot den kod, de verktyg eller de tjänster som en produkt byggs av, till exempel ett open source-paket, en CI/CD-komponent eller byggsystemet, snarare än mot själva produkten. En enda kompromettering når varje organisation som använder den berörda komponenten.
Masken Shai-Hulud (sedan 2025) spreds genom infekterade npm-paket och stal hemligheter från CI. Attacken mot tj-actions/changed-files (CVE-2025-30066) kapade en populär GitHub Action. Bakdörren i xz utils (CVE-2024-3094) smögs in i ett uppströms komprimeringsbibliotek. Log4Shell (CVE-2021-44228) utnyttjade en brist i ett brett använt loggningsbibliotek för Java. Codecovs Bash Uploader (2021) ändrades för att skicka inloggningsuppgifter från CI till en extern server, och SolarWinds Orion (2020) levererades med skadlig kod som förts in i bygget.
SolarWinds. År 2020 förde angripare med dold åtkomst till byggprocessen för SolarWinds Orion in skadlig kod i dess releaser, och kunderna installerade den som en vanlig uppdatering. Den visade att ett rent källkodsträd inte räcker: själva bygget måste vara tillförlitligt och verifierbart.
Oftast inte, och de behöver inte veta det. De flesta attacker riktar sig mot ett paket snarare än ett företag: när ett säkerhetsmeddelande är ute testar angripare exploiten mot allt som kan köra en sårbar version och ser vad som svarar. Publika ledtrådar, som versioner i JavaScript-buntar eller repon med öppen källkod, hjälper dem att sikta. Asymmetrin är att du faktiskt behöver listan: för att veta om du är berörd måste du veta vad varje bygge levererade, inklusive det som hämtades utanför lockfilen.
Ingen enskild kontroll stoppar alla. Ha en SBOM över vad varje bygge levererar och bevaka den mot nya säkerhetsmeddelanden, lås beroenden och GitHub Actions, blockera sårbara versioner vid bygget, begränsa vad CI-jobb kan ansluta till, isolera jobb och begränsa deras hemligheter, och verifiera att driftsatta artefakter är de du byggde.
Checka in en lockfile och installera från den i CI, och inaktivera installationsskript där ett bygge inte behöver dem (npm:s --ignore-scripts). Behåll en registrering av vilka paketversioner varje bygge faktiskt installerade, så att du snabbt kan kontrollera när en ny våg som Shai-Hulud blir känd. Begränsa vad CI-jobb kan ansluta till, så att ett skadligt installationsskript inte kan skicka ut dina tokens, och rotera varje token som en infekterad version kan ha nått.
I säkerhetsövningar spelar red team angriparen och blue team försvarar. Den här sidan använder samma uppdelning: varje steg i en attack mot leveranskedjan med angriparens ord, besvarat av försvaret.
Kända sådana, ja. En skadlig release som har en publicerad CVE, till exempel bakdörren i xz, flaggas som vilken annan sårbarhet som helst, och en policykontroll kan blockera byggen som innehåller den. CRACI analyserar inte hur paket beter sig och poängsätter inte rykte, så ett helt nytt skadligt paket flaggas inte förrän det finns ett säkerhetsmeddelande. Det är det egress-policyn är till för: med neka som standard når bygget bara de värdar det behöver, så paketet kan inte skicka ut dina hemligheter, inte ens i en attack som ingen har sett tidigare.