Red team vs blue team
Aanvallers richten zich zelden op uw bedrijf. Ze richten zich op het pakket, de Action of de buildtool waarvan bedrijven overal afhankelijk zijn, en proberen de exploit vervolgens op allemaal tegelijk. Ze hebben uw lijst met afhankelijkheden niet nodig. U wel.
Een aanval op de softwareketen compromitteert iets waaruit een product is opgebouwd, zoals een open-sourcepakket, een CI/CD-component of het buildsysteem, in plaats van het product direct aan te vallen. Moderne software is grotendeels code van anderen: het meeste komt uit open-sourcepakketten, en de meeste daarvan zijn transitieve afhankelijkheden die niemand in het team heeft gekozen. Compromitteer één veelgebruikt component, en u bereikt elke organisatie die erop bouwt.
Dat verandert hoe aanvallers doelwitten kiezen. Ze onderzoeken niet de afhankelijkheden van één bedrijf. Ze kiezen een pakket of tool met een grote voetafdruk, misbruiken die overal en kijken wat er antwoordt.
Een fout in een populair open-sourcepakket wordt bekendgemaakt, en aanvallers misbruiken die in elk product dat de kwetsbare versie levert, meestal als transitieve afhankelijkheid die niemand direct heeft gekozen.
Een aanvaller neemt een account van een maintainer over, of een worm steelt publicatietokens, en brengt een vergiftigde versie van een vertrouwd pakket uit. Die draait zodra een build hem installeert, zoals bij de npm-worm Shai-Hulud.
Een bijdrager wint in de loop van de tijd vertrouwen in een open-sourceproject en smokkelt vervolgens kwaadaardige code in een release die downstream distributies en producten overnemen, zoals bij de backdoor in xz utils.
Pakketten met namen die op populaire namen lijken, profiteren van typefouten. Dependency confusion gaat verder: een openbaar pakket met dezelfde naam als een intern pakket van een bedrijf wordt in plaats daarvan geïnstalleerd.
Een GitHub Action of andere buildtool wordt gekaapt, en elke pipeline die hem gebruikt, voert de code van de aanvaller uit met de eigen secrets binnen bereik, zoals bij tj-actions en Codecov.
De build zelf wordt gewijzigd, of het artefact wordt tussen build en uitrol verwisseld, zodat een schone broncodeboom toch een gecompromitteerde release oplevert, zoals bij SolarWinds.
SolarWinds is de bekendste aanval op de softwareketen: kwaadaardige code die tijdens de build werd ingevoegd en als normale update aan klanten werd geleverd. De meest recente aanvallen richten zich in plaats daarvan op pakketregistries en CI-pipelines, waar één gecompromitteerd pakket of één gecompromitteerde Action elke build bereikt die ervan gebruikmaakt. Nieuwste eerst:
Een zichzelf verspreidende worm die draait wanneer een geïnfecteerd npm-pakket wordt geïnstalleerd, npm-, GitHub- en cloudtokens steelt en geïnfecteerde versies publiceert van de andere pakketten van het slachtoffer. De meeste infecties vonden plaats in CI.
Hoe u uw builds controleert →CISA meldde dat elke versie van deze populaire GitHub Action drie dagen lang gecompromitteerd was, met secrets die in workflowlogs werden blootgesteld. Workflows die er via een tag naar verwezen, voerden de code van de aanvaller uit.
Andres Freund vond een backdoor in xz-versies 5.6.0 en 5.6.1 nadat hij had gemerkt dat SSH-logins te veel CPU gebruikten. De backdoor was in het upstreamproject zelf ingebracht.
Door een fout in Apache Log4j 2 kon een aanvaller die een gelogd bericht beheerste, willekeurige code uitvoeren, met een CVSS-score van 10.0. Het moeilijke voor de meeste teams was vinden welke applicaties log4j-core bevatten, meestal als afhankelijkheid van een afhankelijkheid.
Aanvallers wijzigden het Bash Uploader-script dat teams in hun CI-pipelines draaiden, zodat het de CI-omgeving, inclusief inloggegevens, tokens en sleutels, naar een server buiten de infrastructuur van Codecov stuurde. Het draaide onopgemerkt van 31 januari tot een klant het op 1 april meldde.
Aanvallers hadden al lange tijd heimelijke toegang tot het buildproces van SolarWinds Orion en voegden kwaadaardige code toe aan Orion-releases 2019.4 tot en met 2020.2.1 HF1, die klanten als normale updates installeerden. CISA vaardigde als reactie een noodrichtlijn uit.
Red team vs blue team
Elke fase in de woorden van de aanvaller, en de verdediging die daarop antwoordt.
Fase 1 van 3
U hoeft het doelwit niet te kennen. Kies het pakket, en de doelwitten kiezen zichzelf.
Red team
U hebt hun lockfile niet nodig. Populaire pakketten zitten diep in de transitieve boom van bijna alles, en de meeste teams kunnen niet zeggen welke ze leveren. Openbare aanwijzingen verkleinen de zoekruimte: versies in JavaScript-bundels en HTTP-headers, openbare repositories en containerimages. En wat hun build buiten de lockfile ophaalt, zoals de binary die een postinstall-script downloadt of de lagen onder hun base image, heeft hun scanner nooit gezien, dus niemand patcht het.
Blue team
CRACI ziet het verkeer dat elke build binnenkomt en legt elk pakket en bestand vast dat hij binnenhaalt, inclusief de verborgen afhankelijkheden die op lockfiles gebaseerde tools missen, op elk niveau van de transitieve boom. Uw SBOM komt uit de build die is geleverd, dus u hebt de lijst die een aanvaller nooit nodig had, voordat iemand gaat zoeken.
SBOM's tijdens de build →Red team
Een nieuwe advisory vertelt u precies welke versies kwetsbaar zijn. Bouw de exploit, scan op alles wat antwoordt, en laat de scan u vertellen wie ze zijn. U begint dezelfde dag, terwijl hun team in een Slack-thread nog vraagt: "zijn we getroffen?"
Blue team
CRACI beoordeelt gemonitorde SBOM's doorlopend opnieuw aan de hand van nieuwe kwetsbaarheidsgegevens. De buildgeschiedenis toont welke builds de kwetsbare afhankelijkheid bevatten, direct of transitief, zodat u weet waar die is geleverd en hoe lang.
Zijn we getroffen? →Fase 2 van 3
Misbruik de fout voordat die is gepatcht, of sla de fout over en lift mee op hun pipeline.
Red team
AI maakt van een advisory en een patch-diff een werkende aanval voordat hun securityteam het ticket heeft getrieerd. De bekendmaking is uw startschot. Hun sprintplanning is volgende week.
Blue team
Policy gates kunnen elke build blokkeren die een specifieke CVE bevat, zodat de kwetsbare versie niet meer wordt geleverd op het moment dat u dat besluit, hoe diep in de boom die ook zit.
CVE-remediatie →Red team
Workflows vertrouwen tags zoals @v4, en tags kunnen worden verplaatst. Compromitteer één populaire GitHub Action en elke workflow die hem gebruikt, voert uw code uit, met hun secrets binnen bereik.
Blue team
CRACI legt de GitHub Actions die een workflow draait vast in de SBOM van de build, vastgepind op de commit die daadwerkelijk heeft gedraaid. Wordt een Action gecompromitteerd, dan ziet u welke builds de kwaadaardige code hebben gedraaid in plaats van het te moeten raden aan de hand van een tag.
CI/CD-beveiligingschecklist →Fase 3 van 3
Neem de secrets mee en blijf hangen voor meer.
Red team
Een kwaadaardige pakketrelease voert zijn installatiescript uit binnen hun build, waar de tokens en cloudinloggegevens staan. CI-runners kunnen meestal het hele internet bereiken, dus de secrets vertrekken naar uw server voordat iemand weet dat het pakket kwaadaardig is.
Blue team
Een egressbeleid dat standaard weigert, laat een build zijn pakketbronnen en publicatiedoelen bereiken en blokkeert al het andere. Malware die uw secrets naar de host van een aanvaller stuurt, wordt geblokkeerd, zelfs als patiënt nul van een aanval die nog niemand heeft gezien, en u krijgt een melding van de beleidsovertreding.
Egressbeleid →Red team
Langlevende zelfgehoste runners zijn een geschenk: plant iets in de workspace of de toolcache en wacht tot de volgende job, en de volgende set secrets, naar u toe komt.
Blue team
Elke CRACI-job draait in zijn eigen geïsoleerde virtuele machine, dus niets wat de ene job achterlaat, wacht op de volgende. Er is ook geen vloot runners die u moet patchen en harden.
Beheerde vs zelfgehoste runners →Na de bekendmaking
De aanvaller hoeft niet te weten dat u de afhankelijkheid gebruikt. Hij probeert de exploit overal en kijkt wat er antwoordt. Uw team moet weten waar die afhankelijkheid is geleverd. Het verschil is of u moet gaan zoeken, en er zijn elk jaar meer races te lopen: zie hoeveel CVE's er per dag worden gepubliceerd.
Red team
Blue team, zonder buildrecord
Blue team, met CRACI
Geen enkele maatregel stopt elke aanval op de softwareketen. Combineer deze, en elke fase hierboven wordt moeilijker. Zie voor de pipelinekant in detail de beveiligingschecklist voor CI/CD-pipelines.
Aanvallers volgen elke advisory en proberen de exploit op iedereen op de dag dat een kwetsbaarheid bekend wordt. Ze hadden uw lijst met afhankelijkheden nooit nodig. U wel. CRACI geeft uw team die lijst, rechtstreeks uit de build, en sluit de deuren waarop aanvallers rekenen: open egress en gedeelde runners.
Een aanval op de code, tools of diensten waaruit een product is opgebouwd, zoals een open-sourcepakket, een CI/CD-component of het buildsysteem, en niet op het product zelf. Eén compromittering bereikt elke organisatie die het getroffen component gebruikt.
De Shai-Hulud-worm (sinds 2025) verspreidde zich via geïnfecteerde npm-pakketten en stal CI-secrets. De compromittering van tj-actions/changed-files (CVE-2025-30066) kaapte een populaire GitHub Action. De backdoor in xz utils (CVE-2024-3094) werd in een upstream compressiebibliotheek gesmokkeld. Log4Shell (CVE-2021-44228) misbruikte een fout in een veelgebruikte Java-logbibliotheek. De Bash Uploader van Codecov (2021) werd gewijzigd om CI-inloggegevens naar een externe server te sturen, en SolarWinds Orion (2020) leverde kwaadaardige code die tijdens de build was ingevoegd.
SolarWinds. In 2020 voegden aanvallers met heimelijke toegang tot het buildproces van SolarWinds Orion kwaadaardige code toe aan de releases, en klanten installeerden die als normale update. Het liet zien dat een schone broncodeboom niet genoeg is: de build zelf moet betrouwbaar en verifieerbaar zijn.
Meestal niet, en dat hoeft ook niet. De meeste aanvallen richten zich op een pakket en niet op een bedrijf: zodra een advisory uit is, proberen aanvallers de exploit op alles wat een kwetsbare versie zou kunnen draaien en kijken ze wat er antwoordt. Openbare aanwijzingen, zoals versies in JavaScript-bundels of open-sourcerepositories, helpen hen gericht aan te vallen. De asymmetrie is dat u de lijst wel nodig hebt: om te weten of u bent getroffen, moet u weten wat elke build heeft geleverd, inclusief wat hij buiten de lockfile heeft opgehaald.
Geen enkele maatregel stopt ze allemaal. Bewaar een SBOM van wat elke build levert en monitor die op nieuwe advisories, pin afhankelijkheden en GitHub Actions vast, blokkeer kwetsbare versies bij de build, beperk waarmee CI-jobs verbinding kunnen maken, isoleer jobs en beperk hun secrets, en verifieer dat uitgerolde artefacten de artefacten zijn die u hebt gebouwd.
Commit een lockfile en installeer ermee in CI, en schakel installatiescripts uit waar een build ze niet nodig heeft (--ignore-scripts van npm). Houd bij welke pakketversies elke build daadwerkelijk heeft geïnstalleerd, zodat u snel kunt controleren wanneer een nieuwe golf zoals Shai-Hulud wordt aangekondigd. Beperk waarmee CI-jobs verbinding kunnen maken, zodat een kwaadaardig installatiescript uw tokens niet naar buiten kan sturen, en roteer elk token dat een geïnfecteerde versie kan hebben bereikt.
In beveiligingsoefeningen speelt het red team de aanvaller en verdedigt het blue team. Deze pagina gebruikt dezelfde verdeling: elke fase van een aanval op de softwareketen in de woorden van de aanvaller, beantwoord door de verdediging.
Bekende wel. Een kwaadaardige release met een gepubliceerde CVE, zoals de xz-backdoor, wordt gemarkeerd zoals elke andere kwetsbaarheid, en een policy gate kan builds blokkeren die hem bevatten. CRACI analyseert geen pakketgedrag en kent geen reputatiescores toe, dus een gloednieuw kwaadaardig pakket blijft ongemarkeerd totdat er een advisory bestaat. Daarvoor dient het egressbeleid: met standaard weigeren kan de build alleen de hosts bereiken die hij nodig heeft, dus het pakket kan uw secrets niet naar buiten sturen, zelfs niet bij een aanval die nog niemand heeft gezien.