SBOM jako důkaz souladu: ISO 27001, SOC 2 a NIS2

Důkaz není soulad

Kontrolu splňuje proces, který funguje. Důkaz ukazuje, že funguje. SBOM ukazuje jednu konkrétní věc: co obsahovalo dané vydání. Neukazuje nic o řízení přístupu, reakci na incidenty ani o tom, zda někdo na nález zareagoval.

Může být také chybná způsobem, kterého si nikdo nevšimne. Generátor, který četl špatné soubory, vytvoří platnou SBOM, ve které chybí polovina produktu. Sken zranitelností této SBOM je čistý, platforma pro soulad vidí, že sken proběhl, a každá kontrola svítí zeleně. Co ověřuje zelená kontrola SBOM pro SOC 2 toto selhání podrobně rozebírá.

Důkaz ze SBOM se počítá, když je:

1. Vázaný na vydání. Jedna SBOM pro každou dodanou verzi, ne jedna pro repozitář.
2. Úplný, nebo uvádí, co chybí. SBOM, která uvádí své mezery, je důvěryhodná v tom, co obsahuje.
3. Uchovávaný po dobu, kterou audit pokrývá. Auditor, který vybírá vzorek z loňského března, potřebuje SBOM z loňského března.
4. Znovu kontrolovaný, když se objeví nové zranitelnosti. Seznam, který nikdo neporovnává s novými bezpečnostními upozorněními, o správě zranitelností mnoho nedokazuje.

Co SBOM obsahuje, popisuje článek co je SBOM. Rámce bezpečného vývoje pro průmyslové produkty a federální software v USA popisují IEC 62443-4-1 a NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 je norma, podle které se certifikuje systém řízení bezpečnosti informací (slovník). Příloha A uvádí 93 opatření; organizace vybere ta, která vyžaduje její posouzení rizik, a zaznamená je do prohlášení o aplikovatelnosti (Statement of Applicability). ISO/IEC 27002:2022 dává pokyny k zavedení. Ani jedna z norem SBOM nezmiňuje. Tabulka cituje jen názvy opatření a stručně uvádí, čeho se každé týká.

Opatření	Čeho se týká	Jak SBOM nebo záznam buildu slouží jako důkaz	Co nepokrývá
5.9 „Inventory of information and other associated assets“	Vědět, jaká aktiva máte a kdo je vlastní	Software, který dodáváte a provozujete, je aktivum. Seznam komponent pro každé vydání je inventářem toho, co je uvnitř.	Hardware, data, lidi a služby
5.19 „Information security in supplier relationships“, 5.20 „Addressing information security within supplier agreements“, 5.21 „Managing information security in the ICT supply chain“, 5.22 „Monitoring, review and change management of supplier services“	Řízení rizik spojených s dodavateli a dodavatelským řetězcem ICT	Dva směry. Jako odběratel můžete od dodavatelů vyžadovat SBOM a monitorovat je. Jako dodavatel je vaše SBOM tím, co po vás žádá proces dodavatelského řetězce vašeho certifikovaného zákazníka. Open source komponenty jsou součástí dodavatelského řetězce ICT, ale nepřicházejí s žádnou dodavatelskou smlouvou, a právě proto na jejich inventáři záleží.	Smlouvy, posuzování dodavatelů a přezkumy
8.8 „Management of technical vulnerabilities“	Získávat informace o zranitelnostech, vyhodnocovat svou expozici a jednat	Aktuální seznam komponent porovnávaný s bezpečnostními upozorněními a znovu vyhodnocovaný, když se objeví nová, a k tomu záznam o tom, která vydání obsahovala zranitelnou verzi a od kdy	Záplatování vaší infrastruktury, skenování hostitelů a samotná rozhodnutí
8.25 „Secure development life cycle“	Pravidla pro bezpečný vývoj softwaru a systémů	Zaznamenaný, opakovatelný proces vydávání: každé vydání sestavené ve stejné pipeline, se svou SBOM	Většinu opatření: školení, prostředí, návrh a review
8.26 „Application security requirements“, 8.27 „Secure system architecture and engineering principles“, 8.28 „Secure coding“	Požadavky, návrh a kód	Ne přímo. Týkají se toho, co píšete, ne toho, co stahujete.	Nic z toho: důkazem jsou zde code review, SAST a dokumentace návrhu
8.29 „Security testing in development and acceptance“	Testování bezpečnosti před vydáním	Kontrolní brána politik (policy gate), která zablokuje build kvůli nálezu zranitelnosti, je zaznamenaný test s výsledkem	Funkční testy bezpečnosti, penetrační testy
8.30 „Outsourced development“	Řízení a monitorování vývoje, který zadáváte externě	Externě vyvinutý kód sestavený ve vaší pipeline dostane stejnou SBOM a stejné kontroly jako váš vlastní	Smlouvu, vlastní postupy dodavatele

U opatření 8.25 až 8.30 buďte poctiví: většina toho, co požadují, leží mimo SBOM. Tvrdit víc je nejrychlejší způsob, jak u auditora ztratit důvěru i ve zbytek.

Praktický příklad: auditor se ptá na 8.8

„Jak poznáte, že nová zranitelnost postihuje produkt, který jste už dodali?“ Zde je řetězec důkazů pro jedno bezpečnostní upozornění a kdo poskytuje který článek.

Krok	Důkaz	Pochází z
1. Obsah vydání	SBOM verze 4.2, zaznamenaná buildem, který ji vytvořil	Vaše nástroje pro build
2. Shoda s bezpečnostním upozorněním	Nové CVE zveřejněné pro knihovnu v této SBOM, spárované podle její package URL	Vaše monitorování zranitelností
3. Období expozice	Každý build, který obsahoval zranitelnou verzi, a datum prvního z nich	Vaše historie buildů
4. Rozhodnutí	Kdo to posoudil, kdy a s jakým výsledkem: oprava, zmírnění nebo nedotčeno, s odůvodněním	Váš proces a jeho záznamy
5. Oprava	Verze 4.2.1, jejíž SBOM už zranitelnou verzi neobsahuje	Vaše nástroje pro build

Kroky 1, 2, 3 a 5 mohou dodat nástroje. Krok 4 je váš proces a je to krok, který auditoři čtou nejpečlivěji.

SOC 2

Zpráva SOC 2 uvádí, zda kontroly splňují kritéria Trust Services Criteria organizace AICPA (2017, s body zaměření revidovanými v roce 2022). Kritéria jsou formulována jako výsledky. SBOM nezmiňují a SBOM pomáhá u dvou z nich.

• CC7.1 požaduje, aby subjekt používal postupy detekce a monitorování k identifikaci (1) změn konfigurací, které vedou k zavedení nových zranitelností, a (2) náchylnosti k nově objeveným zranitelnostem. Důkaz: SBOM pro každé vydání, znovu vyhodnocovaná vůči novým bezpečnostním upozorněním, a záznam o tom, jak byl každý nález vyřešen.
• CC8.1 pokrývá řízení změn: jak jsou změny infrastruktury, dat, softwaru a postupů autorizovány, vyvíjeny nebo pořizovány, testovány, schvalovány a zaváděny. Důkaz: každé vydání sestavené v zaznamenávané pipeline, změna závislostí viditelná z jednoho buildu na další a kontrolní brány politik (policy gates) jako kontrola toho, co smí být vydáno.

Kritéria procházejí revizí. V říjnu 2026 zveřejnila AICPA návrh (exposure draft) Trust Services Criteria 2027 s cílenou restrukturalizací kritérií, lhůtou pro připomínky do 15. ledna 2027 a navrhovanou účinností pro zakázky zahájené 31. prosince 2027 nebo později. Jde o návrh a čísla kritérií se mohou změnit: než důkazy namapujete na nová čísla, ověřte si konečné znění.

Pokud už platformu pro SOC 2 používáte, ponechte si ji. Otázkou je, co ukazuje SBOM, o kterou se její kontroly opírají: srovnání kontrol SBOM pro SOC 2.

NIS2

Směrnice NIS2 (EU) 2022/2555 se vztahuje na základní a důležité subjekty v odvětvích, která vyjmenovává. Pokud tento text čtete jako dodavatel softwaru nebo zařízení, obvykle sami do její působnosti nespadáte. Spadá do ní váš zákazník a jeho povinnosti k vám dorazí v podobě otázek. Článek 21 stanoví opatření k řízení kybernetických bezpečnostních rizik a většinu těchto otázek vyvolávají tři pasáže:

• Čl. 21 odst. 2 písm. d): „bezpečnost dodavatelského řetězce včetně bezpečnostních aspektů týkajících se vztahů mezi každým subjektem a jeho přímými dodavateli nebo poskytovateli služeb“.
• Čl. 21 odst. 2 písm. e): „zabezpečení pořizování, vývoje a údržby sítí a informačních systémů, včetně zveřejňování zranitelností a jejich řešení“.
• Čl. 21 odst. 3: subjekty mají zohlednit „zranitelnosti specifické pro každého přímého dodavatele a poskytovatele služeb a celkovou kvalitu produktů a postupů v oblasti kybernetické bezpečnosti svých dodavatelů a poskytovatelů služeb, včetně jejich postupů bezpečného vývoje“. Právě z této věty se stane dotazník na vašem stole.

Prováděcí nařízení (EU) 2024/2690

Prováděcí nařízení Komise (EU) 2024/2690 ze dne 17. října 2024 stanoví technické a metodické požadavky na opatření podle čl. 21 odst. 2 pro poskytovatele služeb DNS, registry názvů domén nejvyšší úrovně, poskytovatele služeb cloud computingu, poskytovatele služeb datových center, poskytovatele sítí pro doručování obsahu, poskytovatele řízených služeb, poskytovatele řízených bezpečnostních služeb, online tržiště, internetové vyhledávače, platformy sociálních sítí a poskytovatele služeb vytvářejících důvěru. Ostatní odvětví NIS2 nezavazuje, ale je nejpodrobnějším veřejným vyjádřením toho, co „bezpečnost dodavatelského řetězce“ znamená, a další odběratelé si z něj berou. Body, které se dotýkají dodavatelů:

Bod přílohy	Co říká	Na co se dodavatele ptají
5.1.2(a)	Kritéria pro výběr dodavatelů zahrnují „postupy kybernetické bezpečnosti dodavatelů a poskytovatelů služeb, včetně jejich postupů k zajištění bezpečného vývoje“	Jak vyvíjíte bezpečně a jak víte, co jde do vašeho produktu?
5.1.4(e) a (f)	Smlouvy v případě potřeby stanoví „právo provést audit nebo právo obdržet auditní zprávy“ a „povinnost dodavatelů a poskytovatelů služeb řešit zranitelnosti, které představují riziko“ pro bezpečnost sítí a informačních systémů subjektu	Budete řešit zranitelnosti v tom, co dodáváte, a můžeme vidět důkazy?
5.2	Registr přímých dodavatelů, který obsahuje „seznam produktů IKT, služeb IKT a procesů IKT“ poskytovaných každým z nich	Které produkty a verze nám dodáváte?
6.1.2(c)	Při pořizování služeb IKT nebo produktů IKT: „informace popisující hardwarové a softwarové komponenty používané ve službách IKT nebo produktech IKT“	Jaké hardwarové a softwarové komponenty váš produkt obsahuje? Ze všech textů na této stránce má nejblíže k SBOM, a přesto ji nezmiňuje.
6.10	Řešení zranitelností: sledovat informace o zranitelnostech prostřednictvím kanálů, jako jsou oznámení týmů CSIRT nebo „informace poskytované dodavateli či poskytovateli služeb“ (6.10.2(a)), a pokud zranitelnost nevyžaduje nápravu, „zdokumentují a zdůvodní, proč“ (6.10.3)	Jak nás budete o zranitelnostech informovat a proč tahle není problém?

Poslední bod popisuje prohlášení o nedotčenosti s odůvodněním. Přesně to nese dokument VEX, i když nařízení žádný formát nezmiňuje.

Praktický příklad: dotazník od zákazníka podléhajícího NIS2

Pět otázek, jaké zákazník z těchto bodů odvozuje, s důkazy, které může dodavatel přiložit. Některé odpovědi pocházejí ze záznamů, které vedou vaše nástroje, jiné jsou politiky, které píšete vy.

Otázka	Důkaz k přiložení	Záznam, nebo politika
„Uveďte softwarové komponenty ve verzi produktu, kterou nám dodáváte.“ (6.1.2(c))	SBOM této verze v CycloneDX nebo SPDX s uvedenou úplností	Záznam
„Popište, jak řešíte zranitelnosti a v jakých lhůtách.“ (5.1.4(f))	Váš postup řešení zranitelností s úrovněmi závažnosti a cílovými lhůtami	Politika
„Které z verzí, které provozujeme, obsahovaly zranitelnou knihovnu a od kdy?“ (6.10)	Historie buildů ukazující každý build, který komponentu obsahoval, s daty	Záznam
„Proč se nás toto CVE netýká?“ (6.10)	Prohlášení o nedotčenosti s odůvodněním, například „zranitelný kód není přítomen“	Záznam na základě vašeho posouzení
„Jak mohou výzkumníci hlásit zranitelnosti ve vašich produktech?“ (5.1.2(a))	Vaše politika koordinovaného zveřejňování zranitelností	Politika

Jeden rozdíl je třeba mít na paměti: u produktů s digitálními prvky prodávaných v EU Cyber Resilience Act SBOM vyžaduje. NIS2 ne.

DORA, pokud prodáváte finančním subjektům

Nařízení o digitální provozní odolnosti (DORA), nařízení (EU) 2022/2554, se vztahuje na finanční subjekty, ne přímo na jejich dodavatele. Finanční subjekty musí identifikovat a dokumentovat svá aktiva IKT a jejich vzájemné závislosti a vést jejich inventáře (čl. 8 odst. 1, 4 a 6), řídit rizika vyplývající z využívání třetích stran v oblasti IKT jako součást svých rizik IKT (čl. 28 odst. 1), vést registr informací o všech svých smlouvách o službách IKT (čl. 28 odst. 3) a zahrnout do těchto smluv minimální ustanovení (článek 30). DORA SBOM nezmiňuje. Dodavateli softwaru pro banku pomůže seznam komponent pro každé vydání tím, že zákazníkovi usnadní splnění článku 8.

Jedna mapa důkazů pro všechny

Řádky jsou jednotlivé důkazy; každá buňka uvádí opatření, kritérium nebo bod, který podporují, případně „ne přímo“.

Důkaz	ISO/IEC 27001:2022	SOC 2	NIS2 a 2024/2690	DORA
1. SBOM pro každé vydání s uvedenou úplností	5.9, 5.21, 8.8	CC7.1	čl. 21 odst. 2 písm. d); 6.1.2(c)	čl. 8 (inventář zákazníka)
2. Průběžné opětovné vyhodnocování vůči novým bezpečnostním upozorněním	8.8	CC7.1	čl. 21 odst. 2 písm. e); 6.10	Ne přímo
3. Historie buildů: která vydání obsahovala komponentu a od kdy	8.8	CC7.1, CC8.1	6.10	Ne přímo
4. Záznamy o triáži a směrování	8.8	CC7.1	čl. 21 odst. 2 písm. e); 6.10	Ne přímo
5. Prohlášení o nedotčenosti s odůvodněním	8.8	CC7.1	6.10	Ne přímo
6. Kontrolní brány politik, které blokují build	8.25, 8.29	CC8.1	čl. 21 odst. 2 písm. e)	Ne přímo
7. SBOM dodavatelů monitorované spolu s vašimi	5.19, 5.21, 5.22	CC7.1	čl. 21 odst. 2 písm. d), čl. 21 odst. 3; 5.2, 6.10	čl. 28 odst. 1
8. Egress policy a síťové záznamy buildu	8.25	CC8.1	čl. 21 odst. 2 písm. d)	Ne přímo

Co SBOM nedokáže

• Vaše řízení přístupu, reakci na incidenty, kontinuitu činností, personální bezpečnost, kryptografii ani fyzickou bezpečnost.
• Že někdo něco opravil. To je váš proces a jeho záznamy.
• Že váš vlastní kód je bez chyb. Důkazem pro to jsou code review, SAST a testování.
• Co je uvnitř binárek, které jste dostali bez SBOM.
• Že jste certifikovaní. SBOM není certifikát a certifikát, který má dodavatel vašeho nástroje, certifikuje jeho vlastní systém řízení, ne vás.

Jak do toho zapadá CRACI

CRACI nahrazuje vaše runnery hostované na GitHubu a zaznamenává, co každý build stáhl, takže SBOM pochází přímo z release buildu, se stavem úplnosti pro každý job.

• Monitorované SBOM se průběžně znovu vyhodnocují, jak se zveřejňují nové zranitelnosti (sledování zranitelností).
• Historie buildů v rámci vaší doby uchovávání ukazuje, které buildy obsahovaly zranitelnou závislost, a tedy období, kdy jste byli vystaveni. Pokud váš audit pokrývá delší období, exportujte SBOM každého vydání a uchovávejte ji spolu s vydáním.
• Bezpečnostní týmy provádějí triáž nalezených zranitelností a posílají je týmům, které vlastní opravu, a CRACI podporuje VEX pro zaznamenání, kterých produktů se zranitelnost netýká.
• Kontrolní brány politik (policy gates) mohou zablokovat build na základě nálezů, včetně buildu, který obsahuje konkrétní CVE.
• Lze přidat SBOM třetích stran, takže se nakoupené komponenty monitorují spolu s vašimi vlastními buildy.
• SBOM se exportují jako CycloneDX nebo SPDX a API vrací SBOM, síťové záznamy a data o původu (provenance). Egress policy zaznamenává a omezuje, kam se každý build smí připojit.

CRACI dodává důkazy pro tato opatření. Nezajistí vám soulad s ISO 27001 ani SOC 2, ani připravenost na NIS2, a není platformou pro automatizaci souladu. Vlastní certifikát CRACI je samostatná skutečnost: systém řízení bezpečnosti informací společnosti CRACI Corporation Oy pro vývoj a provoz platformy CRACI je certifikován podle ISO/IEC 27001, certifikát vydala společnost Into Certification. Pokrývá to, jak CRACI provozuje svou službu, ne vaši organizaci ani vaše produkty. Viz bezpečnost v CRACI a jak CRACI funguje pro celou platformu.

Kdy CRACI není řešením

• Vaše buildy neběží v GitHub Actions. To je jediné CI, které CRACI dnes podporuje; další systémy CI jsou v plánu vývoje.
• Potřebujete platformu pro automatizaci souladu pro politiky, přezkumy přístupů a workflow s auditorem. Ponechte si ji nebo si ji pořiďte; viz srovnání kontrol SBOM pro SOC 2.
• Vaše mezera v důkazech je převážně organizační: politiky, školení, reakce na incidenty.
• Vaším hlavním rizikem u dodavatelů jsou binárky, které dostáváte bez SBOM. Na to odpovídá binární analýza.

Odpovídáte na požadavek jednoho zákazníka? Viz jak odpovědět na požadavek zákazníka na SBOM, průvodce pro dodavatele komponent a checklist, který použije váš zákazník.

SBOM jako důkaz souladu: časté dotazy

Vyžaduje ISO 27001 SBOM?

Ne. ISO/IEC 27001:2022 SBOM nezmiňuje. Opatření přílohy A 5.9 (inventář), 5.21 (dodavatelský řetězec ICT) a 8.8 (technické zranitelnosti) požadují výsledky, které SBOM podporuje, a o tom, jaký důkaz stačí, rozhoduje organizace a její auditor.

Vyžaduje SOC 2 SBOM?

Ne. Trust Services Criteria jsou formulována jako výsledky a SBOM nezmiňují. SBOM pro každé vydání, znovu vyhodnocovaná vůči novým bezpečnostním upozorněním, je důkazem pro CC7.1 a zaznamenávaná pipeline buildu podporuje CC8.1 o řízení změn.

Vyžaduje NIS2 SBOM?

Ne. Čl. 21 odst. 2 písm. d) požaduje bezpečnost dodavatelského řetězce a písm. e) řešení zranitelností, aniž by SBOM zmiňoval. Prováděcí nařízení (EU) 2024/2690, které se týká určitých poskytovatelů digitálních služeb, požaduje v bodě 6.1.2(c) informace o hardwarových a softwarových komponentách produktů IKT, stále bez slova SBOM.

Která opatření přílohy A ISO 27001 SBOM podporuje?

Hlavně 5.9 (inventář informací a dalších souvisejících aktiv), 5.19 až 5.22 (dodavatelé a dodavatelský řetězec ICT) a 8.8 (řízení technických zranitelností). Záznam buildu se částečně dotýká 8.25, 8.29 a 8.30. Opatření 8.26 až 8.28 se týkají požadavků, návrhu a kódu, tedy oblastí mimo SBOM.

Co zákazníci podléhající NIS2 žádají od svých dodavatelů softwaru?

Obvykle popis bezpečného vývoje, komponenty v dodané verzi, závazek řešit zranitelnosti, způsob, jak přijímat informace o zranitelnostech, a odůvodnění, když se zranitelnost netýká. Tyto otázky vycházejí z čl. 21 odst. 3 a u některých odvětví z bodů o dodavatelích v prováděcím nařízení 2024/2690.

Je SBOM dostatečným důkazem pro opatření 8.8 normy ISO 27001?

Ne. Ukazuje, co každé vydání obsahuje. Opatření 8.8 vyžaduje také důkaz, že získáváte informace o zranitelnostech, vyhodnocujete svou expozici a jednáte. Doplňte SBOM o průběžné opětovné vyhodnocování, záznam o dotčených vydáních a rozhodnutí, která jste učinili.

Jaký je rozdíl mezi souladem a tím, že máte důkazy?

Soulad znamená, že vaše procesy splňují požadavky rámce podle posouzení auditora nebo zákazníka. Důkazy jsou to, co ukazuje, že tyto procesy fungují. SBOM je důkazem pro několik opatření. Do souladu s žádným rámcem vás sama nedostane.