Úplnost SBOM

SBOM je úplná, když uvádí každou komponentu, která se dostala do popisovaného softwaru, v každé úrovni stromu závislostí, včetně komponent, které neuvádí žádný lockfile ani manifest. Úplnost SBOM je právě tato vlastnost. 2026 Minimum Elements od CISA žádají autory SBOM, aby výslovně uváděli, kdy je informace neznámá, a upozorňují, že příjemci mohou SBOM považovat za neúplnou, pokud v ní chybí podstatné údaje o komponentách.

Úplnost, platnost a kvalita jsou různé věci

Otázka	Co znamená	Co to ověří	Co z toho nezjistíte
Platná	Soubor odpovídá schématu CycloneDX nebo SPDX	Validátor schématu	Zda chybí komponenty
Kvalita polí	Každá komponenta má název, verzi, dodavatele, identifikátor, licenci a hash	Nástroj pro hodnocení kvality	Zda chybí komponenty
Úplná	Nechybí nic, co se dostalo do softwaru	Porovnání s tím, co build skutečně načetl	Vstupy, které porovnání nevidělo

Identifikátorem ve druhém řádku bývá obvykle package URL nebo CPE. Soubor může prvními dvěma kontrolami projít bez chyby, a přesto vynechat polovinu softwaru.

Proč se úplnost dodatečně měří těžko

Skener pracuje s lockfily, manifesty nebo s hotovým výstupem. Nemůže vědět o balíčku, který stáhl skript post-install, o crate zkompilovaném do binárky ani o vrstvě základního image, kterou nikdy neviděl. Každá z nich je skrytá závislost.

Vezměme službu v Node.js, jejíž lockfile uvádí 400 balíčků. Jeden z nich má skript postinstall, který během npm ci stáhne předkompilovanou binárku. SBOM vygenerovaná z package-lock.json je platná, každá komponenta má verzi a package URL, a binárka v ní není. Žádné hodnocení kvality to neodhalí, protože nic v souboru neukazuje na to, co chybí.

Ani pozdější nový build otázku nerozhodne: pokud build není reprodukovatelný build, druhý build může načíst něco jiného než první.

Jak úplnost poctivě vykazovat

• Uveďte kontext vygenerování: zda SBOM vznikla ze zdrojového kódu před buildem, byla zaznamenána během buildu, nebo vznikla dodatečnou analýzou výstupu.
• Vyjmenujte známé mezery: části softwaru, které nástroj neviděl, například převzatý (vendored) kód, předkompilované binárky nebo komponenty nainstalované mimo správce balíčků.
• Dejte přednost stavu s důvody před skóre. Procento úplnosti potřebuje celkový počet, a právě ten nikdo nezná. Podle tvrzení typu „neúplná: job povolil nemonitorovaný provoz“ se dá jednat.

Osvědčené postupy pro SBOM popisují širší praxi uvádění toho, co SBOM nemohla vidět.

Stavy úplnosti v CRACI

CRACI přiřazuje SBOM každého jobu stav úplnosti a svůj stav dostávají i cache. Stavy podle definice v dokumentaci CRACI:

• Complete: „CRACI zaznamenalo úplné důkazy o jobu a každá obnovená cache byla úplná.“
• Complete with connections: „Požadavky byly splněny, ale job použil jedno nebo více vlastních síťových připojení.“
• Incomplete: „CRACI zjistilo podmínku, kvůli které mohou v SBOM chybět závislosti.“
• Unavailable: „CRACI nemohlo dokončit vyhodnocení důkazů.“
• Not recorded: „Job vznikl dříve, než bylo zavedeno vykazování úplnosti.“

CRACI to může tvrdit, protože vidí provoz každého jobu ke zdrojům balíčků, a ví tedy, kdy ho něco mohlo obejít: provoz, který nemonitoroval, nebo obnovená cache, jejíž vlastní SBOM byla neúplná. Když je job neúplný, zobrazí důvod, například „Unmonitored traffic was allowed“. Viz generování SBOM.

Tyto stavy platí pro buildy, které běží na runnerech CRACI. U SBOM od dodavatele nebo z pipeline, která neběží na CRACI, použijte výše uvedená porovnání a pravidla vykazování.