SBOM má popisovat build, který byl vydán

Build SBOM, source SBOM, analyzed SBOM

Pokyny CISA k typům SBOM třídí SBOM podle toho, kdy a jak vznikají. Tři z nich pokrývají téměř každý používaný generátor SBOM:

Typ	Jak vzniká	Co může přehlédnout
Source	Ze zdrojových souborů, manifestů a lockfilů, obvykle pomocí nástroje SCA	Komponenty běhového prostředí, pluginů nebo platformy; cokoli, co není deklarováno v souborech
Build	Jako součást buildu, který vytváří artefakt k vydání	Cokoli, co prostředí buildu nevidí, a proto by měla být uvedena úplnost
Analyzed	Po buildu, analýzou spustitelného souboru, balíčku nebo image kontejneru	Komponenty, které nástroj nedokáže rozpoznat; výsledky závisí na heuristikách

CISA uvádí dvě výhody build SBOM: větší jistotu, že SBOM artefakt správně popisuje, díky informacím dostupným během buildu a procesu CI/CD, a větší důvěru, protože stejný build workflow může podepsat SBOM i artefakt. Jako nevýhodu uvádí, že ke generování možná budete muset změnit proces buildu. S CRACI je tou změnou jeden řádek, runs-on: craci, a zaznamenávání přichází s runnerem.

Skenování složky versus zaznamenání buildu

Většina generátorů SBOM jsou skenery. Nasměrujete jeden na strom zdrojového kódu nebo image kontejneru a on odvodí, co podle něj vstoupilo dovnitř, čtením manifestů, lockfilů, nainstalovaných balíčků nebo binárních souborů. To je užitečné a u softwaru, který jste nesestavili sami, je to často jediná možnost.

Slabinou je, že skener vidí jen to, co má před sebou. Pokud nebyl commitnut žádný lockfile, pokud závislosti nebyly před skenem nainstalovány nebo pokud se produkt dodává jako zkompilovaný binární soubor, má skener k dispozici méně než build. Sken, který nenajde vůbec žádné komponenty, přesto vytvoří platný dokument SBOM, a právě na tom se lidé spálí.

CRACI volí jiný přístup. Generuje SBOM uvnitř vlastního CI runneru, takže vydaný artefakt je ten, který je popsán. Není to sken, který proběhl někde poblíž.

5:15

Na čem sken závisí

Syft, Trivy, cdxgen, Microsoft SBOM Tool, export grafu závislostí z GitHubu a Socket CLI odvozují SBOM z toho, co dokážou přečíst. Níže popsané vzorce vyplývají z toho, jak tyto nástroje podle své dokumentace fungují.

Nástroje se neshodnou na tom, co je komponenta

Každý generátor sám rozhoduje, co se počítá jako komponenta a kterým souborům věřit, takže stejný připnutý commit dá každému z nich jiný seznam.

Částečně jde o pojmenování. Nástroje identifikují stejnou GitHub Action pod různými typy package URL, takže mohou uvést totéž, a přesto se neshodovat. I to je součást problému: SBOM, která pro komponentu používá jiný identifikátor, se hůře páruje s daty o zranitelnostech.

Zda jste nejdřív instalovali, může záležet víc než na nástroji

Express 5.2.1 necommituje lockfile. Generátor nasměrovaný na čistý checkout, který řeší závislosti z lockfilů nebo z nainstalovaného stromu, nemá před sebou ani jedno, takže žádná z npm závislostí deklarovaných v package.json se do dokumentu nedostane. Přesto může vrátit seznam složený z čehokoli jiného, co rozpozná, například z GitHub Actions a workflow souborů, které na ně odkazují. Žádný z nástrojů tu není rozbitý.

Na nainstalované kopii stejného repozitáře změní jeden příznak Syftu odpověď znovu. Stejný nástroj, stejný strom, stejná verze. Sken adresáře v Syftu záměrně hlásí, co projekt deklaruje, a katalogizátor, který čte nainstalované balíčky, není pro adresáře ve výchozí sadě.

Některý software nemá žádný manifest ke čtení

Repozitář anthropics/claude-code ve verzi v2.1.259 nemá žádný manifest závislostí: žádný package.json, lockfile ani ekvivalent. To, co pro něj každý generátor vrátí, je sestaveno z jiných typů souborů, takže odpověď vypovídá víc o nástroji než o projektu.

Publikovaný npm balíček se příliš neliší. @anthropic-ai/claude-code deklaruje nula běhových závislostí a osm balíčků pro konkrétní platformy, které obalují předkompilovaný binární soubor. @openai/codex 0.149.1 má stejnou podobu. Na počítači vývojáře běží zkompilovaný binární soubor, do kterého žádná čtečka manifestů nevidí. Nejde o chybu jednoho nástroje. Jde o distribuční model, který dodatečné skenování nedokáže popsat.

Verze a dodavatelé

Když dva nástroje najdou stejný balíček, ne vždy se shodnou na jeho verzi. Jeden může GitHub Action připnout na SHA commitu, zatímco jiný hlásí tag vydání. Vyhledání zranitelností podle špatné verze dá sebejistou špatnou odpověď.

Pole dodavatele, jeden z minimálních prvků NTIA, často zůstane prázdné, protože většina generátorů pro něj nemá zdroj.

Skryté závislosti: co žádný sken nevidí

Každý z výše uvedených nástrojů vychází z lockfilu nebo z výstupu buildu a odvozuje, co vstoupilo dovnitř. Build si ale stahuje víc. Tyto skryté závislosti neuvádí žádný lockfile, takže je sken nemůže najít:

• Instalační hooky. Skripty npm preinstall a postinstall běží během instalace a mohou stahovat další kód. Právě tak fungoval červ Shai-Hulud.
• Build skripty. Build skripty v Rustu, mimo jiné, stahují, co potřebují, v době buildu.
• Základní image. Build kontejneru stahuje základní image a jeho vrstvy operačního systému, které žádný jazykový lockfile neuvádí.
• Cache a build nástroje. Balíčky obnovené z cache CI a nástroje nainstalované kroky setup také přicházejí mimo lockfile.

Dodatečné skenování výstupu tuto mezeru neuzavře. Hotový binární soubor, zejména zkompilovaný kód jako Rust, nechává skener hádat, co do něj vstoupilo.

Dva buildy, dvě SBOM

Existuje druhý důvod, proč sken nemůže build nahradit: většina buildů není reprodukovatelná. Sestavte stejný commit dvakrát po sobě a nikdo vám nezaručí, že dostanete stejné balíčky. Správci balíčků řeší a instalují v pořadí, v jakém přicházejí odpovědi, což nejvíc záleží tam, kde chybí lockfile, jako u mnoha projektů v Pythonu, a kroky buildu mohou obsahovat vlastní náhodnost. Bajtově reprodukovatelné buildy jsou možné, s nástroji jako Nix, ale jsou vzácné.

SBOM vygenerovaná později, na jiném stroji nebo z jiného buildu, tedy popisuje build, který možná nikdy nebyl vydán. Pouze SBOM zaznamenaná během CI buildu, který vytvořil vydání, dokazuje, co běží v produkci.

Co zaznamenávání buildu mění

CRACI provoz vidí; skenery ne. Spouští vaše joby v GitHub Actions na vlastních runnerech a vidí síťový provoz přicházející do každého buildu, takže SBOM uvádí, co si job skutečně stáhl, včetně tranzitivních a skrytých závislostí, nikoli to, co by podle manifestu měl potřebovat.

Cache jsou místem, kde je zaznamenávání v době buildu obtížné. Balíček obnovený z cache se nikdy nedotkne registru balíčků, takže samotná proxy by ho přehlédla. CRACI přenáší důkazy o závislostech s cache, takže balíčky obnovené z cache zůstávají v SBOM jobu, který je obnovil. Viz co cache v GitHub Actions skrývá.

Detekované ekosystémy zahrnují npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk a zdroje Git, plus předvolby pro stahování Yocto a OpenEmbedded. Zrcadla JFrog Artifactory pro npm a PyPI fungují. Deklarovaná licenční metadata jsou součástí exportu. SBOM se exportují v CycloneDX a SPDX. Stránka generování SBOM popisuje všechny možnosti.

Viditelnost provozu funguje i opačným směrem. Build potřebuje balíčky ze známých zdrojů a publikuje svůj výstup na známá místa. Egress policy v CRACI povoluje pouze ty a každé jiné odchozí spojení okamžitě blokuje, takže malware, který se pokusí poslat vaše tajné klíče na server útočníka, selže. Protože politika povoluje to, co build potřebuje, místo aby hledala známé škodlivé hostitele, platí i tehdy, když jste prvním cílem útoku, který dosud nikdo neviděl, jako u Shai-Hulud. Viz jak egress policy zastaví únik dat.

SBOM kontejnerů a Docker image

U image kontejnerů je rozdíl vidět nejvíc. Obvyklé způsoby, jak získat SBOM pro Docker, image vždy analyzují: Syft a Trivy ho skenují, docker scout sbom indexuje jeho obsah, když image nenese žádnou SBOM attestation, a SBOM attestation v BuildKitu, zapnutá pomocí --sbom=true, ve výchozím nastavení spouští skener založený na Syftu nad poslední fází image. Starší plugin docker sbom je zastaralý ve prospěch docker scout sbom.

Každý z nich čte hotový image, takže vidí to, co je ve vrstvách ještě rozpoznatelné. Nevidí, co si build cestou stáhl. CRACI zaznamenává job, který image sestavuje: image a balíčky, které si job stáhne z registrů OCI a zdrojů balíčků, se dostanou do stejné SBOM jako zbytek buildu. U image, který jste nesestavili, je skenování stále praktickou možností. Viz co SBOM Docker image přehlížejí.

Úplnost uvedená pro každý job

Zaznamenaná SBOM je jen tak dobrá jako samotný záznam. Místo aby CRACI vydávala každou SBOM za úplnou, uvádí úplnost pro každý job a každou cache, v jednom z pěti stavů:

• Complete. CRACI zaznamenala úplné důkazy z 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 spojení, takže stojí za to zkontrolovat, co jimi prošlo.
• Incomplete. CRACI zjistila podmínku, kvůli které mohly některé závislosti v SBOM chybět.
• Unavailable. CRACI nedokázala vyhodnocení důkazů dokončit.
• Not recorded. Job je starší než hlášení úplnosti.

Úplnost je tranzitivní napříč cache. Pokud job obnoví neúplnou cache, je neúplná i jeho SBOM a každá cache, kterou tento job vytvoří, nese stav neúplnosti dál. Víte, na které SBOM se můžete spolehnout a které je potřeba zkontrolovat znovu.

1:43

Původ přes API

SBOM je jednou z částí toho, co CRACI u každého jobu zaznamenává. API vrací SBOM, síťové stopy a data o původu, vše zaznamenané ze stejného buildu.

Kde je skener stále správným nástrojem

Zaznamenávání v době buildu pokrývá software, který sestavujete. U image nebo binárního souboru třetí strany, který jste nesestavili, je skener stále praktickou volbou a výše uvedené nástroje jsou schopné a široce používané. Nejde o to, že skenery jsou špatné. Jde o to, že SBOM pro vaše vlastní vydání má pocházet z buildu, který je vytvořil.

Také SBOM z CRACI má svá omezení. Pokrývá joby, které běží na runnerech CRACI, což dnes znamená GitHub Actions na Linuxu, s dalšími CI systémy v plánu vývoje.

Vybíráte mezi nástroji? Viz srovnání nástrojů SBOM, nebo se podívejte, jak SBOM z doby buildu zapadají do práce na souladu s CRA. Syft, Trivy a cdxgen vedle sebe najdete na stránce co open source generátory SBOM přehlížejí.

SBOM z doby buildu: časté dotazy

Co je SBOM z doby buildu?

SBOM z doby buildu, kterou CISA nazývá build SBOM, se generuje jako součást sestavení artefaktu k vydání. Místo aby seznam komponent dodatečně rekonstruovala ze souborů, popisuje, co použil samotný build. CRACI ji zaznamenává z balíčků, které si každý job v GitHub Actions skutečně stáhl.

Jaký je rozdíl mezi build SBOM a analyzed SBOM?

Analyzed SBOM se generuje po buildu analýzou artefaktu, například spustitelného souboru nebo image kontejneru, což obvykle vyžaduje heuristiky. Build SBOM se generuje během buildu, z informací, které build má. Analyzed SBOM fungují bez přístupu k buildu, a proto jsou správnou volbou pro software, který jste nesestavili.

Jak vygenerovat SBOM pro Docker image?

U existujícího image ho naskenujte generátorem jako Syft, Trivy nebo docker scout sbom. BuildKit umí při buildu také připojit SBOM attestation, a to skenováním výsledného image. Chcete-li zaznamenat, co si build image stáhl, spusťte build na runneru CRACI: SBOM jobu pokrývá image a balíčky, které si stáhl.

Co jsou skryté závislosti?

Vše, co si build stáhne a co neuvádí žádný lockfile: kód stažený instalačními hooky npm, soubory, které build skripty v Rustu stahují v době buildu, a základní image s jeho vrstvami operačního systému při buildu kontejneru. Nástroje, které čtou lockfile nebo skenují výstup, je přehlédnou. CRACI je zaznamenává, protože vidí provoz přicházející do buildu.

Proč dva buildy stejného kódu dávají různé SBOM?

Protože většina buildů není reprodukovatelná. Správce balíčků řeší a instaluje balíčky v pořadí, v jakém přicházejí odpovědi, zejména bez lockfilu, a kroky buildu mohou obsahovat náhodnost. Sestavte stejný commit dvakrát po sobě a druhý build může obsahovat jiné balíčky. Pouze SBOM zaznamenaná během buildu, který vytvořil vydání, dokazuje, co toto vydání obsahuje.

Je SBOM z doby buildu vždy úplná?

Ne automaticky. Záznam je jen tak dobrý, jak dobře dokáže pozorovat, a proto CRACI uvádí úplnost pro každý job a každou cache: Complete, Complete with connections, Incomplete, Unavailable nebo Not recorded. Víte, na které SBOM se můžete spolehnout a které je potřeba zkontrolovat znovu.

Nahrazuje SBOM z doby buildu skenery SBOM?

U softwaru, který sestavujete, ano: SBOM vašich vydání má pocházet z buildů, které je vytvořily. U image a binárních souborů třetích stran, které jste nesestavili, je skener stále praktickou volbou. Možnosti popisuje srovnání nástrojů SBOM.

Jaký generátor SBOM CRACI používá?

Žádný. CRACI neskenuje soubory. Proxy rozpoznávající balíčky na jejích runnerech zaznamenává balíčky, které si každý job stáhne ze zdrojů npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk a Git, plus předvolby pro stahování Yocto a OpenEmbedded, a výsledek exportuje v CycloneDX nebo SPDX.