Zgodność z CRA: wymagania SBOM i porównanie narzędzi

Każde porównanie pokazuje, w czym drugi produkt jest dobry, czym różni się CRACI i kiedy warto używać obu. Wszystkie kategorie: wszystkie porównania.

Czego CRA wymaga od SBOM

Cyber Resilience Act, rozporządzenie (UE) 2024/2847, umieszcza SBOM wśród wymagań dotyczących obsługi podatności. Wymaga mniej, niż wielu osobom się wydaje: czytelnego maszynowo zapisu co najmniej zależności najwyższego poziomu, przechowywanego w dokumentacji technicznej i okazywanego organowi na żądanie. Oto co mówi rozporządzenie, pytanie po pytaniu.

Wymagania CRA dotyczące SBOM w rozporządzeniu (UE) 2024/2847
Funkcja	Co mówi CRA	Gdzie
Czy SBOM jest obowiązkowy?	Tak. Producenci muszą zidentyfikować i udokumentować komponenty swoich produktów, w tym przez sporządzenie zestawienia komponentów oprogramowania	Załącznik I, część II pkt 1
Czym jest SBOM?	Formalnym zapisem szczegółów i relacji w łańcuchu dostaw komponentów zawartych w elementach oprogramowania produktu z elementami cyfrowymi	Art. 3 pkt 39
Jaki format?	CRA wymaga „powszechnie stosowanego formatu czytelnego maszynowo”. Komisja może określić format i elementy w aktach wykonawczych	Załącznik I, część II pkt 1; art. 13 ust. 24
Jak głęboko?	„Co najmniej zależności najwyższego poziomu produktów”	Załącznik I, część II pkt 1
Gdzie się znajduje?	W dokumentacji technicznej, jako część informacji o obsłudze podatności	Załącznik VII pkt 2 lit. b
Czy musi być publiczny?	Nie. Producenci nie powinni być zobowiązani do upubliczniania SBOM. Jeśli udostępniają go Państwo użytkownikom, informacje dla użytkownika wskazują, gdzie go znaleźć	Motyw 77; załącznik II pkt 9
Kto może go zażądać?	Organ nadzoru rynku, na uzasadniony wniosek, w celu sprawdzenia zgodności. Organy mogą też żądać SBOM-ów na potrzeby oceny zależności w skali całej UE	Załącznik VII pkt 8; art. 13 ust. 25
Jak długo go przechowywać?	Dokumentację techniczną przechowuje się przez co najmniej 10 lat od wprowadzenia produktu do obrotu lub przez okres wsparcia, w zależności od tego, który z nich jest dłuższy	Art. 13 ust. 13

Rozporządzenie stosuje się w całości od 11 grudnia 2027, a jego obowiązki raportowania obowiązują od 11 września 2026. Pozostałą część rozporządzenia opisuje strona czego wymaga CRA.

Ponad minimum: BSI TR-03183-2

Dopóki Komisja nie określi formatu w akcie wykonawczym, najbardziej szczegółowe publiczne wytyczne pochodzą z niemieckiego Federalnego Urzędu ds. Bezpieczeństwa Informacji (BSI). Jego wytyczna techniczna TR-03183-2, wersja 2.1.0 z sierpnia 2025, jest wytyczną, a nie częścią rozporządzenia, ale pokazuje, dokąd zmierzają oczekiwania:

Format: JSON lub XML, zgodny z CycloneDX 1.6 lub nowszym albo SPDX 3.0.1 lub nowszym.
Głębokość: rekurencyjne rozwiązywanie zależności dla każdego komponentu w zakresie dostawy, aż do pierwszego komponentu poza nim włącznie.
Źródło prawdy: SBOM musi zawierać „te same informacje, które są dostępne podczas procesu buildu”, lub informacje równoważne, jeśli procesu buildu nie ma.

Wytyczna wymienia też rodzaje SBOM. Build SBOM „powstaje jako część procesu buildu”. Analysed SBOM „powstaje po procesie buildu przez analizę artefaktów, takich jak pliki wykonywalne, pakiety, kontenery i obrazy maszyn wirtualnych”. To rozróżnienie jest główną różnicą między narzędziami na tej stronie.

Zależności najwyższego poziomu czy przechodnie

Zależności najwyższego poziomu to minimum, a nie cel. Podatność w pakiecie przechodnim nadal znajduje się w Państwa produkcie, a CRA wymaga od producentów eliminowania i usuwania podatności w dostarczanych komponentach. SBOM, który kończy się na pierwszym poziomie, pozostawia te pakiety poza Państwa obsługą podatności. Praktyczne pytanie nie brzmi, czy rejestrować zależności przechodnie, lecz jak mieć pewność, że zapis odpowiada temu, co dostarczono. Jak je wymienić i naprawić podatne, opisuje strona zależności przechodnie.

Build SBOM czy analysed SBOM

Większość narzędzi SBOM generuje analysed SBOM po buildzie lub zarządza SBOM-ami tworzonymi przez inne narzędzia. CRACI rejestruje build SBOM podczas działania buildu. Porównanie generatorów i menedżerów SBOM znajdą Państwo na stronach zarządzanie SBOM oraz porównanie narzędzi SBOM. Narzędzia zbudowane wokół CRA opisuje strona porównanie narzędzi do zgodności z CRA.

Miejsce CRACI

CRACI rejestruje SBOM podczas działania Państwa buildu GitHub Actions. Proxy rozpoznające pakiety na runnerze rejestruje każdy pakiet pobrany przez zadanie, łącznie z pakietami przywróconymi z cache CI, więc SBOM opisuje build, który wytworzył artefakt, a nie skan uruchomiony gdzieś obok. SBOM każdego zadania ma stan kompletności, a eksporty w CycloneDX i SPDX obejmują zależności przechodnie i deklarowaną licencję każdego komponentu.

Po wydaniu CRACI nadal ponownie ocenia monitorowane SBOM-y w miarę pojawiania się nowych podatności i składa zgłoszenia CRA (wczesne ostrzeżenie, zgłoszenie i raport końcowy) w Państwa imieniu. API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI przechowuje dane buildów domyślnie przez 180 dni, z niestandardowym okresem przechowywania w planie Enterprise, więc należy eksportować to, co powinno znaleźć się w Państwa 10-letniej dokumentacji technicznej. CRACI automatyzuje znaczną część widoczności łańcucha dostaw i dowodów potrzebnych w Państwa procesie CRA; ocena zgodności i dokumentacja techniczna pozostają po stronie producenta. Każde wymaganie CRA w formie planu krok po kroku opisuje przewodnik po CRA. Więcej o generowaniu SBOM w czasie buildu. Można też umówić demo, aby zobaczyć SBOM zarejestrowany z jednego z Państwa buildów.

CRACI w porównaniu z każdym narzędziem

Obok siebie

Kilka narzędzi na jednej stronie, gdy wybierają Państwo kategorię, a nie jeden produkt.

Porównanie: Narzędzia do zgodności z CRA Narzędzia, które pomagają producentom spełnić wymagania Cyber Resilience Act.

SBOM w CRA: odpowiedzi na pytania

Czy CRA wymaga zależności przechodnich w SBOM?

Rozporządzenie wyznacza minimum: „co najmniej zależności najwyższego poziomu produktów” (załącznik I, część II pkt 1). Zależności przechodnie nie są wymienione, ale podatny pakiet przechodni nadal znajduje się w Państwa produkcie, a CRA wymaga obsługi podatności w dostarczanych komponentach. Niemiecka wytyczna BSI TR-03183-2 idzie dalej i wymaga rekurencyjnego rozwiązywania zależności.

Czy SBOM wymagany przez CRA musi być publiczny?

Nie. Motyw 77 stanowi, że producenci nie powinni być zobowiązani do upubliczniania SBOM. Należy on do dokumentacji technicznej, a organ nadzoru rynku może go zażądać na uzasadniony wniosek. Jeśli zdecydują się Państwo udostępnić go użytkownikom, informacje dołączone do produktu muszą wskazywać, gdzie go znaleźć (załącznik II pkt 9).

Czy SBOM na potrzeby CRA powinien być w CycloneDX czy SPDX?

CRA wymaga „powszechnie stosowanego formatu czytelnego maszynowo”, nie wskazując żadnego; Komisja może określić format w akcie wykonawczym (art. 13 ust. 24). CycloneDX i SPDX to dwa powszechne wybory. BSI TR-03183-2 v2.1.0 akceptuje CycloneDX 1.6 lub nowszy oraz SPDX 3.0.1 lub nowszy, w JSON lub XML.

Jak długo trzeba przechowywać SBOM?

SBOM jest częścią dokumentacji technicznej, którą producenci przechowują do dyspozycji organów nadzoru rynku przez co najmniej 10 lat od wprowadzenia produktu do obrotu lub przez okres wsparcia, jeśli jest dłuższy (art. 13 ust. 13).

Od kiedy obowiązują wymagania CRA dotyczące SBOM?

Obowiązki raportowania wynikające z CRA obowiązują od 11 września 2026, a rozporządzenie stosuje się w całości, łącznie z wymogiem SBOM z załącznika I, od 11 grudnia 2027.

Zgodność z CRA: wymagania SBOM i narzędzia