Shai-Hulud
En selvspredende orm, der kører, når en inficeret npm-pakke installeres, stjæler npm-, GitHub- og cloud-tokens og udgiver inficerede versioner af ofrets andre pakker. De fleste infektioner kørte i CI.
Sådan tjekker du dine builds →Red team vs. blue team
Forsyningskædeangreb: sådan kommer angribere ind, og sådan stopper du dem
Angribere går sjældent efter din virksomhed. De går efter den pakke, den Action eller det build-værktøj, virksomheder overalt er afhængige af, og prøver derefter exploitet på dem alle på én gang. De har ikke brug for din liste over afhængigheder. Det har du.
Hvad er et angreb på softwareforsyningskæden?
Et angreb på softwareforsyningskæden kompromitterer noget, et produkt er bygget af, for eksempel en open source-pakke, en CI/CD-komponent eller build-systemet, i stedet for at angribe produktet direkte. Moderne software er for det meste andres kode: Det meste kommer fra open source-pakker, og de fleste af dem er transitive afhængigheder, som ingen på teamet har valgt. Kompromittér én udbredt komponent, så når du hver organisation, der bygger på den.
Det ændrer, hvordan angribere vælger mål. De undersøger ikke én virksomheds afhængigheder. De vælger en pakke eller et værktøj med stor udbredelse, udnytter det overalt og ser, hvad der svarer.
Typer af angreb på softwareforsyningskæden
Udnyttelse af en sårbar afhængighed
En fejl i en populær open source-pakke bliver offentliggjort, og angribere udnytter den i hvert produkt, der leverer den sårbare version, som regel som en transitiv afhængighed, ingen har valgt direkte.
Ondsindede pakkereleases
En angriber overtager en maintainers konto, eller en orm stjæler publiceringstokens, og udgiver en forgiftet version af en betroet pakke. Den kører, i det øjeblik et build installerer den, som med npm-ormen Shai-Hulud.
Upstream-projekter med bagdør
En bidragyder opbygger tillid i et open source-projekt over tid og smugler derefter ondsindet kode ind i en release, som distributioner og produkter længere nede tager med, som med bagdøren i xz utils.
Typosquatting og dependency confusion
Pakker med navne tæt på populære pakker fanger tastefejl. Dependency confusion går videre: En offentlig pakke med samme navn som en virksomheds interne pakke bliver installeret i stedet for den.
Kompromitterede CI/CD-komponenter
En GitHub Action eller et andet build-værktøj bliver kapret, og hver pipeline, der bruger det, kører angriberens kode med sine secrets inden for rækkevidde, som med tj-actions og Codecov.
Manipulation af build og artefakter
Selve buildet bliver ændret, eller artefaktet bliver udskiftet mellem build og udrulning, så et rent kildetræ alligevel producerer en kompromitteret release, som med SolarWinds.
Eksempler på forsyningskædeangreb
SolarWinds er det bedst kendte forsyningskædeangreb: ondsindet kode indsat under buildet og leveret til kunder som en almindelig opdatering. De seneste angreb går i stedet efter pakke-registries og CI-pipelines, hvor én kompromitteret pakke eller Action når hvert build, der bruger den. Nyeste først:
tj-actions/changed-files
CISA rapporterede, at alle versioner af denne populære GitHub Action var kompromitteret i tre dage, med secrets eksponeret i workflow-logs. Workflows, der refererede til den via tag, kørte angriberens kode.
Bagdøren i xz utils
Andres Freund fandt en bagdør i xz-versionerne 5.6.0 og 5.6.1 efter at have bemærket, at SSH-logins brugte for meget CPU. Den var blevet indført i selve upstream-projektet.
Log4Shell
En fejl i Apache Log4j 2 lod en angriber, der kontrollerede en logget besked, køre vilkårlig kode, vurderet til CVSS 10.0. Det svære for de fleste teams var at finde ud af, hvilke applikationer der indeholdt log4j-core, som regel som en afhængighed af en afhængighed.
Codecov Bash Uploader
Angribere ændrede Bash Uploader-scriptet, som teams kørte i deres CI-pipelines, så det sendte CI-miljøet, inklusive legitimationsoplysninger, tokens og nøgler, til en server uden for Codecovs infrastruktur. Det kørte ubemærket fra 31. januar, indtil en kunde rapporterede det 1. april.
SolarWinds Orion
Angribere havde langvarig, skjult adgang til build-processen for SolarWinds Orion og indsatte ondsindet kode i Orion-releases 2019.4 til og med 2020.2.1 HF1, som kunder installerede som almindelige opdateringer. CISA udstedte et nøddirektiv som svar.
Red team vs. blue team
Sådan virker forsyningskædeangreb, stadie for stadie
Hvert stadie med angriberens ord og det forsvar, der svarer på det.
Stadie 1 af 3
Rekognoscering
Du behøver ikke at kende målet. Vælg pakken, så vælger målene sig selv.
Red team
Sats på de afhængigheder, alle har
Du behøver ikke deres lockfile. Populære pakker ligger dybt i det transitive træ i næsten alt, og de fleste teams kan ikke sige, hvilke de leverer. Offentlige spor indsnævrer det: versioner i JavaScript-bundles og HTTP-headers, offentlige repositories og container-images. Og det, deres build henter uden for lockfilen, for eksempel den binærfil, et postinstall-script downloader, eller lagene under deres base-image, har deres scanner aldrig set, så ingen patcher det.
Blue team
Kend hver afhængighed, hvert build trak ind
CRACI ser trafikken ind i hvert build og registrerer hver pakke og fil, det trækker ind, inklusive de skjulte afhængigheder, som lockfile-baserede værktøjer overser, i alle lag af det transitive træ. Din SBOM kommer fra det build, der blev leveret, så du allerede har den liste, en angriber aldrig havde brug for, når nogen begynder at lede.
SBOM'er fra buildet →Red team
Slå til, i det minut en ny CVE kommer
En ny advisory fortæller dig præcis, hvilke versioner der er sårbare. Byg exploitet, scan efter alt, der svarer, og lad scanningen fortælle dig, hvem de er. Du starter samme dag, mens deres team stadig spørger "er vi ramt?" i en Slack-tråd.
Blue team
"Er vi ramt?" besvaret ud fra build-registreringen
CRACI genvurderer løbende overvågede SBOM'er mod nye sårbarhedsdata. Build-historikken viser, hvilke builds der indeholdt den sårbare afhængighed, direkte eller transitiv, så du ved, hvor den blev leveret, og hvor længe.
Er vi ramt? →Stadie 2 af 3
Kom ind
Udnyt fejlen, før den bliver patchet, eller spring fejlen over og kør med i deres pipeline.
Red team
Generér angrebet samme dag, fejlen offentliggøres
AI omsætter en advisory og et patch-diff til et fungerende angreb, før deres sikkerhedsteam har triageret sagen. Offentliggørelsen er dit startskud. Deres sprintplanlægning er i næste uge.
Blue team
Stop med at levere den sårbare version
Policy gates kan blokere ethvert build, der indeholder en bestemt CVE, så den sårbare version holder op med at blive leveret, i det øjeblik du beslutter det, uanset hvor dybt i træet den ligger.
Afhjælpning af CVE'er →Red team
Omskriv ét tag, kør i tusind pipelines
Workflows stoler på tags som @v4, og tags kan flyttes. Kompromittér én populær GitHub Action, så kører hvert workflow, der bruger den, din kode, med deres secrets inden for rækkevidde.
Blue team
Vid præcis, hvilken Action hvert build kørte
CRACI registrerer de GitHub Actions, et workflow kører, i buildets SBOM, fastlåst på det commit, der faktisk kørte. Når en Action bliver kompromitteret, kan du se, hvilke builds der kørte den dårlige kode, i stedet for at gætte ud fra et tag.
Tjekliste til CI/CD-sikkerhed →Stadie 3 af 3
Kom ud
Tag secrets, og bliv hængende efter mere.
Red team
Ring hjem fra deres CI
En ondsindet pakkerelease kører sit install-script inde i deres build, hvor tokens og cloud-legitimationsoplysninger ligger. CI-runnere kan som regel nå hele internettet, så secrets er på vej til din server, før nogen ved, at pakken er dårlig.
Blue team
Et build kan kun nå det, det har brug for
En default deny-egress-politik lader et build nå sine pakkekilder og publiceringsmål og blokerer alt andet. Malware, der sender dine secrets til en angribers host, bliver blokeret, selv som patient nul i et angreb, ingen har set før, og du får en alarm om overtrædelsen af politikken.
Egress-politikker →Red team
Bliv på runneren til næste job
Langlivede self-hosted runnere er en gave: Plant noget i workspacet eller værktøjscachen, og vent på, at næste job, og næste sæt secrets, kommer til dig.
Blue team
Én isoleret virtuel maskine pr. job
Hvert CRACI-job kører i sin egen isolerede virtuelle maskine, så intet, ét job efterlader, venter på det næste. Der er heller ingen flåde af runnere, du skal patche og hærde.
Administrerede vs. self-hosted runnere →Efter offentliggørelsen
Kapløbet starter, når advisoryen bliver offentlig
Angribere behøver ikke at vide, at du kører afhængigheden. De prøver exploitet overalt og ser, hvad der svarer. Dit team skal vide, hvor afhængigheden blev leveret. Forskellen er, om du skal ud og lede, og der er flere kapløb at løbe hvert år: Se hvor mange CVE'er der offentliggøres hver dag.
Red team
- Advisory offentliggjort
- Exploit genereret
- Scan efter alt, der kører en sårbar version
- Inde i hvert match, også dit
Blue team, uden build-registrering
- Advisory offentliggjort
- "Er vi ramt?"
- Grep repos, lockfiles og images
- Find den transitive kopi, ingen havde angivet
- Find ud af, hvilke releases der leverede den
- Patch
Blue team, med CRACI
- Advisory offentliggjort
- Overvågede SBOM'er genvurderet
- Build-historikken viser builds og periode
- Policy gate blokerer nye builds med CVE'en
Sådan forebygger du angreb på softwareforsyningskæden
Ingen enkelt kontrol stopper alle forsyningskædeangreb. Læg dem i lag, så bliver hvert stadie ovenfor sværere. Pipeline-siden i detaljer finder du i sikkerhedstjeklisten til CI/CD-pipelines.
- Vid, hvad hvert build leverer. Hav en SBOM for hvert build, inklusive transitive afhængigheder og alt, der hentes uden for lockfilen. En scanning af repositoriet er ikke en registrering af releasen.
- Hold øje med det leverede, ikke kun default-branchen. Tjek udgivne builds igen mod nye advisories, og behold den build-historik, der fortæller dig, siden hvornår du har været eksponeret.
- Fastlås afhængigheder og Actions. Brug lockfiles, og fastlås GitHub Actions på et commit-SHA i fuld længde. GitHub kalder det den eneste måde at bruge en action som en uforanderlig release på.
- Stop sårbare versioner ved buildet. Sæt gates på builds for de sårbarheder, du har besluttet ikke må leveres, så en rettelse ikke stille og roligt kan gå tabt igen.
- Default deny-egress i CI. Lad kun builds nå deres pakkekilder og publiceringsmål, så ondsindet kode ikke kan sende secrets ud, selv i et angreb, ingen har set før.
- Isolér jobs, og begræns secrets. Kør hvert job på en ny, isoleret maskine, og giv hvert job kun de tokens og rettigheder, det har brug for.
- Verificér artefakter før udrulning. Signér provenance under buildet, og tjek, at det, der kører i produktion, er præcis det, der blev bygget.
- Rotér secrets efter en hændelse. Hvis en kompromitteret pakke eller Action kørte i din pipeline, så behandl hver secret, den kunne nå, som eksponeret. Det var CISA's råd efter kompromitteringen af tj-actions.
De har ikke brug for listen. Det har du.
Angribere overvåger hver advisory og prøver exploitet på alle den dag, en sårbarhed offentliggøres. De har aldrig haft brug for din liste over afhængigheder. Det har du. CRACI giver dit team den liste, taget fra selve buildet, og lukker de døre, angribere regner med: åben egress og delte runnere.
Forsyningskædeangreb: ofte stillede spørgsmål
Hvad er et angreb på softwareforsyningskæden?
Et angreb på den kode, de værktøjer eller de tjenester, et produkt er bygget af, for eksempel en open source-pakke, en CI/CD-komponent eller build-systemet, i stedet for på selve produktet. Én kompromittering rammer alle organisationer, der bruger den berørte komponent.
Hvad er eksempler på angreb på softwareforsyningskæden?
Shai-Hulud-ormen (siden 2025) spredte sig gennem inficerede npm-pakker og stjal CI-secrets. Kompromitteringen af tj-actions/changed-files (CVE-2025-30066) kaprede en populær GitHub Action. Bagdøren i xz utils (CVE-2024-3094) blev smuglet ind i et upstream-komprimeringsbibliotek. Log4Shell (CVE-2021-44228) udnyttede en fejl i et udbredt logbibliotek til Java. Codecovs Bash Uploader (2021) blev ændret, så den sendte CI-legitimationsoplysninger til en ekstern server, og SolarWinds Orion (2020) leverede ondsindet kode indsat under buildet.
Hvad er det mest berømte forsyningskædeangreb?
SolarWinds. I 2020 indsatte angribere med skjult adgang til build-processen for SolarWinds Orion ondsindet kode i dets releases, og kunder installerede den som en almindelig opdatering. Det viste, at et rent kildetræ ikke er nok: Selve buildet skal være troværdigt og kunne verificeres.
Ved angribere, hvilke afhængigheder min virksomhed bruger?
Som regel ikke, og det behøver de ikke. De fleste angreb går efter en pakke og ikke en virksomhed: Når en advisory er ude, prøver angribere exploitet mod alt, der måske kører en sårbar version, og ser, hvad der svarer. Offentlige spor, for eksempel versioner i JavaScript-bundles eller open source-repositories, hjælper dem med at sigte. Asymmetrien er, at du har brug for listen: For at vide, om du er ramt, skal du vide, hvad hvert build leverede, inklusive det, det hentede uden for lockfilen.
Hvordan forebygger du angreb på softwareforsyningskæden?
Ingen enkelt kontrol stopper dem alle. Hav en SBOM over det, hvert build leverer, og overvåg den mod nye advisories, fastlås afhængigheder og GitHub Actions, blokér sårbare versioner ved buildet, begræns, hvad CI-jobs kan forbinde til, isolér jobs og begræns deres secrets, og verificér, at udrullede artefakter er dem, du byggede.
Hvordan beskytter jeg mig mod forsyningskædeangreb via npm?
Commit en lockfile, og installér fra den i CI, og slå install-scripts fra, hvor et build ikke har brug for dem (npm's --ignore-scripts). Registrér, hvilke pakkeversioner hvert build faktisk installerede, så du hurtigt kan tjekke, når en ny bølge som Shai-Hulud bliver annonceret. Begræns, hvad CI-jobs kan forbinde til, så et ondsindet install-script ikke kan sende dine tokens ud, og rotér ethvert token, en inficeret version kunne have nået.
Hvad betyder red team vs. blue team her?
I sikkerhedsøvelser spiller red team angriberen, og blue team forsvarer. Denne side bruger samme opdeling: hvert stadie i et forsyningskædeangreb med angriberens ord, besvaret af forsvaret.
Opdager CRACI ondsindede pakker?
Kendte, ja. En ondsindet release med en offentliggjort CVE, for eksempel xz-bagdøren, bliver markeret som enhver anden sårbarhed, og en policy gate kan blokere builds, der indeholder den. CRACI analyserer ikke pakkers adfærd og scorer ikke omdømme, så en helt ny ondsindet pakke bliver ikke markeret, før der findes en advisory. Det er det, egress-politikken er til: Med default deny kan buildet kun nå de hosts, det har brug for, så pakken ikke kan sende dine secrets ud, selv i et angreb, ingen har set før.