Srovnání
Soulad s CRA: požadavky na SBOM a nástroje
Cyber Resilience Act činí softwarový kusovník povinným pro produkty s digitálními prvky. Zde je, co od něj nařízení požaduje, co přidává německá směrnice BSI a jak si stojí nástroje pro soulad s CRA.
Aktualizováno
Každé srovnání říká, v čem je druhý produkt dobrý, čím se CRACI liší a kdy byste použili oba. Všechny kategorie najdete v sekci všechna srovnání.
Co CRA požaduje od SBOM
Cyber Resilience Act, nařízení (EU) 2024/2847, řadí SBOM mezi požadavky na řešení zranitelností. Požaduje méně, než si mnozí myslí: strojově čitelný záznam přinejmenším nejdůležitějších závislostí produktu, uložený v technické dokumentaci a předložený orgánu na vyžádání. Zde je, co nařízení říká, otázku po otázce.
| Funkce | Co říká CRA | Kde |
|---|---|---|
| Je SBOM povinná? | Ano. Výrobci musí identifikovat a zdokumentovat komponenty svých produktů, mimo jiné vypracováním softwarového kusovníku | Příloha I, část II, bod 1 |
| Co je SBOM? | Formální záznam obsahující podrobnosti a vztahy v dodavatelském řetězci komponent obsažených v softwarových prvcích produktu s digitálními prvky | Článek 3, bod 39 |
| Jaký formát? | CRA požaduje „běžně používaný a strojově čitelný formát“. Komise může formát a prvky stanovit prováděcími akty | Příloha I, část II, bod 1; čl. 13 odst. 24 |
| Do jaké hloubky? | „Přinejmenším nejdůležitější závislosti produktu“ | Příloha I, část II, bod 1 |
| Kam patří? | Do technické dokumentace, jako součást informací o řešení zranitelností | Příloha VII, bod 2 písm. b) |
| Musí být veřejná? | Ne. Výrobci by neměli být povinni SBOM zveřejňovat. Pokud ji sdílíte s uživateli, informace pro uživatele uvádějí, kde ji najdou | Bod odůvodnění 77; příloha II, bod 9 |
| Kdo si ji může vyžádat? | Orgán dozoru nad trhem, na základě odůvodněné žádosti, za účelem ověření souladu. Orgány si mohou SBOM vyžádat také pro posouzení závislostí v celé EU | Příloha VII, bod 8; čl. 13 odst. 25 |
| Jak dlouho ji uchovávat? | Technická dokumentace se uchovává nejméně 10 let po uvedení produktu na trh, nebo po dobu podpory, podle toho, co je delší | Čl. 13 odst. 13 |
Nařízení se v plném rozsahu použije od 11. prosince 2027 a jeho oznamovací povinnosti platí od 11. září 2026. Zbytek nařízení popisuje stránka co CRA požaduje.
Nad rámec minima: BSI TR-03183-2
Dokud Komise formát nestanoví prováděcím aktem, nejpodrobnější veřejné pokyny pocházejí od německého Spolkového úřadu pro bezpečnost v informační technice (BSI). Jeho technická směrnice TR-03183-2, verze 2.1.0 ze srpna 2025, je doporučením, nikoli součástí nařízení, ale ukazuje, kam se očekávání posouvají:
- Formát: JSON nebo XML, validní vůči CycloneDX 1.6 nebo vyšší, nebo SPDX 3.0.1 nebo vyšší.
- Hloubka: rekurzivní řešení závislostí pro každou komponentu v rozsahu dodávky, až po první komponentu mimo něj včetně.
- Zdroj pravdy: SBOM musí obsahovat „stejné informace, jaké jsou k dispozici během procesu buildu“, nebo rovnocenné informace tam, kde proces buildu neexistuje.
Směrnice také pojmenovává druhy SBOM. Build SBOM „vzniká jako součást procesu buildu“. Analysed SBOM „vzniká po procesu buildu analýzou artefaktů, jako jsou spustitelné soubory, balíčky, kontejnery a image virtuálních strojů“. Právě toto rozlišení je hlavním rozdílem mezi nástroji na této stránce.
Přímé, nebo tranzitivní závislosti
Nejdůležitější závislosti produktu, které CRA požaduje, jsou minimum, ne cíl. Zranitelnost v tranzitivním balíčku je stále ve vašem produktu a CRA po výrobcích chce řešit a odstraňovat zranitelnosti v komponentách, které dodávají. SBOM, která končí na první úrovni, tyto balíčky vynechává z vašeho řešení zranitelností. Praktická otázka nezní, zda tranzitivní závislosti zaznamenávat, ale jak si být jistí, že záznam odpovídá tomu, co bylo dodáno. Jak je vypsat a opravit ty zranitelné, popisuje stránka tranzitivní závislosti.
Build SBOM, nebo analysed SBOM
Většina nástrojů SBOM generuje analysed SBOM po buildu, nebo spravuje SBOM, které vytvářejí jiné nástroje. CRACI zaznamenává build SBOM během běhu buildu. Srovnání generátorů a nástrojů pro správu SBOM najdete na stránkách správa SBOM a srovnání nástrojů SBOM. Nástroje postavené kolem CRA popisuje stránka srovnání nástrojů pro soulad s CRA.
Kam zapadá CRACI
CRACI zaznamenává SBOM během běhu vašeho buildu v GitHub Actions. Proxy na runneru, která rozpoznává balíčky, zaznamenává každý balíček, který si job stáhl, včetně balíčků obnovených z cache CI, takže SBOM popisuje build, který vytvořil artefakt, a ne sken, který proběhl někde poblíž. SBOM každého jobu nese stav úplnosti a exporty v CycloneDX a SPDX obsahují tranzitivní závislosti a deklarovanou licenci každé komponenty.
Po vydání CRACI průběžně znovu vyhodnocuje monitorované SBOM, jakmile se objeví nové zranitelnosti, a připravuje obsah oznámení podle CRA (včasné varování, oznámení a závěrečná zpráva), která pak podáváte vy. API vrací SBOM, síťové stopy a data o původu. CRACI uchovává data buildů ve výchozím nastavení 180 dní, s vlastní dobou uchovávání v plánu Enterprise, takže exportujte to, co patří do vaší technické dokumentace uchovávané 10 let. CRACI automatizuje významnou část přehledu o dodavatelském řetězci a důkazů, které váš proces CRA potřebuje; posouzení shody a technická dokumentace zůstávají na výrobci. Všechny požadavky CRA jako plán krok za krokem najdete v průvodci CRA. Přečtěte si více o generování SBOM během buildu, nebo si rezervujte demo a podívejte se na SBOM zaznamenanou z jednoho z vašich buildů.
CRACI ve srovnání s jednotlivými nástroji
- CRACI vs Cybeats Systém evidence SBOM vs zaznamenané a monitorované SBOM.
- CRACI vs FOSSA Správa SBOM vs build, SBOM a monitorování v jednom.
- CRACI vs Anchore Skenování image vs zaznamenávání a monitorování buildů.
- CRACI vs Black Duck Skenování kódu, úryvků a binárek vs důkazy z buildu.
- CRACI vs Sonatype Kontrola na úrovni repozitáře a SCA vs důkazy z buildu.
- CRACI vs ONEKEY Binární analýza firmwaru vs důkazy z doby buildu.
- CRACI vs Finite State Analýza binárek a SBOM od dodavatelů vs záznam buildu.
- CRACI vs Exein Runtime bezpečnost na zařízení vs důkazy z buildu.
Vedle sebe
Několik nástrojů na jedné stránce, když vybíráte kategorii, ne jeden produkt.
Otázky k SBOM podle CRA a odpovědi
Vyžaduje CRA v SBOM tranzitivní závislosti?
Nařízení stanoví minimum jako „přinejmenším nejdůležitější závislosti produktu“ (příloha I, část II, bod 1). Tranzitivní závislosti nejsou výslovně uvedeny, ale zranitelný tranzitivní balíček je stále ve vašem produktu a CRA po vás chce řešit zranitelnosti v komponentách, které dodáváte. Německá směrnice BSI TR-03183-2 jde dál a požaduje rekurzivní řešení závislostí.
Musí být SBOM podle CRA veřejná?
Ne. Bod odůvodnění 77 uvádí, že výrobci by neměli být povinni SBOM zveřejňovat. Patří do technické dokumentace a orgán dozoru nad trhem si ji může vyžádat odůvodněnou žádostí. Pokud se ji rozhodnete sdílet s uživateli, informace dodávané s produktem musí uvádět, kde ji najdou (příloha II, bod 9).
Má být SBOM pro CRA ve formátu CycloneDX, nebo SPDX?
CRA požaduje „běžně používaný a strojově čitelný formát“ a žádný konkrétní neuvádí; Komise může formát stanovit prováděcím aktem (čl. 13 odst. 24). CycloneDX a SPDX jsou dvě běžné volby. BSI TR-03183-2 v2.1.0 přijímá CycloneDX 1.6 nebo vyšší a SPDX 3.0.1 nebo vyšší, v JSON nebo XML.
Jak dlouho musím SBOM uchovávat?
SBOM je součástí technické dokumentace, kterou výrobci uchovávají k dispozici orgánům dozoru nad trhem nejméně 10 let po uvedení produktu na trh, nebo po dobu podpory, je-li delší (čl. 13 odst. 13).
Od kdy platí požadavky CRA na SBOM?
Oznamovací povinnosti podle CRA platí od 11. září 2026 a nařízení se v plném rozsahu, včetně požadavku na SBOM v příloze I, použije od 11. prosince 2027.
Další kategorie
Vyzkoušejte CRACI na vlastní pipeline
Rezervujte si demo a společně projdeme vaše buildy, vaše SBOM a vaše důkazy o souladu.
Rezervujte si demo