Žádosti zákazníků o SBOM: jak na ně odpovědět

Dodáváte komponenty nebo vestavěný software výrobcům? Podívejte se na průvodce SBOM pro dodavatele, který pokrývá smlouvy, VEX a SBOM pro každou dodanou verzi softwaru.

Proč se zákazníci ptají právě teď

• Cyber Resilience Act. Výrobci, kteří prodávají v EU, potřebují SBOM vlastního produktu a musí věnovat péči komponentám, které do něj začleňují, takže se otázka posouvá dál po dodavatelském řetězci.
• NIS2. Základní a důležité subjekty musí řešit bezpečnost dodavatelského řetězce. Směrnice SBOM výslovně nezmiňuje, ale SBOM je jedním ze způsobů, jak kupující uvidí, co dodavatel dodává. Viz SBOM jako důkaz pro NIS2, ISO 27001 a SOC 2.
• Odvětvová pravidla. Oddíl 524B předpisů FDA vyžaduje SBOM pro kybernetická zařízení a další odvětví mají svá vlastní pravidla.
• Jejich vlastní práce se zranitelnostmi. Zákazník, který ví, co je ve vašem produktu, pozná, zda se ho nová CVE týká, aniž by musel zakládat požadavek na podporu.

Na čem se dohodnout, než cokoli pošlete

Otázka	Proč na ní záleží
Jaký produkt a jaká verze?	SBOM popisuje jedno vydání. Pošlete tu, kterou zákazník používá, ne nejnovější build.
Jaký formát?	Většina žádostí přijme CycloneDX nebo SPDX. Zeptejte se, zda potřebují konkrétní verzi.
Do jaké hloubky?	Závislosti nejvyšší úrovně nemusí stačit. Počítejte s tím, že budou chtít i tranzitivní.
Jednou, nebo s každým vydáním?	Smlouva může počítat s novou SBOM pro každé vydání, což vylučuje cokoli dělaného ručně.
Za jakých podmínek?	SBOM ukazuje, jak je váš produkt postavený. Dohodněte se na podmínkách důvěrnosti a na způsobu předání souboru.

Co obsahuje dobrá odpověď

• SBOM v dohodnutém formátu pro přesně to vydání, které zákazník používá.
• Každou komponentu s názvem, verzí, dodavatelem, licencí a identifikátorem balíčku.
• Vztahy mezi závislostmi, aby bylo možné dohledat, co tranzitivní balíček stáhlo.
• Datum, nástroj, který ji vytvořil, a build, ze kterého pochází.
• Poctivou poznámku o všem, co SBOM nepokrývá (viz úplnost SBOM).

Jak soubory vypadají, ukazují příklady SBOM. K oběma formátům viz CycloneDX vs SPDX. Co zákazník po obdržení nejspíš zkontroluje, najdete v kontrolním seznamu kvality SBOM.

Chyby, které se později vrátí

• Poslat nejnovější build místo dodaného. Buildy ve výchozím stavu nejsou reprodukovatelné, takže nový build stejného commitu nezaručuje stejnou SBOM. Jen SBOM z buildu, který vydání vytvořil, ukazuje, co zákazník dostal.
• Sestavit ji ručně pro danou příležitost. Žádosti to jednou vyhoví, ale pro dalšího zákazníka a další vydání to musíte zopakovat. Viz automatizace SBOM.
• Slíbit víc, než dokážete opakovat. „Pošleme ji s každým vydáním“ se do smlouvy napíše snadno, ale bez automatizace se to těžko dodržuje.
• Považovat SBOM za konec. Navazující otázka zní „týká se vás tato CVE?“ a přijde ve chvíli, kdy přijde další velká zranitelnost.

Jak být připraveni na další žádost

Žádosti jsou snadné, když SBOM už existuje. Vytvářejte ji pro každé vydání v pipeline, která ho sestavuje, uchovávejte ji spolu s vydáním a monitorujte ji kvůli novým zranitelnostem. Žádost pak znamená jen stažení a krátkou poznámku a na navazující otázku odpovíte ze stejného záznamu.

Jak to řeší CRACI

CRACI zaznamenává SBOM z každého buildu GitHub Actions, který běží na jeho runnerech, takže každé vydání ji už má, když se na ni někdo zeptá.

• Export ve formátu CycloneDX nebo SPDX včetně tranzitivních závislostí a zranitelností nalezených v komponentách.
• Důkazy přímo z buildu. Každá komponenta v SBOM byla v buildu a zaznamenají se i skryté závislosti, které nástroje založené na lockfilu přehlédnou.
• Stav úplnosti u každého jobu, takže víte, co posíláte, ještě než to pošlete.
• Historie buildů. V rámci vaší doby uchování vidíte minulé buildy a jejich SBOM a také to, které buildy obsahovaly zranitelnou závislost.
• Odpovědi na navazující otázky. CRACI průběžně znovu vyhodnocuje monitorované SBOM, podporuje VEX a v zobrazení inventáře ukazuje, které produkty používají které verze.

Žádosti zákazníků o SBOM: časté dotazy

Musíme zákazníkům dávat svou SBOM?

Záleží na vašem trhu a vašich smlouvách. Cyber Resilience Act činí SBOM součástí technické dokumentace, která se na požádání předává orgánu dozoru nad trhem, a nevyžaduje její zveřejnění. Nárok zákazníka na ni obvykle vyplývá ze smlouvy, proto si ověřte, na čem jste se dohodli.

Jaký formát SBOM máme poslat?

CycloneDX nebo SPDX, podle toho, o co zákazník žádá. Pokud nemá preferenci, poslouží kterýkoli. Zeptejte se, zda jeho nástroje potřebují konkrétní verzi.

Musíme uvádět tranzitivní závislosti?

Cyber Resilience Act požaduje přinejmenším nejdůležitější závislosti produktu, ale mnoho kupujících očekává celý strom a zranitelnosti se často skrývají v tranzitivních balíčcích. Úplná SBOM je bezpečnější odpověď.

Má SBOM jít zákazníkovi na základě NDA?

To je rozhodnutí vaše a vašeho zákazníka. SBOM ukazuje, z čeho je váš produkt složený, proto ji mnoho dodavatelů sdílí na základě stávající smlouvy nebo NDA, místo aby ji zveřejnili.

Jak často máme posílat aktualizovanou SBOM?

Tak často, jak se dohodnete. Závislosti se mění s každým vydáním, takže nová SBOM pro každé vydání je poctivý výchozí stav, a ten je v praxi zvládnutelný jen tehdy, když SBOM vzniká přímo z buildu.

Co když se zákazník ptá na starší vydání?

Potřebujete SBOM z buildu, který dané vydání vytvořil. CRACI uchovává historii buildů v rámci vaší doby uchování, ve výchozím stavu 180 dní, s vlastní dobou uchování v plánu Enterprise, takže vše, co potřebujete uchovat déle, exportujte.

Nikdy jsme SBOM nevytvářeli. Kde začít?

Začněte vydáním, které váš zákazník používá, a nástrojem, který pracuje s vaším skutečným buildem. Pokud používáte GitHub Actions, přesun buildu na runnery CRACI vám dá zaznamenanou SBOM hned od prvního běhu.