Generování SBOM napříč vývojovými týmy: jedna politika, každá pipeline

Proč skenery jednotlivých týmů nedávají dohromady program SBOM

Namiřte pět nástrojů na stejný produkt a dostanete pět SBOM. Rozdíly jsou strukturální, nejde o chyby:

• Různé vstupy, čtené v různou dobu. Jeden nástroj čte lockfile, jiný nainstalovaný strom závislostí, další image kontejneru, další binárku. Každý vidí jiný výsek produktu.
• Různé názvy pro stejnou věc. Jeden identifikuje komponenty pomocí package URL, jiný pomocí CPE, další jen podle názvu souboru. Dvě SBOM, které popisují stejnou knihovnu, nelze propojit přes společný klíč.
• Různá hloubka. Některé uvádějí jen přímé závislosti, některé celý tranzitivní strom a některé i nástroje pro build. Proč se generátory na stejném repozitáři neshodnou, ukazuje stránka open source generátory SBOM.
• Některé nástroje odpovídají na jinou otázku. Skenery zranitelností infrastruktury hlásí, co je nainstalováno na běžících hostitelích. To je užitečné pro provoz, ale není to popis produktu, který dodáváte.

Důsledek: SBOM napříč produkty nemůžete sloučit, deduplikovat ani porovnat a auditorovi nemůžete ukázat jeden proces, protože žádný neexistuje.

Metoda	Co čte na vstupu	Kdy	Co přehlédne	Typický identifikátor
Skener lockfilů nebo manifestů	Lockfily a manifesty v checkoutu	Před buildem nebo po něm	Vše, co neuvádí žádný lockfile: instalační hooky, stahování skripty buildu, základní image	Package URL
Skener image kontejnerů	Databáze balíčků a soubory v image	Po buildu	Nástroje jen pro build, zakompilovaný kód, vše bez záznamu o balíčku	Package URL pro balíčky OS a jazyků
Skener binárek nebo firmwaru	Řetězce a signatury v binárce	Po buildu	Jistotu: verze a komponenty jsou odvozené	CPE nebo odvozený název
Skener zranitelností hostitelů	Nainstalovaný software na běžících serverech	Za provozu	Produkt tak, jak byl dodán zákazníkům	CPE nebo název produktu dodavatele
Záznam během buildu	Co build vydání stáhl	Během buildu	Software, který jste nesestavili; co nemohl vidět, je označeno jako neúplné	Package URL

Politika SBOM: co sjednotit

Sjednoťte SBOM, ne skener. Politika stanoví výstup a proces; každá pipeline ji splní nejlepším generátorem, který může spustit. Každý řádek níže je něco, co lze ověřit.

Požadavek	Pravidlo	Proč	Jak ho ověřit
Rozsah	Každé vydání produktu, které jde k zákazníkovi, včetně firmwaru a image kontejnerů. Interní nástroje volitelně.	Zákazníci a regulátoři se ptají na to, co dodáváte.	Každé vydání v registru vydání má SBOM.
Formát a verze	Jeden primární formát, CycloneDX nebo SPDX, s minimální verzí. Ten druhý přijměte na požádání.	Jeden formát znamená jeden parser, jeden validátor a jedno úložiště. BSI TR-03183-2 požaduje CycloneDX 1.6 nebo novější nebo SPDX 3.0.1 nebo novější, což je rozumné minimum pro zákazníky v EU.	Validace schématu hlásí formát a verzi.
Minimální pole	Package URL u každé komponenty, která ji má, CPE jen tam, kde žádná není, dodavatel, verze, deklarovaná licence, vztahy závislostí, název a verze nástroje, časové razítko a kontext generování.	Právě ty se používají při párování, kontrole licencí a auditech. Sjednoťte je s minimálními prvky na stránce co je SBOM.	Kontrola polí v pipeline spočítá chybějící hodnoty.
Kdy se generuje	V buildu CI, který vytváří vydání, pokaždé. Ne v době auditu, ne na notebooku.	Nový build není tentýž build; viz SBOM z doby buildu.	ID buildu v SBOM odpovídá ID buildu vydání.
Hloubka	Celý tranzitivní strom, ne jen nejvyšší úroveň.	Minimem podle CRA jsou nejdůležitější závislosti produktu; zranitelnosti i zákazníci jdou hlouběji.	Vztahy závislostí existují i pod první úrovní.
Kde se ukládá	Spolu s artefaktem vydání, dohledatelné podle produktu a verze.	SBOM, kterou nikdo nenajde, když vyjde bezpečnostní upozornění, není důkaz.	Vyhledejte SBOM náhodného vydání podle produktu a verze.
Uchování	Nejméně po dobu podpory produktu plus dobu uchování dokumentace, kterou vyžadují vaše předpisy.	CRA stanoví dobu uchování technické dokumentace a SBOM je její součástí.	Porovnejte dobu v politice s dobou uchování v každém nástroji.
Validace	Každá SBOM se v pipeline validuje proti schématu; neplatná SBOM shodí build nebo bránu vydání.	Neplatné SBOM v nástrojích zákazníka selžou bez upozornění.	Log brány vydání ukazuje krok validace.
Vlastnictví	Generování vlastní produktový tým; produktová bezpečnost vlastní politiku, pravidla validace a reporty pokrytí.	Generování potřebuje vlastníka pipeline; konzistence potřebuje jednoho vlastníka pravidel.	Každá pipeline má uvedeného vlastníka.
Výjimky	Registr pojmenovaných, časově omezených výjimek: tým, důvod, datum ukončení.	Politika obstojí i u týmů, které ji zatím nemohou splnit.	Žádná výjimka není po datu ukončení.

Kontrolní seznam na stránce osvědčené postupy pro SBOM pokrývá pravidla pro jednu SBOM; tato politika je vrstva nad nimi. Každý tým v souboru vedle pipeline deklaruje, jak jeho pipeline politiku splňuje:

# sbom-policy.yaml, one per release pipeline
product: gateway-firmware
owner: team-gateway
format: cyclonedx
spec_version: "1.6"
generated_in: release-build
generator: build-time-recording
store: artifact-registry
validation: schema, fail-on-errors
exception: none

Generujte v buildu, ne v každém týmu dodatečně

Generování během buildu je standard, ke kterému byste měli směřovat. Popisuje build, který byl dodán, zahrnuje skryté závislosti, které neuvádí žádný lockfile, a jeden mechanismus vytváří SBOM stejného tvaru pro každý tým v dané pipeline. Rozdíl se nejsnáz vysvětlí na kuchyni: skener ochutná polévku a hádá recept; zapisovatel sleduje, co do kuchyně přichází.

Skener je stále tím správným nástrojem pro image, které jste nesestavili, pro binárky třetích stran a pro starší produkty bez CI. Uveďte to v politice a zaznamenejte kontext generování, aby čtenář věděl, co která SBOM viděla.

Situace	Metoda generování	Kontext generování k zaznamenání
Vydání sestavené v CI, které máte pod kontrolou	Zaznamenejte build, nebo spusťte generátor uvnitř jobu vydání	„Zaznamenáno během buildu“ nebo „po instalaci, ze souborů“
Image kontejneru sestavená v CI	Zaznamenejte build image; pokud zapisovatel nepokrývá balíčky OS, naskenujte kvůli nim výsledek	ID buildu a digest image
Image nebo zařízení třetí strany	Skener image a k tomu SBOM dodavatele, pokud existuje	„Naskenovaný výstup, nesestavili jsme ho my“
Binárka dodavatele	Vyžádejte si SBOM z buildu dodavatele; analýza binárky jako kontrola	Dodavatel, verze, jak byla získána
Starší produkt bez pipeline	Naskenujte dodaný artefakt; naplánujte pipeline	„Naskenovaný výstup“ a výjimka s datem ukončení

Smíšené CI: GitHub Actions, GitLab a Jenkins v jedné organizaci

Politika je záměrně nezávislá na CI: definuje výstup, takže pipeline v GitLabu nebo Jenkinsu ji může splnit krokem s generátorem a pipeline v GitHub Actions může používat záznam během buildu. Pravidla pro krok s generátorem:

• Spusťte ho v jobu vydání po kroku instalace, ne v samostatném jobu, který instaluje znovu.
• Připněte verzi generátoru a akce CI připněte na commit, ne na tag. Proč na tom záleží zejména u skenerů, popisuje stránka open source generátory SBOM.
• Zaznamenejte kontext generování jako „po instalaci, ze souborů“, aby čtenáři věděli, co viděl.
• Validujte výstup proti stejnému schématu jako u každé jiné pipeline.

Open source generátory jako Syft, Trivy a cdxgen umějí zapisovat CycloneDX i SPDX, takže pravidlo o formátu nevynucuje volbu nástroje. Pro jejich srovnání se podívejte na srovnání nástrojů SBOM.

CRACI dnes podporuje GitHub Actions; GitLab CI a Jenkins jsou v plánu vývoje, bez data. Důsledek pro zavádění: začněte se záznamem během buildu tam, kde se používá GitHub Actions, jinde ponechte kroky s generátorem a obojí sledujte ve stejném reportu pokrytí.

Když zákazník chce konkrétní verzi formátu

Zákazník chce CycloneDX 1.6 a vaše nástroje zapisují 1.7. Stává se to, protože jeho nástroj pro import nebo jeho vlastní politika jsou připnuté na určitou verzi; minimem BSI je 1.6, takže ji zákazníci v EU často uvádějí. Vaše možnosti:

1. Zeptejte se, zda je novější verze přijatelná. Často je.
2. Převeďte ji pomocí CycloneDX CLI, pak ji validujte proti cílové verzi a zkontrolujte, co se ztratilo: pole, která existují jen v novější specifikaci, se zahodí.
3. U požadavku na SPDX převádí stejné CLI do formátu SPDX JSON 2.3 a z něj. Jeho dokumentace varuje, že převod mezi SPDX a CycloneDX „může vést ke ztrátě některých informací“.

cyclonedx convert --input-file bom.cdx.json --input-format json \
  --output-file bom-1.6.cdx.json --output-format json --output-version v1_6

cyclonedx validate --input-file bom-1.6.cdx.json --input-format json \
  --input-version v1_6 --fail-on-errors

Validátor kontroluje proti CycloneDX 1.7, pokud nezadáte --input-version. Pravidlo politiky: jako záznam ponechte původní SBOM. Převedená kopie je odvozená dodávka; uložte k ní informace o odvození (nástroj, verze, datum). Více o odpovídání na tyto požadavky najdete na stránce požadavky zákazníků na SBOM a o obou formátech na stránce CycloneDX vs SPDX.

Licenční data pro právní oddělení

Stejná SBOM může posloužit i právnímu týmu, pokud politika požaduje správná pole. Právníci potřebují licenci každé komponenty, rozdíl mezi deklarovanou licencí (co uvádí balíček) a zjištěnou licencí (co někdo ověřil), povinnosti z copyleftu a seznam komponent bez licence. CycloneDX 1.6 označuje licence jako deklarované nebo zjištěné a SPDX má pro obojí samostatná pole.

• Vyžadujte identifikátory nebo výrazy licencí SPDX, například MIT nebo Apache-2.0 OR MIT.
• Označte NOASSERTION a chybějící licence ke kontrole. V SPDX NOASSERTION znamená, že nebylo nic určeno nebo nebyly poskytnuty žádné informace; není to licence.
• Copyleftové licence předávejte právníkům před vydáním, ne po něm.

SBOM nese deklarované licence. Kontrola dodržování licencí se zjištěnými licencemi, upozorněními a povinnostmi je práce pro právníky nebo pro specializovaný nástroj; viz dodržování open source licencí.

Zavádění tým po týmu

Fáze	Vlastník	Kritérium dokončení	Typická překážka
1. Inventura: produkty, pipeline, systémy CI a současné generátory, jeden řádek na pipeline vydání	Produktová bezpečnost	Každý dodávaný produkt má řádek	Nikdo neví, která pipeline sestavuje vydání
2. Zveřejněte politiku s registrem výjimek	Produktová bezpečnost	Politika je schválená a zveřejněná	Debata o tom, který nástroj nařídit (politika žádný nenařizuje)
3. Pilot s jedním nebo dvěma týmy, které mají důvod: požadavek zákazníka, termín, produkt, který současný nástroj nezvládá	Pilotní týmy	Pilotní vydání se dodávají s vyhovujícími SBOM	Týmy bez naléhavého důvodu to odsouvají
4. Přidejte do pilotních pipeline validační brány	Pilotní týmy	Neplatná SBOM shodí vydání	Obava z blokování vydání; začněte varováním
5. Rozšiřujte podle systému CI; skener týmu vyřaďte, až když náhrada splňuje politiku	Produktové týmy	Cíl pokrytí splněn pro každý systém CI	Pipeline, které nikdo nevlastní
6. Reportujte pokrytí každý měsíc	Produktová bezpečnost	Report jde vedení každý měsíc	Metriky počítané ručně

Tabulka s inventurou ve fázi 1 by měla být tou poslední; přechod od tabulek popisuje stránka automatizace SBOM. Častým pilotem je produkt založený na Yocto, protože univerzální skenery si s ním nevědí rady; viz proč skenery SBOM přehlížejí buildy Yocto.

Měření pokrytí

Čísla, na která se ptá vedení a auditoři, každé definované jako poměr:

• Pokrytí vydání: vydání dodaná s SBOM vyhovující politice ÷ dodaná vydání.
• Pokrytí produktů: produkty s alespoň jednou vyhovující SBOM v aktuální době podpory ÷ podporované produkty.
• Úspěšnost validace: SBOM, které projdou validací ÷ vygenerované SBOM.
• Pokrytí identifikátory: komponenty s package URL (nebo CPE) ÷ komponenty.
• Pokrytí licencemi: komponenty s deklarovanou licencí ÷ komponenty.
• Úplnost: SBOM, u nichž generátor uvádí, že jsou úplné ÷ SBOM. Možné jen tam, kde to nástroj hlásí.
• Čas do SBOM: doba od vydání do dostupnosti SBOM.

Ukázkový měsíční report (ilustrativní čísla):

Metrika	Pipeline v GitHub Actions	Pipeline v GitLabu a Jenkinsu	Celkem
Pokrytí vydání	46 / 48	19 / 27	65 / 75
Úspěšnost validace	100%	92%	97%
Pokrytí identifikátory	99%	88%	95%
Otevřené výjimky	1	4	5

Jako důkaz pro regulátora nebo auditora slouží sada: politika, registr výjimek, report pokrytí a několik ukázkových SBOM. Ukazuje jeden proces, uplatňovaný a měřený. Stranu CRA popisuje průvodce CRA.

Jak do toho zapadá CRACI

Pro pipeline v GitHub Actions je CRACI runner: nastavíte runs-on: craci a každý job dostane zaznamenanou SBOM bez kroku s generátorem. Každá SBOM nese stav úplnosti, tranzitivní závislosti, package URL u každého balíčku a deklarovanou licenci každé komponenty a exportuje se ve formátu CycloneDX nebo SPDX. Pravidla licenční politiky mohou zablokovat build, monitorované SBOM se průběžně znovu vyhodnocují a historie buildů ukazuje, které buildy obsahovaly zranitelnou závislost. Tyto týmy tak ve výchozím stavu splňují řádky politiky „generováno v buildu vydání“, „identifikátor“ a „licence“. SBOM třetích stran lze přidat, takže se nakupované komponenty monitorují spolu s vašimi buildy.

Podívejte se na generování SBOM na CRACI a SBOM v GitHub Actions.

Kdy CRACI není řešením

• Týmy na GitLab CI nebo Jenkinsu: dnes ne, je to v plánu vývoje. Použijte krok s generátorem, který politiku splňuje.
• GitHub Enterprise Server: dnes není podporován.
• Skenování infrastruktury a hostitelů, tedy toho, co je nainstalováno na serverech, a chybných konfigurací: jiná úloha; tyto nástroje si ponechte.
• Analýza binárek nebo firmwaru u image dodavatelů, které nesestavujete: CRACI zaznamenává buildy a binárky neskenuje.
• Dlouhé uchování: CRACI uchovává data buildů ve výchozím nastavení 180 dní, s vlastní dobou uchování v plánu Enterprise. Pokud vaše politika vyžaduje SBOM déle, exportujte je do vlastního úložiště.

Generování SBOM napříč týmy: časté dotazy

Jak sjednotit generování SBOM napříč týmy, které používají různé nástroje?

Sjednoťte výstup, ne nástroj. Napište jednu politiku, která stanoví formát a verzi, minimální pole, kdy se SBOM generuje, kde se ukládá, jak dlouho se uchovává a kdo ji validuje. Nechte každou pipeline, ať ji splní nejlepším generátorem, který může spustit, a měřte pokrytí vůči politice.

Co by měla politika SBOM obsahovat?

Rozsah, formát a minimální verzi, minimální pole (package URL, dodavatel, verze, deklarovaná licence, závislosti, nástroj, časové razítko, kontext generování), generování v buildu vydání, celou tranzitivní hloubku, uložení spolu s vydáním, uchování, validaci v pipeline, vlastnictví a registr časově omezených výjimek.

Má mít každý tým vlastní skener, nebo mají SBOM pocházet z buildu?

Z buildu, kde to jde. SBOM z doby buildu popisuje build, který byl dodán, a dává každému týmu v dané pipeline SBOM stejného tvaru. Skenery si ponechte pro to, co jste nesestavili: image třetích stran, binárky dodavatelů a starší produkty bez pipeline.

Zákazník chce naši SBOM ve starší verzi CycloneDX. Co máme dělat?

Nejprve se zeptejte, zda je novější verze přijatelná. Pokud ne, převeďte kopii pomocí CycloneDX CLI (cyclonedx convert s --output-version v1_6), validujte ji proti této verzi a zkontrolujte, která pole se zahodila. Originál ponechte jako záznam a uložte informaci o tom, jak kopie vznikla.

Jak předat licenční data ze SBOM právníkům?

V politice vyžadujte identifikátory nebo výrazy licencí SPDX, označte NOASSERTION a chybějící licence ke kontrole a copyleftové licence předávejte právníkům před vydáním. SBOM nese deklarované licence; zjištěné licence, upozornění a povinnosti vyžadují licenční kontrolu.

Jak měřit pokrytí SBOM napříč produkty?

Jako poměry: vydání dodaná s vyhovující SBOM, podporované produkty s vyhovující SBOM, úspěšnost validace, komponenty s package URL, komponenty s deklarovanou licencí, úplné SBOM tam, kde to nástroj hlásí, a doba od vydání do SBOM. Reportujte je měsíčně podle systému CI.

Jaké důkazy potřebujeme, abychom auditorovi ukázali, že generování SBOM je konzistentní?

Politiku, registr výjimek, měsíční report pokrytí a několik ukázkových SBOM s jejich kontextem generování. Dohromady ukazují jeden proces, uplatňovaný na každé vydání a měřený, a právě to auditor nebo zákazník kontroluje.