Své závislosti už skenujete. Tohle skener nevidí.

Co váš současný stack dělá dobře

Pokud máte nastavené SCA a generování SBOM, máte za sebou tu těžkou organizační práci: závislosti se sledují, bezpečnostní upozornění se dostávají k vývojářům a když se někdo zeptá, máte soubor, který můžete předat. To si ponechte.

• Graf závislostí GitHubu a Dependabot má mnoho týmů zapnuté ve výchozím nastavení. GitHub popisuje graf závislostí jako „a summary of the manifest and lock files stored in a repository and any dependencies that are submitted for the repository using the dependency submission API“ (souhrn manifestů a lockfilů uložených v repozitáři a všech závislostí odeslaných pro repozitář přes dependency submission API). Upozornění Dependabot na něm stavějí a dají vám vědět, když vyjde nové bezpečnostní upozornění nebo když se změní váš graf závislostí.
• Komerční SCA, například Snyk, také generuje SBOM. Jeho příkaz snyk sbom čte soubory manifestů a jejich lockfily a vytváří výstup ve formátu CycloneDX nebo SPDX. K září 2026 ho Snyk v dokumentaci uvádí jako „available only to customers on Snyk Enterprise plans“ (dostupný jen zákazníkům s plány Snyk Enterprise).
• Open source generátory, jako jsou Syft, Trivy a cdxgen, jsou zdarma, rychlé a snadno se přidají do CI. Syft se popisuje jako nástroj „for generating a Software Bill of Materials (SBOM) from container images and filesystems“ (pro generování SBOM z image kontejnerů a souborových systémů).

Tyto nástroje jsou nejsilnější v rychlé zpětné vazbě v pull requestu, širokém pokrytí ekosystémů a v postupu nápravy, který vývojáři už znají. To CRACI dnes nenahrazuje. Jeho sledování zranitelností agreguje nálezy napříč buildy a repozitáři a znovu vyhodnocuje monitorované SBOM, jakmile se objeví nové zranitelnosti. Bezpečnostní týmy mohou provést triáž nálezů a poslat je správnému týmu. Kontrolní brány politik (policy gates) mohou build zablokovat; webhooky pro zranitelnosti jsou v plánu vývoje.

Skener versus záznam

Každý z výše uvedených nástrojů je skener. Nasměrujete ho na strom zdrojového kódu, lockfile nebo image kontejneru a on odvodí, co do něj vstoupilo. To funguje, když soubory řeknou vše. Těžší je to, když neřeknou:

• Repozitář nemá lockfile, takže o verzích se rozhoduje až při instalaci.
• Build obnovuje balíčky z cache CI, kterou žádný manifest nezmiňuje.
• Krok buildu stahuje nástroj, balíček operačního systému nebo binárku napřímo.
• Instalační hook npm nebo build skript v Rustu stáhne během instalace další kód, cestou, kterou využil červ Shai-Hulud.
• Build kontejneru stáhne základní image a jeho vrstvy operačního systému, které žádný jazykový lockfile neuvádí.
• To, co dodáváte, je zkompilovaná binárka a manifest vedle ní neuvádí téměř nic.

CRACI zaznamenává: vidí provoz, který skenery nevidí. Spouští build na vlastním runneru kompatibilním s GitHub Actions a proxy, která rozumí balíčkům, během běhu jobu sleduje provoz ke zdrojům balíčků, takže se tyto skryté závislosti dostanou do SBOM. Balíčky obnovené z cache si své důkazy nesou dál. Neexistuje příkaz craci scan ./dir, protože zpětné skenování adresáře je přesně ten krok, kterému se CRACI vyhýbá.

Na čem sken závisí

Výstup skeneru závisí na nástroji a na tom, na co ho nasměrujete. Syft, Trivy, cdxgen, Microsoft SBOM Tool, export grafu závislostí GitHubu i Socket CLI sestavují seznam z toho, co dokážou přečíst. Níže uvedené vzorce vycházejí z toho, jak tyto nástroje podle dokumentace fungují.

Žádnou komponentu nenajdou všechny nástroje

Každý generátor sám rozhoduje, co považuje za komponentu a kterým souborům věří, takže stejný checkout dá každému z nich jiný seznam. Export grafu závislostí GitHubu funguje zase jinak: vychází z toho, co GitHub o repozitáři ví, ne ze souborů, které čte skener, a čte výchozí větev, ne připnutý commit.

Bez lockfilu žádné závislosti

Express 5.2.1 necommituje žádný lockfile. Generátor, který vyřešuje závislosti z lockfilů nebo z nainstalovaného stromu, nemá na čistém checkoutu před sebou ani jedno, takže do dokumentu se nedostane žádná ze závislostí npm deklarovaných v package.json. Žádný z nástrojů není rozbitý. O tom, zda SBOM obsahuje vůbec nějaké závislosti, nerozhoduje nástroj. Rozhoduje to, zda někdo předtím spustil instalaci.

Jeden přepínač změní odpověď

Výchozí sken adresáře v Syftu uvádí, co projekt deklaruje, ne co je nainstalováno na disku. Na nainstalovaném checkoutu stejného vydání express rozhoduje jeden přepínač katalogizátoru o tom, zda se nainstalované balíčky npm v seznamu vůbec objeví. Stejný nástroj, stejná verze, stejný strom.

Produktem je binárka

Repozitář anthropics/claude-code ve verzi v2.1.259 nemá žádný manifest závislostí ani lockfile. Jeho publikovaný balíček npm deklaruje nula závislostí za běhu a obaluje předem sestavenou nativní binárku prostřednictvím osmi platformních balíčků. @openai/codex 0.149.1 má stejnou podobu. Čtečka manifestů nemá téměř co popsat, zatímco program, který běží, je zkompilovaná binárka, takže to, co který nástroj vrátí, vypovídá víc o nástroji než o projektu.

Stejný balíček, různé verze

Když dva nástroje najdou totéž, ne vždy se shodnou na tom, co to je. Jeden může GitHub Action připnout na SHA commitu, zatímco druhý uvede tag vydání. Vyhledání zranitelností podle špatné verze vrátí sebejistou špatnou odpověď.

Kam CRACI zapadá vedle vašeho SCA

SCA si u pull requestů ponechte. Je to správné místo, kde zachytit zranitelnou verzi před sloučením. CRACI přidejte tam, kde se otázka týká buildu, ne diffu:

• Co toto vydání skutečně obsahovalo? Zaznamenaná SBOM pokrývá zdroje npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk a Git a k tomu předvolby pro stahování, včetně tranzitivních závislostí. Fungují i zrcadla npm a PyPI v JFrog Artifactory.
• Můžeme seznamu věřit? Každý job a každá cache má stav úplnosti, takže neúplný záznam je vidět, místo aby byl potichu chudý.
• Týká se nás nové bezpečnostní upozornění? Monitorované SBOM se znovu vyhodnocují, jakmile jsou zveřejněny nové zranitelnosti, a nálezy se agregují napříč buildy a repozitáři.

SBOM se stahuje ve formátu CycloneDX přes veřejné REST API spolu se síťovým záznamem a původem (provenance) jobu, takže ji můžete předat jakémukoli nástroji, který čte CycloneDX, včetně SCA, které už používáte. Nastavení je jeden řádek ve workflow: změňte runs-on na craci. Dnes je podporovaným CI GitHub Actions; GitLab CI, Jenkins a další systémy CI jsou v plánu vývoje.

Inventář toho, co je kde nasazeno

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

Přečtěte si více o generování SBOM v době buildu a sledování zranitelností.

Co CRACI nahrazuje a co ne, najdete na stránce co CRACI nahrazuje.