Zákazník chce SBOM: průvodce pro dodavatele komponent a softwaru

Tento průvodce je pro dodavatele ve výrobním dodavatelském řetězci: ECU, displeje, řídicí jednotky, brány, pohony, embedded linuxové stacky a moduly firmwaru. Pokud prodáváte software a zákazník poslal jednorázovou žádost, začněte článkem jak odpovědět na žádost zákazníka o SBOM, který tento případ popisuje.

Proč se OEM ptají právě teď

Žádost OEM o SBOM je obvykle předpis, který se na OEM vztahuje a k vám dorazí prostřednictvím smlouvy. O jaký předpis jde, rozhoduje o tom, co OEM musí mít a kolik z toho se přenese na vás.

Cyber Resilience Act

Podle Cyber Resilience Act (akt o kybernetické odolnosti), nařízení (EU) 2024/2847, zahrnuje produkt s digitálními prvky i softwarové nebo hardwarové komponenty, které jsou uváděny na trh samostatně (čl. 3 bod 1). Komponenta, kterou samostatně prodáváte do EU, je sama o sobě produktem a vy jste jejím výrobcem s vlastní povinností vůči SBOM: příloha I část II bod 1 požaduje softwarový kusovník (SBOM) „v běžně používaném strojově čitelném formátu, který obsahuje přinejmenším nejdůležitější závislosti produktu“. Pokud je komponenta určena k začlenění do jiných produktů, musí vaše pokyny obsahovat také informace, které integrátor potřebuje ke splnění základních požadavků (příloha II bod 8 písm. f)).

OEM má povinnosti, které dopadají i na vás. Při začleňování komponent od třetích stran musí jednat s náležitou péčí (čl. 13 odst. 5), a když v začleněné komponentě najde zranitelnost, musí ji oznámit osobě nebo subjektu, který komponentu vyrábí nebo udržuje (čl. 13 odst. 6). Pokyny Komise k CRA z července 2026 uvádějí, že důkazem náležité péče může být dokumentace získaná od výrobce komponenty, a SBOM nezmiňují; v praxi je SBOM často právě tou dokumentací, kterou OEM požadují. Povinnosti podávání zpráv platí od 11. září 2026 a nařízení se plně použije od 11. prosince 2027. Náhradní díly vyrobené podle stejné specifikace jako komponenty, které nahrazují, jsou vyloučeny (čl. 2 odst. 6). Zbytek nařízení popisují stránky co je CRA a Průvodce CRA.

Vozidla

CRA se nevztahuje na produkty, na které se vztahuje nařízení (EU) 2019/2144, nařízení o schvalování typu vozidel (čl. 2 odst. 2 písm. c)). Komponenty pro vozidla se schváleným typem se místo toho dostávají na trh podle pravidel pro vozidla a tato pravidla SBOM nikde nezmiňují.

• Předpis OSN č. 155 (kybernetická bezpečnost) vyžaduje, aby výrobce shromažďoval a ověřoval informace v celém dodavatelském řetězci a prokázal, že rizika spojená s dodavateli jsou identifikována a řízena (5.1.1(a)), aby ukázal, jak jeho systém řízení kybernetické bezpečnosti bude řídit závislosti, které mohou existovat vůči smluvním dodavatelům, poskytovatelům služeb nebo organizačním složkám výrobce (7.2.2.5), a aby pro schvalovaný typ vozidla identifikoval a řídil rizika spojená s dodavateli (7.3.2).
• Předpis OSN č. 156 (aktualizace softwaru) vyžaduje, aby všechny původní i aktualizované verze softwaru byly jednoznačně identifikovatelné (7.1.1.2), a pro každé RX Software Identification Number (RXSWIN) auditovatelný registr popisující veškerý software relevantní pro dané RXSWIN (7.1.2.3).
• ISO/SAE 21434 organizuje práci na kybernetické bezpečnosti mezi OEM a dodavatelem jako distribuované činnosti, jejichž rozdělení se sjednává v cybersecurity interface agreement.
• Auto-ISAC SBOM Informational Report (únor 2025) obsahuje vlastní doporučení odvětví.

V automobilovém průmyslu přichází SBOM jako smluvní požadavek, ne jako zákonný.

Průmyslová automatizace

IEC 62443-4-1 se vztahuje na dodavatele produktů pro průmyslové automatizační a řídicí systémy. SBOM nejmenuje, ale praxe 6, řízení bezpečnostních problémů (DM-1 až DM-6), a praxe 7, řízení bezpečnostních aktualizací (SUM-1 až SUM-5, včetně SUM-3, „Dependent component or operating system security update documentation“), jsou místa, kde SBOM slouží jako důkaz.

Strojní zařízení

Nařízení o strojních zařízeních (EU) 2023/1230 se použije od 20. ledna 2027 a SBOM nezmiňuje. Jeho základní požadavky na ochranu před poškozením (příloha III, 1.1.9) žádají, aby byl software kritický pro shodu identifikován a chráněn, aby strojní zařízení dokázalo identifikovat software, který je v něm nainstalován a je nezbytný pro jeho bezpečný provoz, a aby se shromažďovaly důkazy o zásazích do tohoto softwaru. Strojní zařízení s digitálními prvky na rozdíl od vozidel se schváleným typem spadají také pod CRA, a proto výrobci strojních zařízení už nyní žádají své dodavatele o SBOM. Viz CRACI pro výrobce strojních zařízení a průmyslový IoT.

NIS2 a certifikovaní zákazníci

Pokud dodáváte základním nebo důležitým subjektům, například v polovodičovém průmyslu, NIS2 v čl. 21 odst. 2 písm. d) vyžaduje, aby se váš zákazník zabýval bezpečností dodavatelského řetězce. SBOM nejmenuje. Zákazníci z toho dělají dotazníky a opatření 5.21 a 8.8 z přílohy A normy ISO/IEC 27001 jsou místa, kde SBOM slouží jako důkaz. Viz SBOM jako důkaz pro ISO 27001, SOC 2 a NIS2.

Režimy vedle sebe

Režim	Vztahuje se na	Jmenuje SBOM?	Co se dostane k dodavateli
Cyber Resilience Act	Produkty s digitálními prvky na trhu EU, včetně samostatně prodávaných komponent	Ano, příloha I část II bod 1	Přímo, pokud komponentu uvádíte na trh; prostřednictvím náležité péče OEM (čl. 13 odst. 5) a oznámení zranitelností (čl. 13 odst. 6)
UN R155 a R156	Výrobce vozidel, kteří žádají o schválení typu	Ne	Řízení rizik dodavatelů (R155 7.2.2.5, 7.3.2) a identifikace softwaru (R156), prostřednictvím smluv
ISO/SAE 21434	Inženýrství kybernetické bezpečnosti silničních vozidel, OEM a dodavatele	Ve veřejném popisu ne	Distribuované činnosti a cybersecurity interface agreement
IEC 62443-4-1	Dodavatele produktů pro průmyslové automatizační a řídicí systémy	Ne	Přímo, pokud jste dodavatelem produktu; SBOM slouží jako důkaz pro DM a SUM
Nařízení o strojních zařízeních	Strojní zařízení a související produkty na trhu EU	Ne	Identifikace a ochrana softwaru (příloha III 1.1.9); souběžně se použije CRA
NIS2	Základní a důležité subjekty	Ne	Dotazníky k bezpečnosti dodavatelského řetězce a smluvní podmínky (čl. 21 odst. 2 písm. d), čl. 21 odst. 3)

Ať je cesta jakákoli, zákazník potřebuje totéž: přesnou SBOM pro každou verzi softwaru, kterou dodáváte.

Co OEM obvykle požadují

Požadavky se u jednotlivých OEM liší, ale sbíhají se ke stejnému seznamu. Před první dodávkou s ním svou SBOM porovnejte.

Požadavek	Obvyklé očekávání
Formát	CycloneDX nebo SPDX, JSON nebo XML, s minimální verzí specifikace. BSI TR-03183-2 stanoví CycloneDX 1.6 nebo novější, případně SPDX 3.0.1 nebo novější.
Pole	V souladu s CISA 2026 Minimum Elements nebo BSI TR-03183-2: autor, časové razítko a u každé komponenty název, verze, výrobce a identifikátory
Identifikátory	Package URL všude, kde ho ekosystém má, CPE tam, kde ne, aby šlo komponenty spárovat s databázemi zranitelností
Licence	Identifikátory licencí SPDX. Licenční specialista OEM je čte, aby posoudil copyleft a další licenční rizika.
Hashe	Hash každé dodané binárky, aby OEM mohl ověřit, že SBOM popisuje soubor, který obdržel. BSI požaduje SHA-512.
Hloubka	Tranzitivní závislosti, nejen nejvyšší úroveň
Granularita	Jedna SBOM pro každou dodanou verzi softwaru nebo číslo dílu
Dodání a reakce	Kanál pro dodání a doby reakce na dotazy ke zranitelnostem

Mnoho OEM to po přijetí kontroluje automaticky. Co váš zákazník zkontroluje a jaké nástroje k tomu použije, najdete v kontrolním seznamu kvality SBOM a jak pole vypadají v souboru, ukazují příklady SBOM.

Vaše SBOM, když je open source málo nebo žádný

Bare-metal ECU nebo řídicí jednotka s proprietárním firmwarem z generování kódu na základě modelů má poctivou SBOM, která může být krátká: proprietární aplikace, váš bootloader, knihovny nebo kalibrace od výrobce čipu a případný open source, například kryptografická knihovna. To je platná odpověď. Pravidla:

• Proprietární komponenty uveďte s vlastními identifikátory: název, verze a vy jako výrobce.
• Uveďte známé neznámé, například knihovnu dodavatele, do jejíhož obsahu nevidíte.
• Nikdy SBOM uměle nenafukujte, aby vypadala důkladně, a nikdy nevynechávejte open source knihovnu jen proto, že je malá.

U displejů a bran založených na Linuxu platí opak: stovky nebo tisíce komponent, včetně jádra, bootloaderu a balíčků základního systému (viz připojená zařízení). SBOM, která uvádí jen vaši aplikaci a pár knihoven, je první věc, kterou přijímající tým označí. Pokud sestavujete pomocí Yocta, přečtěte si, proč skenery přehlížejí obsah buildů Yocto.

Smlouvy: co sjednat před první dodávkou

Podmínka	Proč na ní záleží
Pokryté produkty a verze softwaru	Aby se později nikdo nepřel, zda varianta nebo servisní vydání SBOM potřebovaly
Formát a verze specifikace	Jejich příjmová pipeline může cokoli jiného odmítnout
Pole a rámec, kterým se řídí	„BSI TR-03183-2 v2.1.0“ nebo „CISA 2026 Minimum Elements“ lze otestovat; „úplnou SBOM“ ne
Spouštěč dodání	Každé vydání, každá verze softwaru dodaná OEM a každá oprava
Kanál pro dodání	Dodavatelský portál OEM, zabezpečená výměna souborů nebo e-mail v rámci NDA
Důvěrnost	NDA nebo stávající dodavatelská smlouva, která SBOM výslovně označuje za důvěrnou informaci
Omezení použití	Pouze pro správu zranitelností a soulad, bez dalšího sdílení bez souhlasu
Oznamování zranitelností oběma směry	OEM oznamuje zranitelnosti, které najde ve vaší komponentě (CRA čl. 13 odst. 6); vy mu oznamujete ty své
Očekávání k VEX	Jaký formát a jak rychle posoudíte nové CVE
Uchovávání	Jak dlouho uchováváte SBOM každé verze, v souladu s dobou podpory produktu
Přesnost a známé neznámé	Poctivé ustanovení o tom, co SBOM může a nemůže pokrýt, chrání obě strany

SBOM Sharing Primer od CISA popisuje automobilový případ stejně: žádosti o SBOM by byly součástí standardních dohod o výměně informací (např. dohody o mlčenlivosti, cybersecurity interface agreement, development interface agreement).

Sdílení bez úniku duševního vlastnictví

SBOM není váš zdrojový kód. Uvádí názvy komponent, verze, výrobce, licence, hashe a vztahy. Neobsahuje váš kód, vaše algoritmy, vaše kalibrační data ani váš návrh.

• CRA výrobcům neukládá povinnost SBOM zveřejnit (bod odůvodnění 77). Orgánu dozoru nad trhem se předává na základě odůvodněné žádosti (příloha VII bod 8).
• Pokyny CISA ke sdílení popisují obvyklé kanály pro proprietární software: e-mail v rámci NDA, dodavatelský portál zákazníka nebo zabezpečenou výměnu dokumentů, případně vlastní portál s řízeným přístupem, přičemž důvěrnost a přístup upravují smlouvy.
• Praktické možnosti: jedna úplná SBOM pro každého OEM na základě smlouvy; identifikátory proprietárních částí, které neprozrazují interní názvy projektů; a samostatný dokument VEX, abyste mohli aktualizovat stav zranitelnosti, aniž byste znovu posílali SBOM.

Jak často a co se děje po dodání

• Nová SBOM pro každou verzi softwaru, kterou dodáte, pod stejným identifikátorem, pod kterým ji OEM nahrává nebo registruje. U vozidel to navazuje na identifikaci softwaru podle R156.
• Opravená SBOM, když v již odeslané najdete chybu.
• Prohlášení VEX nebo bezpečnostní upozornění, když jste zranitelnost posoudili.

Navazující otázka „týká se vás CVE-X?“ přijde s příští velkou zranitelností. Buďte připraveni na ni odpovědět pro každou dodanou verzi, což jde jen tehdy, pokud jste si SBOM každé z nich uchovali.

VEX: co bude váš zákazník očekávat dál

Dokument VEX uvádí, zda je produkt zranitelností zasažen. Dokument CISA Minimum Requirements for VEX (duben 2023) definuje čtyři stavy: not_affected, affected, fixed a under_investigation. Prohlášení not_affected má uvádět jedno z pěti zdůvodnění, případně prohlášení o dopadu:

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

Prohlášení affected potřebuje prohlášení o opatření: co má zákazník udělat. VEX existuje ve třech formátech: profil VEX v CSAF 2.0, CycloneDX VEX a OpenVEX. Výstup SPDX 3.0 z Yocta obsahuje data VEX ve výchozím nastavení (proměnná SPDX_INCLUDE_VEX).

Praktický příklad. Displej založený na Linuxu se dodává s OpenSSL 3.0.8. CVE-2023-0464 popisuje nadměrné využití prostředků při ověřování řetězců certifikátů X.509, které obsahují omezení politik. Zpracování politik je ve výchozím nastavení vypnuté a software displeje ho nikdy nezapíná. Dodavatel pošle ilustrativní prohlášení OpenVEX:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

Opakovatelné vytváření SBOM

Jak sestavujete	Realistický způsob, jak SBOM vytvořit
Software sestavovaný v CI	Vygenerujte SBOM v buildu, který vytváří dodávaný software, a uchovejte ji spolu s vydáním
Embedded Linux založený na Yoctu	Vlastní výstup SPDX z Yocta (create-spdx), zkontrolovaný na to, co vynechává, nebo záznam buildu Yocto
Bare-metal firmware z nástrojů pro modelování	Knihovna nebo nástroj pro generování, nikdy textový editor, udržovaný s každým vydáním a před odesláním validovaný
Binárky třetích stran, které začleňujete	Požádejte svého dodavatele o jeho SBOM; než dorazí, poslouží jako náhrada binární analýza

Ať zvolíte jakoukoli cestu, soubor před odesláním validujte. Kontrolní seznam kvality SBOM uvádí validátory, které váš zákazník pravděpodobně spustí, CycloneDX vs SPDX pomůže s formátem a standardizace generování SBOM popisuje, jak ho sjednotit napříč týmy.

Kde má místo CRACI

Dodavatelům, kteří sestavují v GitHub Actions, CRACI nahrazuje runnery hostované na GitHubu a z každého buildu zaznamená SBOM, takže každá dodaná verze ji už má.

• SBOM uvádí, co build skutečně stáhl, včetně tranzitivních závislostí, s package URL pro každý balíček a deklarovanou licencí každé komponenty.
• SBOM každého jobu nese stav úplnosti, takže víte, co posíláte, ještě než to pošlete.
• SBOM se exportují jako CycloneDX nebo SPDX a CRACI podporuje VEX.
• Monitorované SBOM se znovu vyhodnocují, jakmile jsou zveřejněny nové zranitelnosti, a historie buildů v rámci vaší doby uchování ukazuje, které buildy obsahovaly zranitelnou závislost.
• Buildy Yocto běží na runnerech CRACI a jsou zdokumentované.
• Lze přidat SBOM třetích stran, takže nakupované komponenty se monitorují spolu s vašimi vlastními buildy.

Kdy CRACI není řešením

• Nemáte CI, nebo sestavujete na GitLabu, Jenkins či na build serveru. CRACI dnes podporuje jen GitHub Actions; další systémy CI jsou v plánu vývoje.
• Váš firmware se generuje z nástrojů pro modelování bez stahování balíčků. Záznamník buildů tam přidá málo.
• Potřebujete hostovat SBOM pro mnoho OEM na portálu pro sdílení, nebo SBOM podepisovat. CRACI nenabízí ani jedno.
• Vaše buildy musí běžet na vaší vlastní infrastruktuře. Runnery hostované u zákazníka jsou v plánu vývoje.
• Váš zákazník chce doklad o řízení bezpečnosti ve vaší organizaci, například certifikát ISO 27001 nebo odpovědi na dotazník k NIS2. SBOM je důkazem pro část toho, ne certifikací. Vlastní certifikát ISO 27001 společnosti CRACI pokrývá službu CRACI, ne vaši.

SBOM pro dodavatele: časté dotazy

Můj zákazník, OEM, požádal o SBOM. Musím ji dodat?

Často to vyžaduje spíš smlouva než zákon. Pokud komponentu s digitálními prvky uvádíte na trh EU sami, vyžaduje Cyber Resilience Act vaši vlastní SBOM. Jinak je to povinnost OEM, který ji na vás přenáší prostřednictvím náležité péče a dodavatelské smlouvy.

Vztahuje se CRA na komponenty, které prodávám výrobci?

Pokud komponentu uvádíte na trh EU samostatně, ano: čl. 3 bod 1 zahrnuje softwarové nebo hardwarové komponenty uváděné na trh samostatně. Pokud se na trh dostane jen uvnitř produktu OEM, výrobcem je OEM a musí u vaší komponenty jednat s náležitou péčí (čl. 13 odst. 5). Komponenty vozidel se schváleným typem jsou mimo CRA (čl. 2 odst. 2 písm. c)).

Vyžaduje UN R155 nebo ISO/SAE 21434 SBOM?

Ne. R155 SBOM nikde nezmiňuje; vyžaduje, aby výrobce vozidla řídil rizika spojená s dodavateli. ISO/SAE 21434 organizuje práci na kybernetické bezpečnosti s dodavateli prostřednictvím interface agreements. V automobilovém průmyslu přichází SBOM jako smluvní požadavek.

Jaký formát a jaká pole bude OEM očekávat?

Obvykle CycloneDX nebo SPDX v JSON nebo XML, v souladu s CISA 2026 Minimum Elements nebo BSI TR-03183-2: autor a časové razítko a u každé komponenty název, verze, výrobce, package URL nebo CPE, licence a hash, včetně tranzitivních závislostí.

Jak často musím posílat aktualizovanou SBOM?

Pro každou verzi softwaru, kterou dodáte, pokaždé, když opravíte chybu, a s prohlášením VEX nebo bezpečnostním upozorněním, když jste posoudili zranitelnost. Spouštěč dodání sjednejte ve smlouvě.

Odhalí sdílení SBOM naše duševní vlastnictví?

Ne. SBOM uvádí názvy komponent, verze, výrobce, licence, hashe a vztahy, ne zdrojový kód, algoritmy ani kalibrační data. Sdílejte ji v rámci NDA nebo dodavatelské smlouvy s použitím omezeným na správu zranitelností a soulad. CRA nevyžaduje, aby byla veřejná.

Co je VEX a bude ho můj zákazník požadovat?

VEX uvádí, zda je produkt zranitelností zasažen: not_affected, affected, fixed nebo under_investigation, se zdůvodněním u not_affected. Počítejte s tím, že o něj budete požádáni po příští široce medializované zranitelnosti v komponentě, kterou dodáváte.

Firmware naší ECU neobsahuje open source. Jak vypadá naše SBOM?

Krátce a poctivě: proprietární aplikace, bootloader, případné knihovny nebo kalibrace od výrobce čipu a případný open source, například kryptografická knihovna, každá položka s vašimi vlastními identifikátory, a k tomu známé neznámé. Uměle ji nenafukujte.