SBOM jako dowód zgodności: ISO 27001, SOC 2 i NIS2

Dowód to nie zgodność

Kontrolę spełnia działający proces. Dowód pokazuje, że działa. SBOM pokazuje jedną konkretną rzecz: co zawierało dane wydanie. Nie mówi nic o kontroli dostępu, reagowaniu na incydenty ani o tym, czy ktoś zajął się ustaleniem.

Może też być błędny w sposób, którego nikt nie zauważy. Generator, który odczytał niewłaściwe pliki, tworzy poprawny SBOM pomijający połowę produktu. Skan podatności tego SBOM jest czysty, platforma zgodności widzi, że skan się odbył, a każda kontrola świeci na zielono. Co weryfikuje zielona kontrola SBOM w SOC 2 szczegółowo omawia ten błąd.

Dowód z SBOM się liczy, gdy SBOM jest:

1. Powiązany z wydaniem. Jeden SBOM na każdą dostarczoną wersję, a nie jeden dla repozytorium.
2. Kompletny lub mówi, czego mu brakuje. SBOM, który podaje swoje luki, jest wiarygodny w tym, co wymienia.
3. Przechowywany przez okres objęty audytem. Audytor, który bierze próbkę z marca ubiegłego roku, potrzebuje SBOM z marca ubiegłego roku.
4. Ponownie sprawdzany, gdy pojawiają się nowe podatności. Lista, której nikt nie porównuje z nowymi biuletynami, niewiele dowodzi o zarządzaniu podatnościami.

Co zawiera SBOM, wyjaśnia czym jest SBOM. Ramy bezpiecznego wytwarzania dla produktów przemysłowych i oprogramowania federalnego USA opisują IEC 62443-4-1 i NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 to norma, według której certyfikuje się system zarządzania bezpieczeństwem informacji (słownik). Załącznik A wymienia 93 kontrole; organizacja wybiera te, których wymaga jej ocena ryzyka, i zapisuje je w deklaracji stosowania (Statement of Applicability). ISO/IEC 27002:2022 zawiera wytyczne wdrożeniowe. Żadna z nich nie wymienia SBOM. Tabela cytuje tylko tytuły kontroli, w wersji angielskiej, i krótko mówi, czego dotyczy każda z nich.

Kontrola	Czego dotyczy	Jak SBOM lub zapis buildu służy jako dowód	Czego nie obejmuje
5.9 „Inventory of information and other associated assets”	Wiedza o tym, jakie aktywa Państwo mają i kto jest ich właścicielem	Oprogramowanie, które Państwo dostarczają i uruchamiają, jest aktywem. Lista komponentów dla każdego wydania to inwentarz tego, co jest w środku.	Sprzętu, danych, ludzi i usług
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”	Zarządzanie ryzykiem związanym z dostawcami i łańcuchem dostaw ICT	W dwóch kierunkach. Jako kupujący mogą Państwo wymagać SBOM od dostawców i je monitorować. Jako dostawca Państwa SBOM jest tym, o co prosi proces łańcucha dostaw Państwa certyfikowanego klienta. Komponenty open source są częścią łańcucha dostaw ICT, ale nie mają umowy z dostawcą, i właśnie dlatego ich inwentarz ma znaczenie.	Umów, ocen dostawców i przeglądów
8.8 „Management of technical vulnerabilities”	Pozyskiwanie informacji o podatnościach, ocena narażenia i działanie	Aktualna lista komponentów porównywana z biuletynami i oceniana ponownie, gdy pojawiają się nowe, plus zapis, które wydania zawierały podatną wersję i od kiedy	Łatania infrastruktury, skanowania hostów i samych decyzji
8.25 „Secure development life cycle”	Zasady bezpiecznego wytwarzania oprogramowania i systemów	Zapisany, powtarzalny proces wydawania: każde wydanie zbudowane w tym samym pipeline, wraz ze swoim SBOM	Większości kontroli: szkoleń, środowisk, projektowania i przeglądów
8.26 „Application security requirements”, 8.27 „Secure system architecture and engineering principles”, 8.28 „Secure coding”	Wymagania, projekt i kod	Nie bezpośrednio. Dotyczą tego, co Państwo piszą, a nie tego, co wciągają.	Niczego z tego: dowodem są tu przeglądy kodu, SAST i dokumentacja projektowa
8.29 „Security testing in development and acceptance”	Testowanie bezpieczeństwa przed wydaniem	Bramka polityki, która blokuje build po wykryciu podatności, to zapisany test z wynikiem	Funkcjonalnych testów bezpieczeństwa, testów penetracyjnych
8.30 „Outsourced development”	Kierowanie i monitorowanie zleconego wytwarzania	Zlecony kod zbudowany w Państwa pipeline otrzymuje ten sam SBOM i te same kontrole co Państwa własny	Umowy, własnych praktyk dostawcy

Proszę uczciwie traktować 8.25 do 8.30: większość tego, czego wymagają te kontrole, leży poza SBOM. Twierdzenie, że jest inaczej, to najszybszy sposób, by audytor stracił zaufanie do reszty.

Przykład: audytor pyta o 8.8

„Skąd Państwo wiedzą, że nowa podatność dotyczy produktu, który już dostarczyli?” Oto łańcuch dowodów dla jednego biuletynu i to, kto dostarcza każde ogniwo.

Krok	Dowód	Źródło
1. Zawartość wydania	SBOM wersji 4.2, zarejestrowany przez build, który ją wytworzył	Państwa narzędzia buildu
2. Dopasowanie biuletynu	Nowa CVE opublikowana dla biblioteki z tego SBOM, dopasowana po jej package URL	Państwa monitorowanie podatności
3. Okno narażenia	Każdy build, który zawierał podatną wersję, i data pierwszego z nich	Państwa historia buildów
4. Decyzja	Kto ją ocenił, kiedy i z jakim wynikiem: naprawa, ograniczenie lub brak wpływu, z uzasadnieniem	Państwa proces i jego zapisy
5. Poprawka	Wersja 4.2.1, której SBOM nie zawiera już podatnej wersji	Państwa narzędzia buildu

Narzędzia mogą dostarczyć kroki 1, 2, 3 i 5. Krok 4 to Państwa proces i to ten krok audytorzy czytają najuważniej.

SOC 2

Raport SOC 2 stwierdza, czy kontrole spełniają Trust Services Criteria AICPA (2017, z punktami uwagi zmienionymi w 2022). Kryteria opisują rezultaty. Nie wymieniają SBOM, a w dwóch z nich SBOM pomaga.

• CC7.1 wymaga, by jednostka stosowała procedury wykrywania i monitorowania w celu identyfikacji (1) zmian konfiguracji, które wprowadzają nowe podatności, oraz (2) podatności na nowo odkryte zagrożenia. Dowód: SBOM dla każdego wydania, oceniany ponownie względem nowych biuletynów, oraz zapis tego, jak obsłużono każde ustalenie.
• CC8.1 dotyczy zarządzania zmianą: jak zmiany w infrastrukturze, danych, oprogramowaniu i procedurach są autoryzowane, opracowywane lub nabywane, testowane, zatwierdzane i wdrażane. Dowód: każde wydanie zbudowane w zapisywanym pipeline, zmiana zależności widoczna między kolejnymi buildami i bramki polityki jako kontrola tego, co może zostać wydane.

Kryteria są zmieniane. W październiku 2026 AICPA opublikował projekt Trust Services Criteria 2027 do konsultacji, z ukierunkowaną restrukturyzacją kryteriów, terminem uwag do 15 stycznia 2027 i proponowanym wejściem w życie dla zleceń rozpoczynających się 31 grudnia 2027 lub później. To projekt, a numery kryteriów mogą się zmienić: przed przypisaniem dowodów do nowych numerów proszę sprawdzić tekst ostateczny.

Jeśli korzystają już Państwo z platformy SOC 2, proszę ją zachować. Pytanie brzmi, co pokazuje SBOM stojący za jej kontrolami: porównanie kontroli SBOM w SOC 2.

NIS2

Dyrektywa NIS 2 (UE) 2022/2555 ma zastosowanie do podmiotów kluczowych i ważnych w wymienionych w niej sektorach. Jeśli czytają to Państwo jako dostawca oprogramowania lub urządzeń, zwykle nie są Państwo bezpośrednio objęci. Objęty jest Państwa klient, a jego obowiązki docierają do Państwa w postaci pytań. Artykuł 21 określa środki zarządzania ryzykiem w cyberbezpieczeństwie, a trzy fragmenty generują większość tych pytań. Poniżej podajemy ich wierne omówienie, a nie cytat:

• Art. 21 ust. 2 lit. d): bezpieczeństwo łańcucha dostaw, w tym aspekty bezpieczeństwa dotyczące relacji między każdym podmiotem a jego bezpośrednimi dostawcami lub usługodawcami.
• Art. 21 ust. 2 lit. e): bezpieczeństwo w procesie nabywania, rozwoju i utrzymania sieci i systemów informatycznych, w tym obsługa i ujawnianie podatności.
• Art. 21 ust. 3: podmioty mają uwzględniać podatności właściwe dla każdego bezpośredniego dostawcy i usługodawcy oraz ogólną jakość produktów i praktyk cyberbezpieczeństwa swoich dostawców i usługodawców, w tym ich procedur bezpiecznego rozwoju. To zdanie zamienia się w kwestionariusz na Państwa biurku.

Rozporządzenie wykonawcze (UE) 2024/2690

Rozporządzenie wykonawcze Komisji (UE) 2024/2690 z 17 października 2024 określa wymogi techniczne i metodologiczne środków z art. 21 ust. 2 dla dostawców usług DNS, rejestrów nazw TLD, dostawców usług chmurowych, dostawców usług ośrodków danych, dostawców sieci dostarczania treści, dostawców usług zarządzanych, dostawców usług zarządzanych w zakresie bezpieczeństwa, internetowych platform handlowych, wyszukiwarek internetowych, platform usług sieci społecznościowych oraz dostawców usług zaufania. Nie wiąże pozostałych sektorów NIS2, ale jest najbardziej szczegółowym publicznym opisem tego, co oznacza „bezpieczeństwo łańcucha dostaw”, i inni kupujący z niego korzystają. Punkty, które docierają do dostawców, w omówieniu:

Punkt załącznika	Co mówi	O co pyta się dostawcę
5.1.2(a)	Przy wyborze dostawców uwzględnia się praktyki cyberbezpieczeństwa dostawców i usługodawców, w tym ich procedury bezpiecznego rozwoju	Jak Państwo bezpiecznie wytwarzają oprogramowanie i skąd wiedzą, co trafia do produktu?
5.1.4(e) i (f)	Umowy określają, w stosownych przypadkach, prawo do audytu lub do otrzymywania sprawozdań z audytu oraz obowiązek dostawców i usługodawców do obsługi podatności stanowiących ryzyko dla podmiotu	Czy będą Państwo obsługiwać podatności w tym, co dostarczają, i czy możemy zobaczyć dowody?
5.2	Rejestr bezpośrednich dostawców z wykazem produktów ICT, usług ICT i procesów ICT dostarczanych przez każdego z nich	Jakie produkty i wersje nam Państwo dostarczają?
6.1.2(c)	Przy nabywaniu usług ICT lub produktów ICT: informacje opisujące komponenty sprzętowe i programowe używane w usługach ICT lub produktach ICT	Jakie komponenty sprzętowe i programowe zawiera Państwa produkt? Najbliżej SBOM ze wszystkich tekstów na tej stronie, a i tak go nie wymienia.
6.10	Obsługa podatności: monitorowanie informacji o podatnościach kanałami takimi jak komunikaty CSIRT lub informacje przekazywane przez dostawców lub usługodawców (6.10.2(a)), a gdy podatność nie wymaga działań naprawczych, udokumentowanie i uzasadnienie przyczyny (6.10.3)	Jak będą nas Państwo informować o podatnościach i dlaczego ta nie stanowi problemu?

Ostatni punkt opisuje oświadczenie o braku wpływu wraz z uzasadnieniem. Właśnie to zawiera dokument VEX, choć rozporządzenie nie wskazuje formatu.

Przykład: kwestionariusz od klienta objętego NIS2

Pięć pytań, jakie klient wyprowadza z tych punktów, wraz z dowodem, który dostawca może dołączyć. Niektóre odpowiedzi pochodzą z zapisów prowadzonych przez Państwa narzędzia; inne to polityki, które Państwo piszą.

Pytanie	Dowód do dołączenia	Zapis czy polityka
„Proszę wymienić komponenty oprogramowania w wersji produktu, którą nam Państwo dostarczają.” (6.1.2(c))	SBOM tej wersji, w CycloneDX lub SPDX, z podaną kompletnością	Zapis
„Proszę opisać obsługę podatności i jej terminy.” (5.1.4(f))	Procedura obsługi podatności, z poziomami istotności i docelowymi czasami	Polityka
„Które z używanych przez nas wersji zawierały podatną bibliotekę i od kiedy?” (6.10)	Historia buildów pokazująca każdy build z tym komponentem, z datami	Zapis
„Dlaczego ta CVE nas nie dotyczy?” (6.10)	Oświadczenie o braku wpływu z uzasadnieniem, np. „podatny kod nie występuje”	Zapis, oparty na Państwa ocenie
„Jak badacze mogą zgłaszać podatności w Państwa produktach?” (5.1.2(a))	Państwa polityka skoordynowanego ujawniania podatności	Polityka

Jedno rozróżnienie warto zapamiętać: dla produktów z elementami cyfrowymi sprzedawanych w UE Cyber Resilience Act wymaga SBOM. NIS2 nie.

DORA, jeśli sprzedają Państwo podmiotom finansowym

Digital Operational Resilience Act, rozporządzenie (UE) 2022/2554, ma zastosowanie do podmiotów finansowych, a nie bezpośrednio do ich dostawców. Podmioty finansowe muszą identyfikować i dokumentować swoje aktywa ICT oraz wzajemne zależności i prowadzić ich inwentarze (art. 8 ust. 1, 4 i 6), zarządzać ryzykiem ze strony zewnętrznych dostawców usług ICT jako częścią ryzyka ICT (art. 28 ust. 1), prowadzić rejestr informacji o wszystkich umowach dotyczących usług ICT (art. 28 ust. 3) i umieszczać w tych umowach minimalne postanowienia (art. 30). DORA nie wymienia SBOM. Dostawcy oprogramowania dla banku lista komponentów dla każdego wydania pomaga klientowi spełnić art. 8.

Jedna mapa dowodów dla wszystkich ram

Wiersze to dowody; każda komórka podaje kontrolę, kryterium lub punkt, który dany dowód wspiera, albo „nie bezpośrednio”.

Dowód	ISO/IEC 27001:2022	SOC 2	NIS2 i 2024/2690	DORA
1. SBOM dla każdego wydania, z podaną kompletnością	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d); 6.1.2(c)	Art. 8 (inwentarz klienta)
2. Ciągła ponowna ocena względem nowych biuletynów	8.8	CC7.1	Art. 21(2)(e); 6.10	Nie bezpośrednio
3. Historia buildów: które wydania zawierały komponent i od kiedy	8.8	CC7.1, CC8.1	6.10	Nie bezpośrednio
4. Zapisy triażu i kierowania	8.8	CC7.1	Art. 21(2)(e); 6.10	Nie bezpośrednio
5. Oświadczenia o braku wpływu z uzasadnieniem	8.8	CC7.1	6.10	Nie bezpośrednio
6. Bramki polityki blokujące build	8.25, 8.29	CC8.1	Art. 21(2)(e)	Nie bezpośrednio
7. SBOM-y dostawców monitorowane razem z własnymi	5.19, 5.21, 5.22	CC7.1	Art. 21(2)(d), 21(3); 5.2, 6.10	Art. 28(1)
8. Polityka egress i zapisy sieciowe buildu	8.25	CC8.1	Art. 21(2)(d)	Nie bezpośrednio

Czego SBOM nie udowodni

• Państwa kontroli dostępu, reagowania na incydenty, ciągłości działania, bezpieczeństwa kadrowego, kryptografii ani bezpieczeństwa fizycznego.
• Że ktokolwiek cokolwiek naprawił. To Państwa proces i jego zapisy.
• Że Państwa własny kod jest wolny od wad. Dowodem na to są przeglądy kodu, SAST i testy.
• Co jest w plikach binarnych otrzymanych bez SBOM.
• Że mają Państwo certyfikat. SBOM nie jest certyfikatem, a certyfikat Państwa dostawcy narzędzi certyfikuje jego własny system zarządzania, nie Państwa.

Gdzie pasuje CRACI

CRACI zastępuje runnery hostowane przez GitHub i rejestruje, co pobrał każdy build, więc SBOM pochodzi z samego buildu wydania, ze stanem kompletności dla każdego zadania.

• Monitorowane SBOM-y są stale oceniane ponownie, gdy publikowane są nowe podatności (śledzenie podatności).
• Historia buildów pokazuje, które buildy zawierały podatną zależność, a więc okres narażenia, w ramach Państwa okresu przechowywania. Jeśli audyt obejmuje dłuższy okres, proszę eksportować SBOM każdego wydania i przechowywać go razem z wydaniem.
• Zespoły bezpieczeństwa przeprowadzają triaż wykrytych podatności i przekazują je zespołom odpowiedzialnym za poprawkę, a CRACI obsługuje VEX do zapisywania, których produktów podatność nie dotyczy.
• Bramki polityki mogą blokować build na podstawie ustaleń, w tym build zawierający konkretną CVE.
• Można dodawać SBOM-y stron trzecich, aby kupowane komponenty były monitorowane razem z Państwa własnymi buildami.
• SBOM-y eksportują się jako CycloneDX lub SPDX, a API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. Polityka egress rejestruje i ogranicza, z czym może się łączyć każdy build.

CRACI dostarcza dowodów dla tych kontroli. Nie zapewnia Państwu zgodności z ISO 27001 ani SOC 2, ani gotowości na NIS2, i nie jest platformą automatyzacji zgodności. Własny certyfikat CRACI to odrębny fakt: system zarządzania bezpieczeństwem informacji CRACI Corporation Oy w zakresie rozwoju i eksploatacji platformy CRACI jest certyfikowany zgodnie z ISO/IEC 27001, a certyfikat wydał Into Certification. Obejmuje sposób, w jaki CRACI prowadzi swoją usługę, a nie Państwa organizację ani produkty. Zob. bezpieczeństwo w CRACI oraz jak działa CRACI, by poznać całą platformę.

Kiedy CRACI nie jest odpowiedzią

• Państwa buildy nie działają w GitHub Actions. To obecnie jedyny system CI obsługiwany przez CRACI; inne systemy CI są w planach rozwoju.
• Potrzebują Państwo platformy automatyzacji zgodności do polityk, przeglądów dostępu i współpracy z audytorem. Proszę zachować lub kupić taką platformę; zob. porównanie kontroli SBOM w SOC 2.
• Luka w dowodach jest głównie organizacyjna: polityki, szkolenia, reagowanie na incydenty.
• Największe ryzyko ze strony dostawców to pliki binarne otrzymywane bez SBOM. Na to odpowiada analiza binarna.

Odpowiadają Państwo na prośbę jednego klienta? Zob. jak odpowiedzieć na prośbę klienta o SBOM, przewodnik dla dostawców komponentów oraz listę kontrolną, którą zastosuje Państwa klient.

SBOM jako dowód zgodności: najczęściej zadawane pytania

Czy ISO 27001 wymaga SBOM?

Nie. ISO/IEC 27001:2022 nie wymienia SBOM. Kontrole 5.9 (inwentarz), 5.21 (łańcuch dostaw ICT) i 8.8 (podatności techniczne) z załącznika A wymagają rezultatów, które SBOM wspiera, a organizacja i jej audytor decydują, jaki dowód wystarcza.

Czy SOC 2 wymaga SBOM?

Nie. Trust Services Criteria opisują rezultaty i nie wymieniają SBOM. SBOM dla każdego wydania, oceniany ponownie względem nowych biuletynów, jest dowodem dla CC7.1, a zapisywany pipeline buildów wspiera CC8.1 w zakresie zarządzania zmianą.

Czy NIS2 wymaga SBOM?

Nie. Art. 21 ust. 2 lit. d) wymaga bezpieczeństwa łańcucha dostaw, a lit. e) obsługi podatności, bez wymieniania SBOM. Rozporządzenie wykonawcze (UE) 2024/2690, obejmujące niektórych dostawców usług cyfrowych, wymaga w pkt 6.1.2(c) informacji o komponentach sprzętowych i programowych produktów ICT, nadal bez słowa SBOM.

Które kontrole z załącznika A do ISO 27001 wspiera SBOM?

Głównie 5.9 (inwentarz informacji i innych powiązanych aktywów), 5.19 do 5.22 (dostawcy i łańcuch dostaw ICT) oraz 8.8 (zarządzanie podatnościami technicznymi). Zapis buildu częściowo dotyka 8.25, 8.29 i 8.30. 8.26 do 8.28 dotyczą wymagań, projektu i kodu, poza SBOM.

O co klienci objęci NIS2 proszą swoich dostawców oprogramowania?

Zwykle o opis bezpiecznego wytwarzania, komponenty dostarczonej wersji, zobowiązanie do obsługi podatności, sposób otrzymywania informacji o podatnościach i uzasadnienia, gdy podatność nie ma zastosowania. Pytania te wynikają z art. 21 ust. 3, a w niektórych sektorach z punktów dotyczących dostawców w rozporządzeniu wykonawczym 2024/2690.

Czy SBOM jest wystarczającym dowodem dla kontroli 8.8 ISO 27001?

Nie. Pokazuje, co zawiera każde wydanie. Kontrola 8.8 wymaga też dowodów, że pozyskują Państwo informacje o podatnościach, oceniają narażenie i działają. Proszę połączyć SBOM z ciągłą ponowną oceną, zapisem dotkniętych wydań i podjętymi decyzjami.

Jaka jest różnica między zgodnością a posiadaniem dowodów?

Zgodność oznacza, że Państwa procesy spełniają wymagania ramy w ocenie audytora lub klienta. Dowód to to, co pokazuje, że te procesy działają. SBOM jest dowodem dla kilku kontroli. Nie zapewnia zgodności z żadną ramą.