Proč bezpečnost dodavatelského řetězce patří do vašeho CI

1:53

Váš produkční build není build z vašeho notebooku

Většina týmů předpokládá, že kód, který otestovali lokálně, je kód, který se dodá. Zdrojový kód je stejný, software ale často ne. Build je zdrojový kód plus vše, co stáhne, a vše, co ho v době běhu obklopuje, a jen velmi málo z toho je pevně dané.

Nepřipnuté závislosti se vyřeší pokaždé jinak

Rozsahy verzí závislostí jsou běžné. V npm ^1.0.4 přijme jakékoli pozdější vydání 1.x, takže stejný package.json nainstaluje v různé dny různé verze. Lockfile je připne, ale jen pokud je commitnutý a build ho respektuje: npm ci selže, když se lockfile a package.json neshodují, zatímco npm install může lockfile potichu aktualizovat. Spousta projektů ho necommituje vůbec. Express 5.2.1, široce používaný webový framework, ho nemá.

I připnutá verze je jen název, ne soubor. Dokumentace pipu vysvětluje, že samotné připnutí verze nezabrání indexu balíčků poskytnout pro stejnou verzi jiné soubory, a proto nabízí režim kontroly hashů.

Čas mění vstupy

Registry se mezi buildy mění. Vycházejí nové verze, staré se stahují a rozsah, který se v pondělí vyřešil bezpečně, si v úterý může vzít kompromitované vydání. Posouvají se i tagy kontejnerů: vlastní dokumentace Dockeru varuje, že „tagy image jsou měnitelné, což znamená, že vydavatel může tag aktualizovat tak, aby ukazoval na nový image“, takže FROM node:20 není z měsíce na měsíc stejný base image, pokud ho nepřipnete podle digestu.

Čas se dostává i do výstupu. Projekt Reproducible Builds označuje časová razítka za „největší zdroj problémů s reprodukovatelností“, protože tolik nástrojů zapisuje aktuální datum a čas do toho, co sestavují.

Prostředí je jiné

• Operační systém a architektura. Notebook s macOS a ARM a CI runner s Linuxem a x86-64 nainstalují pro stejný balíček různé předkompilované binárky. Mnoho nástrojů pro npm se dnes dodává jako balíčky pro konkrétní platformu, které obalují zkompilovanou binárku.
• Toolchainy. Verze kompilátoru, runtime a správce balíčků se mezi stroji rozcházejí, pokud není připnutá každá z nich.
• Cache. Váš stroj a vaše CI obnovují různé cache, vytvořené v různou dobu z různých vyřešení závislostí.
• Instalační skripty a kroky buildu. Post-install hooky, setup akce a build skripty stahují během buildu nástroje a data. Nic z toho se neobjeví v manifestu.
• Konfigurace. Proměnné prostředí, příznaky buildu a tajné klíče existují v CI a nikde jinde.

Projekt Reproducible Builds definuje reprodukovatelný build jako build, u kterého „při stejném zdrojovém kódu, prostředí buildu a instrukcích pro build může kdokoli vytvořit bit po bitu identické kopie všech určených artefaktů“. Tato definice ukazuje, kolik toho musí zůstat konstantní. Buildy většiny týmů se tam nedostanou a ty, které ano, si to tvrdě vypracovaly. Dokud tam nejste, jediný spolehlivý záznam toho, co bylo dodáno, je ten, který vznikl během běhu buildu, ze kterého vydání pochází.

1:18

Kde můžete kontrolovat a co které místo vidí

Bezpečnostní kontroly mohou běžet na čtyřech místech. Každé má svůj úkol, ale jen jedno z nich vidí build, který skutečně vytvořil vaše vydání.

Sken repozitáře hlásí, co projekt deklaruje. Sken hotového artefaktu hlásí, co v něm dokáže rozpoznat. Ani jeden neviděl build probíhat. Express 5.2.1 necommituje žádný lockfile, takže skener nasměrovaný na čistý checkout nemá k dispozici žádné npm závislosti projektu, které by vyřešil, a hlásí cokoli jiného, co rozpozná. Nasměrujte stejný nástroj na nainstalovanou kopii téhož repozitáře a jeden příznak catalogeru odpověď opět změní. Výsledek závisí na tom, co bylo nainstalováno před skenem, a to je přesně ta část, kterou sken neřídí. Proč se skeny rozcházejí a co mění záznam buildu, popisuje stránka o SBOM z doby buildu.

Pipeline je cílem sama o sobě

V CI se potkává zdrojový kód, závislosti a tajné klíče, a proto se vyplatí na něj útočit.

• tj-actions/changed-files (2025). Široce používaná GitHub Action byla kompromitována a vypisovala tajné klíče CI do logů buildu.
• Codecov Bash Uploader (2021). Upravený skript spouštěný v CI zákazníků odesílal proměnné prostředí na server útočníka.
• Červ Shai-Hulud v npm (2025). Kompromitované balíčky při instalaci kradly přihlašovací údaje a používaly je k publikování dalších kompromitovaných balíčků.
• xz utils (2024). Zadní vrátka byla ukrytá v release tarballech a v samotném procesu buildu, ne ve viditelném zdrojovém kódu.

Každý z těchto útoků spustil kód během buildu nebo instalace. Sken repozitáře spuštěný před nimi ani sken artefaktu spuštěný po nich by neviděl, co proces buildu udělal. Kontroly, které sledují a omezují, kam se job může dostat, musí být tam, kde job běží. To platí i pro interní a méně viditelné aplikace: útoky jako tyto míří na pipeline a balíčky, které sdílí každá aplikace, ne na to, co aplikace dělá. Viz bezpečnost dodavatelského řetězce pro interní software a software s nízkým rizikem.

Víc kódu, víc závislostí, méně lidí, kteří je čtou

AI agenti pro psaní kódu píší a mění kód rychleji, než týmy stihnou zkontrolovat každý řádek, a cestou přidávají závislosti. Také jmenují balíčky, které neexistují: studie z konference USENIX Security 2025, která zkoumala 576 000 vygenerovaných ukázek kódu, zjistila podíl halucinovaných balíčků nejméně 5,2 % u komerčních modelů a 21,7 % u open source modelů. Útočník, který si jeden z těchto názvů zaregistruje, se nainstaluje do dalšího buildu, který mu důvěřuje.

Každá změna, ať ji napsal kdokoli nebo cokoli, prochází na cestě do produkce buildem. Proto je build jediným kontrolním bodem, který nezávisí na tom, že se na něco někdo podíval.

Důkazy musí popisovat, co bylo dodáno

Předpisy i zákazníci žádají důkazy, ne záměry. EU Cyber Resilience Act požaduje, aby výrobci identifikovali a dokumentovali komponenty ve svých produktech a po dobu podpory produktu řešili jejich zranitelnosti. SBOM vygenerovaná z manifestu popisuje, o co projekt žádal. SBOM zaznamenaná z buildu popisuje, co se dostalo do vydání, za které odpovídáte. Když je zveřejněna nová zranitelnost, ta druhá vám řekne, která vydání jsou zasažena. Přečtěte si, co CRA požaduje.

Co by mělo znamenat „v CI“

Spouštět skener jako krok CI je začátek, ale stále se tím díváte na soubory až poté, co dorazily. „V CI“, pokud se to dělá pořádně, znamená:

1. Zaznamenávejte, neodvozujte. Zachyťte každý balíček a každé stahování, které job skutečně provede, včetně tranzitivních závislostí a všeho obnoveného z cache.
2. Uveďte, jak úplný záznam je. SBOM by měla říkat, zda pokrývá vše, co job stáhl, nejen vypisovat, co našla.
3. Řiďte odchozí provoz. Rozhodněte, ke kterým hostitelům se job smí připojit, a zbytek zastavte dřív, než se kompromitovaná závislost stihne ozvat domů.
4. Sledujte i po vydání. Při objevení nových zranitelností znovu kontrolujte, co bylo dodáno, a nálezy převádějte na opravy.

Přesně to dělá CRACI. Je to runner pro vaše joby GitHub Actions, takže zaznamenává, co každý build stáhne, uplatňuje egress policy a monitoruje, co jste dodali. Přesun workflow je jeden řádek: runs-on: craci. Viz jak CRACI funguje.

Co CI nenahrazuje

Umístění bezpečnosti dodavatelského řetězce do buildu nečiní ostatní vrstvy volitelnými.

• Stroje vývojářů stále drží přihlašovací údaje a spouštějí instalační skripty. Chraňte i je; kompromitovaný notebook může pushnout kód dřív, než se spustí jakýkoli build.
• Code review a statická analýza nacházejí chyby ve vašem vlastním kódu, což záznam závislostí nedělá.
• Připínání verzí, lockfily a digesty jsou stále dobrou praxí. Zmenšují rozdíl mezi buildy; záznam buildu vám i tak řekne, co se stalo.

Build není jediné místo, kde kontrolovat. Je to jediné místo, které vidí software, který skutečně dodáváte.