CRACI vs vlastní stack SBOM

Stručná odpověď

Vlastní stack ze Syft nebo Trivy, Grype, Dependency-Track, Cosign a Renovate je bez licenčních poplatků, běží kdekoli a schopnému platformnímu týmu dává plnou kontrolu. CRACI je spravovaný runner pro GitHub Actions, který zaznamenává, co každý build stáhl, řídí, kam se může připojit, monitoruje, co bylo dodáno, a exportuje důkazy. Rozdíl není tolik ve funkcích jako v tom, odkud SBOM pochází a kdo udržuje spoje mezi nástroji. Pokud stavíte na GitLabu, Jenkins nebo Windows, nebo vše musí běžet na vaší vlastní infrastruktuře, je dnes poctivým doporučením vlastní řešení.

Jak stack vypadá

Kompletní řešení na vlastní pěst má obvykle sedm vrstev. Každá je skutečný projekt s vlastní údržbou.

1. Generování. Syft („generování softwarového kusovníku (SBOM) z image kontejnerů a souborových systémů“), Trivy, cdxgen (projekt OWASP, který vytváří CycloneDX BOM „ze zdrojového kódu a image kontejnerů“) nebo Microsoft SBOM Tool, který zapisuje SPDX a na příkazové řádce očekává složku s výstupem buildu, název balíčku, verzi a dodavatele.
2. Párování. Grype skenuje image, souborové systémy a SBOM s hodnocením EPSS, KEV a rizika. OSV-Scanner páruje lockfily, SBOM a image kontejnerů s databází OSV.dev.
3. Správa. OWASP Dependency-Track načítá CycloneDX SBOM a dlouhodobě je monitoruje. Jeho API server potřebuje alespoň 2 GB RAM a 2 jádra CPU (doporučeno 8 GB a 4 jádra) a jeho dokumentace odkazuje produkční nasazení na Docker Compose se samostatnou databází.
4. Podepisování. Cosign podepisuje image, bloby a atestace SBOM, s podepisováním bez klíčů přes Fulcio a transparentním logem Rekor. GitHub artifact attestations stavějí na Sigstore a poskytují původ na úrovni SLSA v1.0 Build Level 2.
5. Aktualizace. Renovate nebo Dependabot otevírají pull requesty, aby závislosti zůstaly aktuální.
6. Kontrola odchozího provozu. StepSecurity Harden-Runner umí auditovat nebo blokovat odchozí spojení z jobů GitHub Actions. Jeho úroveň Community je zdarma pro veřejné repozitáře na runnerech hostovaných na GitHubu; privátní repozitáře a vlastní (self-hosted) runnery vyžadují úroveň Enterprise. Alternativou je vlastní proxy a pravidla firewallu kolem vlastních runnerů.
7. Reporting. Někdo musí výstupy všeho výše uvedeného převést na dokumenty, které potřebuje auditor, zákazník nebo technická dokumentace pro CRA.

Náklady jsou ve spojích

Výběr generátoru je výběr jeho slepých míst

Nasměrujte několik generátorů SBOM na stejný repozitář a neshodnou se na tom, co obsahuje. Každý čte jinou sadu souborů a jinak je vyhodnocuje, takže seznam komponent, který dostanete, je vlastností zvoleného nástroje stejně jako projektu. Pole dodavatele podle NTIA ukazuje totéž z druhé strany: většina generátorů pro něj nemá zdroj, takže zůstane prázdné bez ohledu na to, co repozitář obsahuje.

Žádný z těchto nástrojů není rozbitý. Každý dělá jiné, zdokumentované rozhodnutí o tom, co se počítá jako komponenta a kterým souborům věřit. Vlastní stack ale zdědí rozhodnutí nástrojů, které jste vybrali, a zbytek pipeline (párování, monitorování, reporting) může být jen tak úplný jako tento první krok.

Lepidlo je na vás

Každý nástroj má vlastní kadenci vydávání, databázi zranitelností, výstupní formát a konfiguraci. Někdo musí připínat verze, aktualizovat databáze, záplatovat Dependency-Track a jeho databázi, rotovat podpisové identity, rozhodovat, která SBOM kam patří, a všimnout si, když některý krok potichu začne produkovat méně. To je průběžná platformní práce, ne jednorázové nastavení.

I nástroje jsou závislosti

Bezpečnostní nástroje běží uvnitř vašich buildů s přístupem k vašim tajným klíčům, takže patří do vašeho modelu hrozeb. V březnu 2026 zveřejnila Aqua Security bezpečnostní upozornění popisující, jak byly kompromitované přihlašovací údaje použity k vydání škodlivého releasu Trivy a k vynucenému přepsání (force-push) většiny tagů trivy-action na kód kradoucí přihlašovací údaje po dobu zhruba 12 hodin. Aqua incident veřejně zdokumentovala a mohl postihnout jakýkoli široce používaný projekt. Ukazuje, proč na kontrole odchozího provozu na runneru záleží: politika default-deny omezuje, kam může kompromitovaný krok posílat data, i když ne každý kanál (upozornění popisuje i záložní postup, který vytvářel repozitáře na GitHub účtu oběti).

Kdy je vlastní řešení správná volba

• Vaše CI není GitHub Actions. CRACI dnes podporuje pouze GitHub Actions, GitLab CI a Jenkins jsou v plánu vývoje. Týmy na GitLabu, Jenkins a CircleCI mohou provozovat všechny výše uvedené open source nástroje.
• Buildy sestavujete na Windows nebo macOS. Runnery CRACI jsou dnes linuxové (x86-64 a ARM64); Windows a macOS jsou v plánu vývoje.
• Vše musí běžet na vaší infrastruktuře. CRACI dnes provozuje spravované runnery na evropské infrastruktuře, runnery hostované zákazníkem jsou v plánu vývoje pro Enterprise.
• Máte platformní tým, který to chce vlastnit. Pokud je údržba stacku záměrnou investicí a už Dependency-Track dobře provozujete, ponechte si ho.
• Potřebujete jednu SBOM pro jeden dotazník. Pro občasný požadavek s nízkými nároky může stačit generátor spuštěný ručně.

Co CRACI nahradí a co ne

CRACI pokrývá několik vrstev na jednom místě a vychází z buildu. Změníte runs-on na craci a běhy se dál zobrazují v rozhraní GitHubu. Proxy, která rozumí balíčkům, zaznamenává, co každý job stahuje ze zdrojů npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk a Git, a také z předvoleb pro stahování, a důkazy o závislostech putují spolu s cache CI. Každý job a každá cache dostane stav úplnosti: Complete, Complete with connections, Incomplete, Unavailable nebo Not recorded.

• Generování: CycloneDX a SPDX ze zaznamenaného buildu, včetně tranzitivních závislostí.
• Monitorování: nálezy agregované napříč buildy a repozitáři, monitorované SBOM se průběžně znovu vyhodnocují.
• Původ: API vrací SBOM, síťové záznamy a údaje o původu (provenance). CRACI původ nepodepisuje.
• Odchozí provoz: politika pro každý job s 24 vestavěnými předvolbami zdrojů softwaru, ověřená před spuštěním jobu, při selhání vše zablokuje a při porušení odešle upozornění.
• Export: SBOM jako CycloneDX nebo SPDX, včetně zranitelností; bez exportu reportů.

Nenahradí všechno. Blocklisty balíčků jsou v plánu vývoje. Pokud potřebujete podepsaný původ, ponechte si Cosign nebo GitHub artifact attestations. Renovate nebo Dependabot mají stále smysl, abyste udrželi aktuální všechny závislosti, nejen ty zranitelné. Pokud váš bezpečnostní tým pracuje v Dependency-Track, CycloneDX SBOM se stáhne přes REST API CRACI a může do něj proudit.

Inventář toho, co je kde nasazeno

Inventář v CRACI přesně ukazuje, které verze softwaru jsou nasazeny ve kterých produktech, a to globálně. Když se objeví nová zranitelnost, uvidíte, které produkty používají dotčenou verzi, místo abyste to skládali dohromady z poznámek k vydání a tabulek.

Pro Cyber Resilience Act

CRA požaduje, aby výrobci „identifikovali a dokumentovali zranitelnosti a komponenty obsažené v produktech s digitálními prvky, mimo jiné vypracováním softwarového kusovníku“ (příloha I, část II). Oznamování aktivně zneužívaných zranitelností platí od září 2026, s 24 hodinami na první oznámení. Vlastní stack to může podporovat, pokud někdo vlastní stopu důkazů od každého vydání zpět k jeho SBOM. CRACI automatizuje významnou část přehledu o softwarovém dodavatelském řetězci a důkazů, které firmy potřebují pro svůj širší proces souladu s CRA, a připraví obsah oznámení podle CRA, který pak sami podáte. Ať zvolíte kteroukoli cestu, rozhodnutí o tom, co je aktivně zneužíváno, zůstává na vašem týmu. Viz soulad s CRA a generování SBOM z doby buildu.