Osvědčené postupy pro SBOM

Jak tyto postupy zavést napříč týmy, popisuje článek generování SBOM napříč vývojovými týmy.

Generování SBOM

1. Generujte v CI, pro každé vydání

SBOM vytvořená ručně zastará dřív, než ji někdo přečte. Udělejte z ní krok v pipeline, která sestavuje vydání, nebo použijte runner, který ji vytvoří zcela bez kroku, aby žádné vydání neodešlo bez ní. Pro GitHub Actions viz jak vygenerovat SBOM v GitHub Actions.

2. Popište build, který byl vydán

Buildy ve výchozím stavu nejsou reprodukovatelné. Dvojí build stejného commitu nezaručuje stejné závislosti, protože verze se řeší v době buildu a kroky se mohou lišit. SBOM z notebooku nebo z pozdějšího skenu popisuje podobný build, ne ten, který jste vydali. Jen SBOM z buildu v CI, který vydání vytvořil, dokazuje, co v něm je. Viz SBOM z doby buildu.

3. Pokryjte víc než lockfile

Lockfile není záznamem toho, co bylo vydáno. Instalační skripty stahují kód, build skripty v Rustu stahují soubory a buildy kontejnerů přinášejí základní image s vlastními balíčky operačního systému. Rozhodněte, co musí SBOM pokrýt, a pak to otestujte: vyhledejte ve své SBOM balíček ze základní image a nástroj buildu.

4. Zahrňte tranzitivní závislosti a vztahy

Zranitelnosti obvykle leží pod vašimi přímými závislostmi. Plochý seznam ukáže, že komponenta je přítomna, ale ne co aktualizovat. Ponechte v SBOM graf závislostí, aby nález přišel spolu s balíčkem, který ho natahuje.

5. Uveďte, co jste nemohli vidět

Dokument 2026 Minimum Elements žádá autory SBOM, aby neznámé informace výslovně označili. Částečná SBOM, která to přizná, má větší hodnotu než částečná SBOM, která vypadá hotově. Zaznamenejte také nástroj, jeho verzi a kontext generování, aby čtenář mohl posoudit, co soubor pokrývá. Viz úplnost SBOM.

Uchovávání SBOM

6. Uchovávejte jednu SBOM na vydání, svázanou s artefaktem

Když se zákazník se starou verzí zeptá, zda je ohrožen, potřebujete SBOM této verze, ne tu nejnovější. Ukládejte každou SBOM s buildem a artefaktem, který popisuje, a dobu uchovávání určete podle toho, jak dlouho vydání podporujete. Hashe v SBOM pomáhají svázat ji s přesným artefaktem.

7. Zvolte formát a identifikátor a držte se jich

Standardizujte na CycloneDX nebo SPDX, jednu verzi formátu a package URL jako identifikátory. Většina potíží při porovnávání SBOM pramení z toho, že nástroje stejnou věc pojmenovávají různě. Validujte každý soubor v pipeline a stejný formát žádejte od dodavatelů. Kontrolní seznam kvality SBOM ukazuje, co kontrolovat a které nástroje to dělají.

Používání SBOM

8. Monitorujte to, co bylo vydáno, nejen to, co právě sestavujete

Nejcennější okamžik pro SBOM je den poté, co vyjde bezpečnostní upozornění na software vydaný loni. Sken v pull requestu tehdy nepomůže. Uložené SBOM podporovaných vydání znovu vyhodnocujte proti novým datům o zranitelnostech, aby se z nového upozornění stal seznam dotčených vydání.

9. Předávejte nálezy vlastníkovi a zaznamenejte rozhodnutí

SBOM s tisícem spárovaných zranitelností je seznam, ne plán. Seřaďte nálezy pomocí metody prioritizace, každý pošlete týmu, který vlastní opravu, a zaznamenejte, proč jste u ostatních nejednali, například v prohlášení VEX.

10. Používejte stejnou SBOM pro zákazníky i auditory

Zákazníci, auditoři a regulátoři kladou podobné otázky. Odpovídejte na ně ze SBOM, kterou používají vaše vlastní týmy, místo abyste vytvářeli samostatný dokument, který se postupně rozchází. Pokud SBOM sdílíte, rozhodněte, kdo je smí vidět a jak dostávají aktualizace, a totéž žádejte od svých dodavatelů.

Časté chyby

Chyba	Proč škodí	Místo toho
Jedna SBOM na repozitář	Neříká nic o žádném konkrétním vydání	Jedna na vydání, svázaná s artefaktem
Generování jen před auditem	Popisuje build, který nikdo nevydal	Každé vydání, v CI
Brát SBOM jako hotovou	Nová upozornění přicházejí po vydání	Dál ji monitorujte
Porovnávat jen počet komponent	Víc není lepší, pokud jsou záznamy chybné	Zkontrolujte konkrétní balíčky, o kterých víte, že tam jsou

Jak to řeší CRACI

CRACI pokrývá postupy, které závisí na buildu. Je to runner pro GitHub Actions, který každý balíček stažený každým jobem, včetně skrytých závislostí, které neuvádí žádný lockfile, zaznamená do SBOM ve formátu CycloneDX nebo SPDX se stavem úplnosti. Uchovává každý minulý build a jeho SBOM po dobu uchovávání podle vašeho plánu, monitorované SBOM znovu vyhodnocuje, jakmile se objeví nové zranitelnosti, a ukazuje, které buildy obsahovaly zranitelnou závislost. Bezpečnostní týmy provádějí triáž nálezů a posílají je týmům, které vlastní opravu. Jak se nástroje pro správu porovnávají, viz správa SBOM, nebo nejlepší nástroje SBOM.

Osvědčené postupy SBOM: časté dotazy

Kdy byste měli generovat SBOM?

Během buildu v CI, který vytváří vydání, a to pokaždé. SBOM vytvořená v tomto okamžiku popisuje to, co bylo vydáno, zatímco pozdější popisuje nový build nebo sken.

Jak dlouho byste měli SBOM uchovávat?

Nejméně tak dlouho, jak vydání podporujete, plus cokoli, co vyžadují regulátoři nebo smlouvy. SBOM staré verze potřebujete, abyste zjistili, zda se na její uživatele vztahuje nová zranitelnost.

Mají být SBOM automatizované?

Ano. Ručně vytvořená SBOM je zastaralá s dalším vydáním. Generujte SBOM v pipeline, tam je validujte a ukládejte je s buildem.

Měli byste svou SBOM sdílet se zákazníky?

Sdílejte ji, když o ni požádá zákazník nebo regulátor, za podmínek, které vám vyhovují. SBOM prozrazuje, co používáte, proto ji mnoho firem sdílí na požádání, místo aby ji zveřejnily.

Jaký je rozdíl mezi SBOM a správou SBOM?

SBOM je jeden soubor. Správa SBOM je průběžná práce: ukládání SBOM podle vydání, jejich monitorování kvůli novým zranitelnostem a jejich zpřístupnění lidem, kteří je potřebují.