Automatizace SBOM: nahraďte tabulky záznamy z buildů

Proč ruční SBOM přestávají fungovat

Při dalším buildu zastarají. Závislosti se mění s každým vydáním a tabulka se změní jen tehdy, když si někdo vzpomene ji aktualizovat.
Končí u toho, co lidé vidí. Přímé závislosti se vypisují snadno. Tranzitivní závislosti pod nimi už ne a ručně je nikdo nedokáže sledovat.
Množí se. Několik produktů, každý s několika podporovanými verzemi, znamená desítky souborů, každý s vlastním vlastníkem a vlastní představou o pravdě.
Neodpovědí na otázku, na které záleží. Když se objeví nová zranitelnost, potřebujete vědět, která vydání balíček obsahují. Hledání ve složce tabulek je pomalé a odpovědi nelze věřit.
Nejsou tím, co ostatní požadují. Zákazníci i nástroje očekávají strojově čitelný formát, jako je CycloneDX nebo SPDX. Viz jak odpovědět na žádost zákazníka o SBOM.

Co dělá dobrá automatizace SBOM

Vytvoří SBOM pro každý build, aniž by kdokoli musel něco spouštět nebo si na něco vzpomenout.
Pokrývá celý strom, včetně tranzitivních závislostí v libovolné hloubce.
Váže každou SBOM k jednomu buildu, takže víte, který soubor popisuje které vydání.
Říká, co nemohla vidět, místo aby částečný seznam vydávala za úplný.
Exportuje standardní formát, aby SBOM fungovala s dalším nástrojem i dalším zákazníkem.
Dál sleduje, co bylo vydáno, protože vydání, které bylo v pondělí čisté, může být v úterý zasažené.

Tři způsoby vedení SBOM ve srovnání

Otázka	Tabulka	Skener v CI	Zaznamenáno během buildu
Kdy se aktualizuje?	Když si někdo vzpomene	Když proběhne krok skenování	Při každém buildu
Odkud data pocházejí?	Od lidí	Z lockfilů nebo z hotového výstupu	Z toho, co build skutečně stáhl
Tranzitivní závislosti?	Zřídka	Ty, které dokáže odvodit	V libovolné hloubce
Skryté závislosti, například stahování instalačními skripty?	Ne	Přehlédnuty	Zaznamenány
Balíčky obnovené z cache CI?	Ne	Záleží na nástroji	Zaznamenány a označeny jako z cache
Monitorování zranitelností?	Ručně	Obvykle samostatný nástroj	Vestavěné v CRACI

Automatizace pomocí skeneru je oproti tabulce skutečným zlepšením, a přesto jen odhaduje, co do buildu vstoupilo. Zdůvodnění najdete v článku proč je zdrojem pravdy build.

Co se stane s vašimi tabulkami

Data o komponentách z nich odejdou: verze a balíčky pocházejí z buildu, takže je nikdo nemusí vypisovat. Zůstane znalost, kterou má jen váš tým, například jaké produkty existují, kdo je vlastní a které verze jsou stále podporované. To je ta část, která si zaslouží čas člověka.

Jak to řeší CRACI

CRACI nahrazuje vaše runnery hostované na GitHubu rychlejšími a levnějšími a zaznamenává SBOM během každého buildu. Nastavíte runs-on: craci a vaše běhy se dál zobrazují v GitHubu. Standardní buildy získají úplnou SBOM bez konfigurace. Buildy s vlastními registry balíčků nebo neobvyklým nastavením kontejnerů mohou nějakou potřebovat.

Zaznamenáno, ne naskenováno. CRACI vidí provoz přicházející do každého buildu, včetně skrytých závislostí, které nástroje založené na lockfilech přehlédnou. Každá komponenta v SBOM v buildu skutečně byla.
Stav úplnosti u každého jobu, takže víte, kdy build nebylo možné plně zaznamenat a proč.
Export do CycloneDX a SPDX, včetně tranzitivních závislostí a zranitelností nalezených v komponentách.
Jeden pohled napříč produkty. Zobrazení inventáře ukazuje, které verze softwaru jsou nasazené v kterých produktech, a CRACI průběžně znovu vyhodnocuje monitorované SBOM.

Jak to zavést napříč týmy s různými pipeline, popisuje generování SBOM napříč vývojovými týmy.

Automatizace SBOM: časté dotazy

Co je automatizace SBOM?

Vytváření softwarového kusovníku jako součásti buildu, takže každé vydání ho má, aniž by ho kdokoli vytvářel ručně. Lepší řešení navíc po vydání monitorují každou SBOM kvůli novým zranitelnostem.

Můžeme své SBOM vést v Excelu?

Tabulka může posloužit jako první inventář, ale těžko se udržuje aktuální a nedosáhne na tranzitivní závislosti. Navíc to není standardní formát SBOM. Zákazníci a bezpečnostní nástroje obvykle očekávají CycloneDX nebo SPDX a Cyber Resilience Act požaduje běžně používaný, strojově čitelný formát.

Potřebuje automatizace SBOM nový krok v každé pipeline?

U většiny generátorů ano: přidáte krok do každého workflow a udržujete ho aktuální. CRACI zaznamenává SBOM v runneru, takže do jobů není potřeba přidávat žádný krok.

Které ekosystémy CRACI zaznamenává?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, balíčky Debianu a Ubuntu (apt), balíčky Alpine (apk) a zdroje Git a také stahování pro Yocto a OpenEmbedded. Maven a Java jsou v plánu vývoje.

Které systémy CI a platformy CRACI podporuje?

Dnes GitHub Actions, další systémy CI jsou v plánu vývoje. Runnery jsou dnes Linux x86-64 a ARM64, Windows a macOS jsou v plánu vývoje.

A co komponenty, které kupujeme od dodavatelů?

SBOM dodavatelů můžete do CRACI přidat, takže nakoupené komponenty jsou monitorovány spolu s vašimi vlastními buildy.

Kolik to stojí?

CRACI účtuje jen minuty buildu: $0.002 za vCPU-minutu ($0.004 za výchozí runner se 2 vCPU), účtováno po sekundách, bez měsíčního poplatku a bez poplatku za SBOM.