Shai-Hulud
Samošířící se červ, který se spustí při instalaci infikovaného balíčku npm, ukradne tokeny npm, GitHubu a cloudu a publikuje infikované verze dalších balíčků oběti. Většina infekcí proběhla v CI.
Jak zkontrolovat své buildy →Red team vs blue team
Útoky na dodavatelský řetězec: jak se útočníci dostanou dovnitř a jak je zastavit
Útočníci málokdy míří na vaši firmu. Míří na balíček, Action nebo nástroj buildu, na kterých závisejí firmy všude, a pak zkoušejí exploit na všech najednou. Seznam vašich závislostí nepotřebují. Vy ano.
Co je útok na softwarový dodavatelský řetězec?
Útok na softwarový dodavatelský řetězec kompromituje něco, z čeho se produkt sestavuje, například open source balíček, komponentu CI/CD nebo systém buildu, místo aby útočil přímo na produkt. Moderní software je z velké části cizí kód: většina pochází z open source balíčků a většina z nich jsou tranzitivní závislosti, které nikdo v týmu nevybral. Kompromitujte jednu široce používanou komponentu a zasáhnete každou organizaci, která na ní staví.
To mění způsob, jakým útočníci vybírají cíle. Nezkoumají závislosti jedné firmy. Vyberou balíček nebo nástroj s velkým dosahem, zneužijí ho všude a sledují, co odpoví.
Typy útoků na softwarový dodavatelský řetězec
Zneužití zranitelné závislosti
Je zveřejněna chyba v oblíbeném open source balíčku a útočníci ji zneužijí v každém produktu, který dodává zranitelnou verzi, obvykle jako tranzitivní závislost, kterou nikdo přímo nevybral.
Škodlivá vydání balíčků
Útočník převezme účet správce nebo červ ukradne tokeny pro publikování a vydá otrávenou verzi důvěryhodného balíčku. Spustí se v okamžiku, kdy ji build nainstaluje, jako u červa Shai-Hulud v npm.
Upstream projekty se zadními vrátky
Přispěvatel si v open source projektu postupně získá důvěru a pak do vydání propašuje škodlivý kód, který převezmou navazující distribuce a produkty, jako u zadních vrátek v xz utils.
Typosquatting a dependency confusion
Balíčky s názvy podobnými oblíbeným balíčkům zachytávají překlepy. Dependency confusion jde ještě dál: místo interního balíčku firmy se nainstaluje veřejný balíček se stejným názvem.
Kompromitované komponenty CI/CD
Útočník převezme GitHub Action nebo jiný nástroj buildu a každá pipeline, která ho používá, spustí kód útočníka s tajnými klíči na dosah, jako u tj-actions a Codecov.
Manipulace s buildem a artefakty
Změní se samotný build nebo se artefakt vymění mezi buildem a nasazením, takže i čistý zdrojový kód vytvoří kompromitované vydání, jako u SolarWinds.
Příklady útoků na dodavatelský řetězec
SolarWinds je nejznámější útok na dodavatelský řetězec: škodlivý kód vložený při buildu a dodaný zákazníkům jako běžná aktualizace. Nejnovější útoky místo toho míří na registry balíčků a pipeline CI, kde jeden kompromitovaný balíček nebo Action zasáhne každý build, který ho používá. Od nejnovějších:
tj-actions/changed-files
CISA oznámila, že každá verze této oblíbené GitHub Action byla tři dny kompromitována a tajné klíče se objevily v logech workflow. Workflow, která na ni odkazovala tagem, spustila kód útočníka.
Zadní vrátka v xz utils
Andres Freund našel zadní vrátka ve verzích xz 5.6.0 a 5.6.1, když si všiml, že přihlášení přes SSH spotřebovávají příliš mnoho CPU. Vrátka byla vložena přímo do upstream projektu.
Log4Shell
Chyba v Apache Log4j 2 umožnila útočníkovi, který ovládal logovanou zprávu, spustit libovolný kód, s hodnocením CVSS 10.0. Nejtěžší pro většinu týmů bylo zjistit, které aplikace obsahují log4j-core, obvykle jako závislost závislosti.
Codecov Bash Uploader
Útočníci upravili skript Bash Uploader, který týmy spouštěly ve svých pipeline CI, tak, aby posílal prostředí CI včetně přihlašovacích údajů, tokenů a klíčů na server mimo infrastrukturu Codecov. Běžel nepozorovaně od 31. ledna, dokud ho 1. dubna nenahlásil zákazník.
SolarWinds Orion
Útočníci měli dlouhodobý skrytý přístup k procesu buildu SolarWinds Orion a vložili škodlivý kód do vydání Orion 2019.4 až 2020.2.1 HF1, která zákazníci instalovali jako běžné aktualizace. CISA v reakci vydala mimořádnou směrnici.
Red team vs blue team
Jak útoky na dodavatelský řetězec fungují, fázi po fázi
Každá fáze slovy útočníka a obrana, která na ni odpovídá.
Fáze 1 z 3
Průzkum
Cíl znát nepotřebujeme. Vybereme balíček a cíle se vyberou samy.
Red team
Vsadíme na závislosti, které má každý
Jejich lockfile nepotřebujeme. Oblíbené balíčky sedí hluboko ve stromu tranzitivních závislostí téměř všeho a většina týmů neumí říct, které z nich dodává. Veřejné stopy výběr zúží: verze v bundlech JavaScriptu a v hlavičkách HTTP, veřejné repozitáře a image kontejnerů. A to, co jejich build stáhne mimo lockfile, třeba binárku stahovanou skriptem postinstall nebo vrstvy pod jejich základním image, jejich skener nikdy neviděl, takže to nikdo nezáplatuje.
Blue team
Znejte každou závislost, kterou každý build stáhl
CRACI vidí provoz přicházející do každého buildu a zaznamenává každý balíček a soubor, který build stáhne, včetně skrytých závislostí, které nástroje založené na lockfilu přehlížejí, v jakékoli hloubce stromu tranzitivních závislostí. Vaše SBOM pochází z buildu, který byl dodán, takže máte seznam, který útočník nikdy nepotřeboval, dřív, než ho někdo začne hledat.
SBOM z doby buildu →Red team
Vyrazíme, jakmile vyjde nové CVE
Nové bezpečnostní upozornění nám přesně řekne, které verze jsou zranitelné. Sestavíme exploit, proskenujeme vše, co odpoví, a sken nám prozradí, o koho jde. Začínáme ještě ten den, zatímco jejich tým se ve vlákně na Slacku teprve ptá: „Týká se nás to?“
Blue team
„Týká se nás to?“ zodpovězeno ze záznamu buildu
CRACI průběžně znovu vyhodnocuje monitorované SBOM podle nových dat o zranitelnostech. Historie buildů ukazuje, které buildy obsahovaly zranitelnou závislost, přímou nebo tranzitivní, takže víte, kam se dostala a jak dlouho.
Týká se nás to? →Fáze 2 z 3
Proniknutí
Zneužijeme chybu dřív, než ji záplatují, nebo chybu vynecháme a svezeme se jejich pipeline.
Red team
Útok vygenerujeme v den zveřejnění
AI promění bezpečnostní upozornění a diff záplaty ve funkční útok dřív, než jejich bezpečnostní tým provede triáž tiketu. Zveřejnění je náš startovní výstřel. Jejich plánování sprintu je až příští týden.
Blue team
Přestaňte dodávat zranitelnou verzi
Kontrolní brány politik (policy gates) mohou zablokovat jakýkoli build, který obsahuje konkrétní CVE, takže zranitelná verze se přestane dodávat ve chvíli, kdy se tak rozhodnete, ať je ve stromu jakkoli hluboko.
Náprava CVE →Red team
Přepíšeme jeden tag a běžíme v tisíci pipeline
Workflow důvěřují tagům jako @v4 a tagy se dají přesunout. Stačí kompromitovat jednu oblíbenou GitHub Action a každé workflow, které ji používá, spustí náš kód s jejich tajnými klíči na dosah.
Blue team
Vězte přesně, kterou Action každý build spustil
CRACI zaznamenává GitHub Actions, které workflow spouští, do SBOM buildu, připnuté na commit, který skutečně běžel. Když je Action kompromitována, vidíte, které buildy spustily škodlivý kód, místo abyste hádali podle tagu.
Kontrolní seznam bezpečnosti CI/CD →Fáze 3 z 3
Únik
Vezmeme tajné klíče a zůstaneme pro další.
Red team
Ozveme se domů z jejich CI
Škodlivé vydání balíčku spustí svůj instalační skript uvnitř jejich buildu, kde jsou tokeny a cloudové přihlašovací údaje. Runnery CI se obvykle dostanou na celý internet, takže tajné klíče odejdou na náš server dřív, než kdokoli zjistí, že je balíček škodlivý.
Blue team
Build se dostane jen tam, kam potřebuje
Egress policy nastavená na výchozí zákaz (default deny) pustí build ke zdrojům balíčků a cílům publikování a vše ostatní zablokuje. Malware, který posílá vaše tajné klíče na hostitele útočníka, je zablokován, i když jste pacientem nula útoku, jaký ještě nikdo neviděl, a o porušení politiky dostanete upozornění.
Egress policy →Red team
Zůstaneme na runneru pro další job
Dlouhodobě běžící vlastní (self-hosted) runnery jsou dar: stačí něco zasadit do pracovního adresáře nebo cache nástrojů a počkat, až za námi přijde další job a s ním další sada tajných klíčů.
Blue team
Jeden izolovaný virtuální stroj na každý job
Každý job CRACI běží ve vlastním izolovaném virtuálním stroji, takže nic, co jeden job zanechá, nečeká na další. Navíc nemáte žádnou flotilu runnerů, kterou byste museli záplatovat a zabezpečovat.
Spravované vs vlastní runnery →Po zveřejnění
Závod začíná, když je bezpečnostní upozornění veřejné
Útočník nepotřebuje vědět, že danou závislost používáte. Zkouší exploit všude a sleduje, co odpoví. Váš tým potřebuje vědět, kam se ta závislost dostala. Rozdíl je v tom, zda to musíte hledat, a takových závodů přibývá každým rokem: podívejte se, kolik CVE se zveřejní každý den.
Red team
- Bezpečnostní upozornění zveřejněno
- Exploit vygenerován
- Sken všeho, co běží na zranitelné verzi
- Uvnitř každého nalezeného cíle, včetně vás
Blue team bez záznamu buildu
- Bezpečnostní upozornění zveřejněno
- „Týká se nás to?“
- Grep v repozitářích, lockfilech a image
- Nalezení tranzitivní kopie, kterou nikdo neuvedl
- Zjištění, která vydání ji dodala
- Záplata
Blue team s CRACI
- Bezpečnostní upozornění zveřejněno
- Monitorované SBOM znovu vyhodnoceny
- Historie buildů ukáže buildy a období
- Kontrolní brána politik zablokuje nové buildy s tímto CVE
Jak předcházet útokům na softwarový dodavatelský řetězec
Žádná jednotlivá kontrola nezastaví každý útok na dodavatelský řetězec. Vrstvěte tato opatření a každá z fází výše bude těžší. Podrobně o pipeline najdete v kontrolním seznamu bezpečnosti pipeline CI/CD.
- Vězte, co každý build dodává. Uchovávejte SBOM pro každý build, včetně tranzitivních závislostí a všeho, co se stáhne mimo lockfile. Sken repozitáře není záznamem vydání.
- Sledujte, co bylo dodáno, ne jen výchozí větev. Kontrolujte vydané buildy znovu podle nových bezpečnostních upozornění a uchovávejte historii buildů, která vám řekne, odkdy jste byli vystaveni.
- Připínejte závislosti a Actions. Používejte lockfily a GitHub Actions připínejte na plný SHA commitu. GitHub to označuje za jediný způsob, jak používat action jako neměnné vydání.
- Zastavte zranitelné verze už v buildu. Podmiňte buildy zranitelnostmi, o kterých jste rozhodli, že se nesmějí dodat, aby se oprava nemohla potichu vrátit.
- Výchozí zákaz odchozího provozu v CI. Pusťte buildy jen ke zdrojům balíčků a cílům publikování, aby škodlivý kód nemohl tajné klíče odeslat ven, ani při útoku, jaký ještě nikdo neviděl.
- Izolujte joby a omezte tajné klíče. Spouštějte každý job na novém izolovaném stroji a dejte každému jobu jen tokeny a oprávnění, které potřebuje.
- Ověřte artefakty před nasazením. Podepisujte původ (provenance) v době buildu a kontrolujte, že to, co běží v produkci, je přesně to, co bylo sestaveno.
- Po incidentu vyměňte tajné klíče. Pokud ve vaší pipeline běžel kompromitovaný balíček nebo Action, považujte každý tajný klíč, ke kterému se mohl dostat, za vyzrazený. To doporučila CISA po kompromitaci tj-actions.
Oni ten seznam nepotřebují. Vy ano.
Útočníci sledují každé bezpečnostní upozornění a v den zveřejnění zranitelnosti zkoušejí exploit na všech. Seznam vašich závislostí nikdy nepotřebovali. Vy ano. CRACI dá vašemu týmu tento seznam, převzatý přímo z buildu, a zavře dveře, na které útočníci spoléhají: otevřený odchozí provoz a sdílené runnery.
Útoky na dodavatelský řetězec: časté dotazy
Co je útok na softwarový dodavatelský řetězec?
Útok na kód, nástroje nebo služby, ze kterých se produkt sestavuje, například open source balíček, komponentu CI/CD nebo systém buildu, a ne na samotný produkt. Jedna kompromitace zasáhne každou organizaci, která zasaženou komponentu používá.
Jaké jsou příklady útoků na softwarový dodavatelský řetězec?
Červ Shai-Hulud (od roku 2025) se šířil přes infikované balíčky npm a kradl tajné klíče z CI. Kompromitace tj-actions/changed-files (CVE-2025-30066) převzala oblíbenou GitHub Action. Zadní vrátka v xz utils (CVE-2024-3094) byla propašována do upstream knihovny pro kompresi. Log4Shell (CVE-2021-44228) zneužil chybu v široce používané logovací knihovně pro Javu. Bash Uploader od Codecov (2021) byl upraven tak, aby posílal přihlašovací údaje z CI na externí server, a SolarWinds Orion (2020) dodal škodlivý kód vložený při buildu.
Jaký je nejznámější útok na dodavatelský řetězec?
SolarWinds. V roce 2020 útočníci se skrytým přístupem k procesu buildu SolarWinds Orion vložili do jeho vydání škodlivý kód a zákazníci ho nainstalovali jako běžnou aktualizaci. Ukázalo se, že čistý zdrojový kód nestačí: důvěryhodný a ověřitelný musí být i samotný build.
Vědí útočníci, jaké závislosti naše firma používá?
Obvykle ne a ani to vědět nepotřebují. Většina útoků míří na balíček, ne na firmu: jakmile vyjde bezpečnostní upozornění, útočníci zkoušejí exploit na všem, co by mohlo používat zranitelnou verzi, a sledují, co odpoví. Veřejné stopy, například verze v bundlech JavaScriptu nebo v open source repozitářích, jim pomáhají zamířit. Asymetrie spočívá v tom, že vy ten seznam potřebujete: abyste věděli, zda se vás to týká, musíte znát, co každý build dodal, včetně toho, co stáhl mimo lockfile.
Jak útokům na softwarový dodavatelský řetězec předcházet?
Žádná jednotlivá kontrola nezastaví všechny. Uchovávejte SBOM toho, co každý build dodává, a monitorujte ji podle nových bezpečnostních upozornění, připínejte závislosti a GitHub Actions, blokujte zranitelné verze už v buildu, omezte, kam se joby CI mohou připojit, izolujte joby a omezte jejich tajné klíče a ověřujte, že nasazené artefakty jsou ty, které jste sestavili.
Jak se chránit před útoky na dodavatelský řetězec v npm?
Commitujte lockfile a v CI z něj instalujte a tam, kde je build nepotřebuje, vypněte instalační skripty (v npm --ignore-scripts). Uchovávejte záznam o tom, které verze balíčků každý build skutečně nainstaloval, abyste mohli rychle ověřit situaci, když je ohlášena nová vlna, jako je Shai-Hulud. Omezte, kam se joby CI mohou připojit, aby škodlivý instalační skript nemohl odeslat vaše tokeny ven, a vyměňte každý token, ke kterému se infikovaná verze mohla dostat.
Co tu znamená red team vs blue team?
V bezpečnostních cvičeních hraje red team útočníka a blue team se brání. Tato stránka používá stejné rozdělení: každá fáze útoku na dodavatelský řetězec slovy útočníka a k ní odpověď obrany.
Odhaluje CRACI škodlivé balíčky?
Známé ano. Škodlivé vydání se zveřejněným CVE, jako jsou zadní vrátka v xz, je označeno jako každá jiná zranitelnost a kontrolní brána politik může zablokovat buildy, které ho obsahují. CRACI neanalyzuje chování balíčků ani nehodnotí jejich reputaci, takže zcela nový škodlivý balíček zůstane neoznačený, dokud nevyjde bezpečnostní upozornění. K tomu slouží egress policy: při výchozím zákazu se build dostane jen k hostitelům, které potřebuje, takže balíček nemůže odeslat vaše tajné klíče ven, ani při útoku, jaký ještě nikdo neviděl.