Co generátory SBOM s otevřeným zdrojovým kódem přehlížejí

Jak vygenerovat SBOM jednotlivými nástroji

U každého nástroje stačí jeden příkaz pro zdrojový adresář nebo image kontejneru, s výstupem CycloneDX nebo SPDX:

# Syft: a source directory or a container image
syft ./my-project -o cyclonedx-json=sbom.cdx.json
syft my-image:latest -o spdx-json=sbom.spdx.json

# Trivy: a filesystem or a container image
trivy fs --format cyclonedx --output sbom.cdx.json .
trivy image --format spdx-json --output sbom.spdx.json my-image:latest

# cdxgen: the current directory, optionally with a project type
cdxgen -o bom.json .
cdxgen -t js -o bom.json .

Příkazy jsou ta snadná část. Co skončí v souboru, závisí na tom, co který nástroj čte, a nečtou totéž.

Co který nástroj čte

Nástroj	Zdrojový adresář	Image kontejneru	Dobré vědět
Syft	Výchozí sada catalogerů pro adresáře, která čte deklarované závislosti	Výchozí sada catalogerů pro image, která čte nainstalované balíčky	Catalogery se vybírají podle typu skenu. syft cataloger list ukáže, které běží, a --select-catalogers je přidává nebo odebírá.
Trivy	Lockfily, pro Node.js package-lock.json, yarn.lock, pnpm-lock.yaml a bun.lock	Pro Node.js soubory package.json pod node_modules	Vývojové závislosti vynechává, pokud nezadáte --include-dev-deps.
cdxgen	Primárně lockfily, které zahrnují vývojové závislosti; u Node.js navíc v kódu hledá importy	Podporováno	Typ projektu nastavte pomocí -t, abyste omezili, co hledá.

Proč se na stejném repozitáři neshodnou

Nasměrujte všechny tři na jeden commit a dostanete tři různé seznamy. Žádný z nástrojů není rozbitý. Každý se řídí svými zdokumentovanými pravidly:

• Bez lockfilu žádné závislosti. Express 5.2.1 necommituje žádný lockfile. Na čistém checkoutu nemá nástroj, který závislosti zjišťuje z lockfilů nebo nainstalovaných balíčků, ani jedno, takže se závislosti npm deklarované v package.json do SBOM nikdy nedostanou. Přesto zapíše platný dokument se vším ostatním, co rozpoznal.
• Nainstalované, nebo deklarované. Zda jste před skenem spustili instalaci, může znamenat víc než volba nástroje. Na nainstalované kopii stejného repozitáře rozhoduje jedno nastavení catalogeru v Syftu o tom, zda se nainstalované balíčky npm vůbec objeví.
• Vývojové závislosti. Trivy je ve výchozím stavu vynechává a cdxgen je zahrnuje, takže stejný lockfile dává dvě odpovědi na otázku „co je v tomto projektu“.
• Pojmenování a verze. Nástroje identifikují některé komponenty pod různými typy package URL nebo připnou GitHub Action ke commit SHA tam, kde jiný uvádí tag. Vyhledání zranitelností podle špatného identifikátoru dá sebejistou, ale chybnou odpověď.
• Žádný manifest. Repozitář anthropics/claude-code nemá žádný manifest závislostí a jeho balíček npm obaluje předem sestavenou binárku. To, co který nástroj vrátí, vypovídá víc o nástroji než o projektu.

Co všechny přehlížejí: skryté závislosti

Hlubší limit mají společný. Skener čte lockfile nebo výstup buildu a až dodatečně z toho odvozuje, co do něj vstoupilo. Cokoli build stáhl mimo tyto soubory, se do SBOM nikdy nedostane. To jsou skryté závislosti:

• Instalační hooky. Skripty npm preinstall a postinstall běží během instalace a mohou stáhnout další kód. Právě tak fungoval červ Shai-Hulud.
• Build skripty, například build skripty v Rustu, které si potřebné věci stahují během buildu.
• Základní image a jejich vrstvy operačního systému v buildu kontejneru, které žádný jazykový lockfile neuvádí.
• Balíčky obnovené z cache CI, které nemusí odpovídat aktuálnímu lockfilu. Viz co skrývá cache GitHub Actions.
• Build nástroje instalované kroky setup, s vlastními stromy závislostí.
• Tranzitivní verze vyřešené během buildu, když lockfile chybí, je zastaralý nebo ho frozen instalace nepoužije. Viz tranzitivní závislosti.

Dodatečný sken výstupu mezeru neuzavře. U hotové binárky, zejména u kompilovaného kódu, jako je Rust, skeneru nezbývá než hádat, co do ní vstoupilo. Komerční SCA skenery pracují se stejnými druhy souborů a mají stejná slepá místa. CRACI našlo zranitelné balíčky, které Snyk a Aikido nenahlásily, protože tyto komponenty nikdy nebyly v tom, co skenovaly.

Stejný problém v buildech Yocto popisuje článek proč skenery SBOM přehlížejí, co je v buildech Yocto.

I nástroje jsou součástí vašeho dodavatelského řetězce

Skener běží ve vašem CI s přístupem k vašemu kódu a často i k vašim tajným klíčům. V březnu 2026 popsalo bezpečnostní upozornění Aqua Security (CVE-2026-33634) škodlivé vydání Trivy v0.69.4 a podvržené tagy trivy-action a setup-trivy, které z runnerů CI kradly přihlašovací údaje. Akce skenerů připínejte k plným commit SHA a v upozornění si ověřte verze, které používáte.

Jak zkontrolovat vlastní SBOM

1. Spusťte dva generátory na stejném commitu a porovnejte package URL, které uvádějí.
2. Zkontrolujte, zda repozitář commituje lockfile a zda z něj CI instaluje pomocí frozen instalace.
3. Skenujte po kroku instalace i před ním a výsledky porovnejte.
4. Porovnejte seznam s tím, co podle logu buildu bylo staženo, včetně kroků setup a obnov z cache.

Pokud se seznamy liší, SBOM, kterou zveřejňujete, závisí na tom, jaký nástroj jste zrovna spustili, ne na tom, co jste vydali.

Zaznamenejte raději build

CRACI vidí provoz; skenery ne. Je to runner pro GitHub Actions, který vidí síťový provoz přicházející do každého buildu, takže jeho SBOM zaznamenává každý balíček, který job stáhl, v každé hloubce stromu, včetně skrytých závislostí a balíčků obnovených z cache CI. Není potřeba na nic mířit ani vybírat cataloger. Když záznam nemohl vidět vše, například proto, že job povolil nemonitorovaný provoz, SBOM to uvede svým stavem úplnosti.

Zaznamenávání je důležité i proto, že buildy jsou jen zřídka reprodukovatelné. Sestavte stejný commit dvakrát po sobě a správce balíčků může závislosti vyřešit a nainstalovat v jiném pořadí, takže druhý build může obsahovat jiné balíčky. Jen SBOM zaznamenaná během buildu, který vydání vytvořil, dokazuje, co toto vydání obsahuje.

Syft nebo Trivy si nechte pro image a binárky třetích stran, které jste nesestavili. Pro vlastní vydání viz SBOM z doby buildu, nebo si rezervujte demo a na jednom ze svých repozitářů porovnejte zaznamenanou SBOM s tou ze svého současného nástroje.

Generátory SBOM s otevřeným zdrojovým kódem: časté dotazy

Co je pro SBOM lepší, Syft, nebo Trivy?

Jsou postavené na jinou práci. Syft je specializovaný generátor SBOM s mnoha catalogery a podepsanými atestacemi; Trivy je bezpečnostní skener, který SBOM zapisuje jako jeden ze svých výstupů. Oba čtou soubory, které mají před sebou, takže na stejném repozitáři je větším rozdílem obvykle to, zda je lockfile commitnutý a zda byly závislosti před skenem nainstalovány.

Proč moje SBOM neukazuje žádné závislosti?

Nejčastěji proto, že repozitář necommituje žádný lockfile a před skenem se nic nenainstalovalo. Generátor, který čte lockfily nebo nainstalované balíčky, pak nemá co číst, a přesto zapíše platnou SBOM. Commitněte lockfile, nebo skenujte po kroku instalace.

Zahrnuje Trivy do SBOM vývojové závislosti?

Ve výchozím stavu ne. Dokumentace Trivy pro Node.js uvádí, že vývojové závislosti nehlásí, pokud nezadáte --include-dev-deps. cdxgen naopak parsuje lockfily a vývojové závislosti zahrnuje. Už jen kvůli tomu se mohou dva nástroje na stejném projektu rozcházet.

Mohu SBOM z open source generátoru věřit?

Co se týče toho, co přečetl, ano. Otázkou je, co nepřečetl: cache, build nástroje, stahování, instalační skripty a binárky bez metadat balíčků. Skenovanou SBOM berte jako popis souborů, na které jste nástroj nasměrovali, ne buildu, který vytvořil vaše vydání.

Jaký je nejlepší nástroj SBOM?

U softwaru, který sestavujete sami, pochází nejúplnější SBOM ze záznamu buildu, ne ze skenování souborů. CRACI zaznamená každý balíček, který každý job GitHub Actions stáhne, i z cache, a našlo zranitelné balíčky, které Snyk a Aikido nenahlásily. Pro image a binárky třetích stran, které jste nesestavili, zůstává praktickou volbou skener, jako je Syft nebo Trivy.