Co je SBOM a co o něm říká Cyber Resilience Act?

Jak SBOM definuje CRA a co do něj nepatří?

Akt o kybernetické odolnosti (Cyber Resilience Act, nařízení (EU) 2024/2847) definuje softwarový kusovník jako „formální záznam obsahující podrobné informace o komponentách obsažených v softwarových prvcích produktu s digitálními prvky a o vztazích těchto komponent k dodavatelskému řetězci“ (čl. 3 bod 39). NÚKIB ho zjednodušeně přirovnává k seznamu ingrediencí softwaru. Komponentou může být vlastní modul, knihovna třetí strany, open-source balíček nebo firmware od dodavatele.

Zranitelnosti do SBOM nepatří. Kusovník popisuje jednu konkrétní verzi produktu a ta se nemění, kdežto informace o zranitelnostech přibývají každý den. Německý Spolkový úřad pro bezpečnost informačních technologií (BSI) proto ve své technické směrnici TR-03183-2 stanoví, že SBOM informace o zranitelnostech obsahovat nesmí, a doporučuje pro ně formát CSAF včetně profilu VEX (oddíl 8.1.14).

Co přesně CRA požaduje od SBOM?

Požadavek je v příloze I, části II, bodě 1. Výrobci podle něj „určí a zdokumentují zranitelnosti a komponenty obsažené v produktech s digitálními prvky, mj. na základě vypracování softwarového kusovníku (SBOM) v běžně používaném strojově čitelném formátu, který obsahuje přinejmenším nejdůležitější závislosti produktu“. Z jedné věty plynou tři podmínky:

• Běžně používaný formát. Konkrétní formát nařízení nejmenuje. Komise ho může stanovit prováděcím aktem s ohledem na evropské a mezinárodní normy (čl. 13 odst. 24). Běžně se používají SPDX a CycloneDX.
• Strojově čitelný. Kusovník musí umět přečíst program, nejen člověk. Seznam knihoven v PDF nebo ve Wordu podmínku nesplní.
• Alespoň přímé závislosti. České znění píše „nejdůležitější závislosti“, anglické „top-level dependencies“, tedy závislosti nejvyšší úrovně. BSI takový kusovník nazývá top-level SBOM: kromě samotného produktu obsahuje úplný popis všech komponent, na kterých produkt přímo závisí.

SBOM je jen jedna z povinností přílohy I. Jestli se CRA na váš produkt vůbec vztahuje a jakým postupem budete posuzovat shodu, zjistíte zdarma v kontrole produktu podle CRA.

Od kdy SBOM podle CRA potřebuji?

Povinně od 11. prosince 2027, a to u produktů, které od toho dne uvádíte na trh (čl. 71 odst. 2). U hardwaru se uvedením na trh myslí každý jednotlivý kus: zařízení uvedené na trh od 11. 12. 2027 potřebuje SBOM, i když jeho typ vznikl dřív (pokyny Komise, body 11 a 39). Verze samostatného softwaru, kterou nabízíte už před tímto dnem, SBOM podle CRA mít nemusí, dokud neprojde podstatnou změnou (čl. 69 odst. 2; pokyny Komise, body 13 a 14).

Pokyny Komise z 27. července 2026 to potvrzují: u produktů uvedených na trh před 11. prosincem 2027 výrobce nemusí plnit požadavky přílohy I části II, kam SBOM patří. Hlásit ale musí i po skončení doby podpory (bod 210).

K čemu SBOM v praxi potřebujete?

Hlavně k rychlé odpovědi na otázku, kde máte zranitelnou komponentu. Objeví-li se zpráva o zneužívané zranitelnosti v rozšířené knihovně, musíte zjistit, které verze kterých vašich produktů ji obsahují. Se SBOM pro každé vydání odpovíte jedním dotazem. Bez něj procházíte repozitáře a sestavení ručně.

Hlásí se jen zranitelnost zneužitá ve vašem produktu: včasné varování do 24 hodin, oznámení do 72 hodin (čl. 14 odst. 2; pokyny Komise, bod 218). Kdy povinnost vzniká, rozebíráme na stránce hlášení zranitelností podle CRA. Najdete tam i 30denní hlídání CVE zdarma, ve kterém vám SBOM pro jeden produkt z nejvýše tří repozitářů vytvoříme.

Od 11. prosince 2027 přibude druhý důvod. Na základě posouzení kybernetických bezpečnostních rizik a v příslušných případech pak musí být produkt dodáván na trh bez známých zneužitelných zranitelností (příloha I část I bod 2 písm. a). Za známou Komise považuje mimo jiné zranitelnost uvedenou v relevantní veřejně dostupné databázi, například v evropské databázi zranitelností (pokyny Komise, body 230, 233 a 237). Porovnat produkt s databází jde v praxi jen přes seznam jeho komponent.

Musím SBOM zveřejnit, nebo ho jen předat na žádost?

Zveřejnit ho nemusíte: podle recitálu 77 by výrobci neměli mít povinnost softwarový kusovník zveřejnit. SBOM je součástí technické dokumentace (příloha VII bod 2 písm. b). Tu uchováváte nejméně 10 let od uvedení produktu na trh nebo po dobu podpory, podle toho, co trvá déle (čl. 13 odst. 13). Kusovník dostane:

• orgán dozoru nad trhem na odůvodněnou žádost, pokud ho potřebuje k ověření souladu s přílohou I (příloha VII bod 8)
• orgán dozoru nad trhem na žádost také tehdy, když se specializovaná skupina pro správní spolupráci (ADCO) rozhodne provést pro vaši kategorii produktů celounijní posouzení závislosti na softwarových komponentách; skupině pak orgány mohou poskytnout anonymizované souhrnné informace o závislosti na softwaru (čl. 13 odst. 25)
• uživatelé, jen když se tak sami rozhodnete; v pokynech pro uživatele pak uvedete, kde kusovník najdou (příloha II bod 9)

Dodáváte-li komponentu, kterou zákazník zabuduje do svého produktu, musíte mu dát informace potřebné ke splnění příloh I a VII (příloha II bod 8 písm. f). SBOM tam jmenovitě uveden není. Zákazník ale hlásí i zranitelnosti ve vaší komponentě a k tomu potřebuje vědět, co obsahuje. Počítejte proto s tím, že o kusovník požádá.

SPDX, nebo CycloneDX?

Pro CRA vyhoví oba formáty, nařízení žádný nepreferuje. Oba jsou otevřené normy a v obou se podle BSI licence zapisují identifikátory SPDX, například Apache-2.0 nebo MIT.

Vyberte formát, ve kterém SBOM vygenerují vaše nástroje pro sestavení a který přečtou vaši odběratelé. BSI v příloze (oddíl 8.2) upozorňuje, že se struktury obou formátů liší a ani jeden nemá všechna pole, která směrnice požaduje. Chybějící údaje se proto zapisují jako dvojice klíč–hodnota z taxonomie BSI.

Jak vypadá vyplněný SBOM podle BSI TR-03183-2?

Technická směrnice BSI TR-03183-2, verze 2.1.0 z 20. srpna 2025, určuje, která pole má SBOM mít. Pro české výrobce závazná není a CRA na ni neodkazuje. Hodí se ale jako kontrolní seznam. Na úrovni celého kusovníku vyžaduje e-mail jeho tvůrce (není-li k dispozici, tak URL) a časovou značku, u každé komponenty pak deset povinných údajů. Soubor musí být ve formátu JSON nebo XML.

Co do rozsahu jde BSI dál než CRA: závislosti chce rozepsat v každé větvi stromu až k první komponentě, která už není součástí dodávky, a tu ještě zahrnout. Pokud existují, přidejte i URI zdrojového kódu, odkaz ke stažení, identifikátory CPE nebo purl a původní licence.

Produkt sám je zapsaný v metadata.component a tabulka ukazuje jednu jeho přímou závislost, knihovnu requests pro Python. Příznaky odpovídají tabulce 7 směrnice, kde je instalační balíček (rpm) veden jako nespustitelný strukturovaný archiv; balíček wheel je na tom stejně. Otisk SHA-512 má 128 šestnáctkových znaků a počítá se z dodávaného souboru.

Časté otázky

Stačí SBOM jen s přímými závislostmi?

Jako minimum podle přílohy I ano. Pro hlášení podle čl. 14 ale nestačí: aktivně zneužívaná zranitelnost může být i v nepřímé závislosti a v kusovníku s jednou úrovní ji nenajdete. Doporučujeme proto generovat celý strom závislostí.

Patří do SBOM i vývojové a testovací knihovny?

Pokud je s produktem nedodáváte, ne. CRA požaduje zdokumentovat komponenty obsažené v produktu a BSI rozsah vymezuje tím, co se s produktem dodává; části, které se pořizují zvlášť, do něj nepatří (TR-03183-2, oddíl 8.1.11).

Vygeneruje SBOM nástroj sám?

Z manifestů a lockfilů většinu komponent ano. Nevidí ale, co v žádném manifestu není: zkopírovaný zdrojový kód, přibalené binární knihovny nebo firmware dodavatele. To je potřeba doplnit ručně nebo analýzou hotového sestavení a pak SBOM ověřit proti schématu formátu.

Co hrozí, když SBOM chybí?

U produktu uvedeného na trh od 11. prosince 2027 jde o nesplnění přílohy I. Za nedodržení přílohy I a povinností podle čl. 13 a 14 hrozí pokuta až 15 mil. € nebo 2,5 % celosvětového ročního obratu za předchozí finanční rok, podle toho, co je vyšší (čl. 64 odst. 2).