SBOM generovaná AI je odhad vašeho buildu. Regulátoři chtějí záznam.

Proč to týmy zkoušejí

Lákavost je skutečná. Vložíte repozitář nebo lockfile do asistenta pro programování, požádáte o CycloneDX a za pár sekund dostanete dobře strukturovaný dokument. Dokáže dokonce vyplnit pole, která skenery běžně nechávají prázdná. Typickým příkladem je pole dodavatele: většina generátorů pro něj nemá zdroj, takže zůstane prázdné. Model požádaný o úplný dokument dokáže něco napsat do každého pole.

Právě v tom je celý problém v malém. Skener, který dodavatele nezná, nechá pole prázdné. Model, který ho nezná, může přesto vytvořit věrohodnou odpověď. Dokument vypadá úplněji a je méně spolehlivý.

Co model skutečně vidí

Model, který generuje SBOM, pracuje s textem, který má před sebou: manifesty, lockfily, případně Dockerfile. Build nesleduje. Nevidí proto:

• jaké verze správce balíčků vyřešil, když repozitář necommituje žádný lockfile,
• balíčky obnovené z cache CI,
• nástroje, balíčky operačního systému a binární soubory, které krok buildu stahuje přímo,
• co se dostalo do zkompilované binárky, která se dodává spolu s téměř prázdným manifestem.

Dva repozitáře ukazují, jak skromné ty soubory mohou být. expressjs/express 5.2.1 necommituje žádný lockfile, takže jeho package.json uvádí závislosti jako rozsahy verzí a skutečné verze se určí až při instalaci. Repozitář anthropics/claude-code ve verzi v2.1.259 nemá žádný manifest závislostí ani lockfile a jeho zveřejněný balíček npm deklaruje nula runtime závislostí, přičemž obaluje předem sestavenou nativní binárku. Deterministický skener namířený na tento repozitář nemá co číst, co by binárku popisovalo. Model, který dostane stejné soubory, má stejný nedostatek informací a větší volnost mezeru vyplnit.

Halucinace jsou zdokumentovaný způsob selhání

Jazykové modely uvádějí balíčky, které neexistují. Nejlépe změřený případ se týká generování kódu, ne psaní SBOM, ale selhání, které ukazuje, platí stejně dobře pro seznam komponent. Studie z USENIX Security 2025 vygenerovala 576 000 ukázek kódu pomocí 16 modelů a zjistila průměrný podíl halucinovaných balíčků nejméně 5,2 % u komerčních modelů a 21,7 % u open source modelů, s 205 474 unikátními halucinovanými názvy balíčků. Vlastní dokumentace GitHubu ke Copilot Autofix varuje, že může navrhovat smyšlené závislosti zveřejněné pod statisticky pravděpodobnými názvy.

Modely také nedávají dvakrát stejnou odpověď. Dokumentace Anthropic uvádí, že ani s teplotou nastavenou na 0 nebudou výsledky plně deterministické a identické vstupy mohou v různých voláních API dávat různé výstupy. Dvě SBOM vygenerované ze stejného commitu se mohou lišit a ani jedna neříká, která je správná.

V SBOM není halucinovaná položka neškodný překlep. Balíček, který neexistuje, nebo špatná verze balíčku, který existuje, pošle vyhledávání zranitelností na špatné místo a výsledek se vrátí sebejistý a chybný.

Co podle norem má SBOM obsahovat

Minimální prvky NTIA (2021)

Základ NTIA definoval sedm datových polí: název dodavatele, název komponenty, verzi komponenty, další jedinečné identifikátory, vztah závislosti, autora dat SBOM a časové razítko. Doplnil je o podporu automatizace a soubor postupů a procesů. Každé pole popisuje fakt o softwaru, ne názor na něj.

Minimální prvky CISA z roku 2026

29. července 2026 zveřejnily CISA, NSA, FBI a mezinárodní partneři aktualizované minimální prvky, které nahrazují základ z roku 2021. Několik nových prvků lze jen těžko splnit bez sledování buildu:

• SBOM Generation Context: relativní fáze životního cyklu softwaru a data dostupná v okamžiku, kdy autor SBOM vygeneroval, s příklady „před buildem“, „build“ a „po buildu“. Model, který čte repozitář, je nanejvýš ve fázi před buildem.
• Component Hash Value: výstup kryptografického hashovacího algoritmu použitého na spustitelný artefakt komponenty. Pokud autor artefakt nemá, má podle CISA uvést, že hodnota je neznámá. Model, který se artefaktu nikdy nedotkl, hash vytvořit nemůže, jen text, který tak vypadá.
• SBOM Tool Name and Version: nástroj použitý ke generování SBOM musí být uveden.
• Coverage: SBOM má obsahovat informace o všech komponentách, které tvoří cílový software, včetně tranzitivních závislostí. Minimální hloubka neexistuje.
• Explicitly identifying unknown information: autor má výslovně uvést, zda je informace neznámá. Smyšlená hodnota je opakem.

Cyber Resilience Act EU

CRA dělá ze SBOM zákonnou povinnost výrobců produktů s digitálními prvky. Podle přílohy I části II výrobci „určí a zdokumentují zranitelnosti a komponenty obsažené v produktech s digitálními prvky, mj. na základě vypracování softwarového kusovníku (SBOM) v běžně používaném strojově čitelném formátu, který obsahuje přinejmenším nejdůležitější závislosti produktu“. Příloha VII řadí SBOM do technické dokumentace a orgán dozoru nad trhem si ji může vyžádat ke kontrole souladu se základními požadavky.

Žádný z těchto textů nástroje AI nezakazuje. Požadují data, která popisují skutečný produkt, a poctivé uvedení toho, co je neznámé. SBOM napsaná na základě odhadu má problém s obojím.

Jak CRACI vytváří SBOM

CRACI spouští vaše joby GitHub Actions na vlastních runnerech. Změníte runs-on na craci a běhy se dál zobrazují v GitHubu. Během běhu jobu sleduje proxy, která rozumí balíčkům, provoz ke zdrojům balíčků, takže SBOM zaznamenává, co build skutečně stáhl, včetně tranzitivních závislostí. Důkazy o závislostech putují spolu s cache CI, takže balíček obnovený z cache v záznamu zůstane.

• Ekosystémy: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk a zdroje Git, plus předvolby pro stahování.
• Úplnost: každý job a každá cache je označena jako Complete, Complete with connections, Incomplete, Unavailable nebo Not recorded, takže neznámé údaje jsou uvedeny, ne domyšleny.
• Formáty: CycloneDX a SPDX, s deklarovanými licenčními metadaty zahrnutými v exportu.
• Původ: API vrací SBOM, síťové stopy a údaje o původu (provenance).

CRACI automatizuje významnou část přehledu o dodavatelském řetězci a důkazů, které širší proces souladu s CRA potřebuje. Sám o sobě produkt do souladu neuvede. Podrobnosti popisuje generování SBOM během buildu a časový harmonogram náš přehled CRA.

Kde AI se SBOM opravdu pomáhá

Jakmile máte zaznamenanou SBOM, model s ní umí dobře pracovat: shrnout, které komponenty nesou riziko, vysvětlit bezpečnostní upozornění srozumitelným jazykem nebo připravit koncept dokumentace kolem ní, kterou pak zkontroluje člověk. Pravidlo je jednoduché. Záznam ať vytvoří build a model ať ho čte.