Pełne egzekwowanie CRA rozpoczyna się 11 grudnia 2027 r. Od tej daty każdy produkt z elementami cyfrowymi wprowadzany do obrotu na rynku UE musi posiadać oznakowanie CE, a oznakowanie CE wymaga zgodnego z przepisami SBOM. Kluczowym przepisem jest Załącznik I, Część II, pkt 1: producenci mają obowiązek „identyfikowania i dokumentowania podatności i komponentów zawartych w produkcie z elementami cyfrowymi, w tym przez sporządzenie zestawienia podstawowych materiałów do produkcji oprogramowania w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu produktów". To sformułowanie przesądza o formacie, zakresie i miejscu, jakie SBOM zajmuje w dokumentacji technicznej. Niniejsza strona omawia dokładnie to, czego prawo wymaga, i to, czego nie wymaga.
Najważniejsze informacje
- SBOM jest obowiązkowy na podstawie Załącznika I, Część II, pkt 1 dla każdego produktu z elementami cyfrowymi
- Format musi być nadający się do odczytu maszynowego (CycloneDX lub SPDX; pliki PDF i arkusze kalkulacyjne nie spełniają tego wymogu)
- Minimalne pokrycie: zależności najwyższego poziomu produktów; pokrycie zależności przechodnich jest najlepszą praktyką, lecz wykracza poza ustawowe minimum
- SBOM wchodzi w skład dokumentacji technicznej zgodnie z Załącznikiem VII (pkt 2(b), przy czym pkt 8 reguluje udostępnianie kopii organom nadzoru rynku na wniosek)
- Obowiązek ma charakter ciągły: przesłanki aktualizacji obejmują każde wydanie oprogramowania układowego, zmianę komponentu i wykrycie podatności
- Pełne egzekwowanie: 11 grudnia 2027 r.; zegar zgłaszania podatności startuje 11 września 2026 r.
Obowiązki CRA dotyczące SBOM
CRA przywołuje SBOM w dwóch kluczowych miejscach.
Załącznik I: Zasadnicze wymagania
Oficjalny tekst Załącznika I, Część II, pkt 1 stanowi:
„identyfikowania i dokumentowania podatności i komponentów zawartych w produkcie z elementami cyfrowymi, w tym przez sporządzenie zestawienia podstawowych materiałów do produkcji oprogramowania w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu produktów"
Oznacza to:
- SBOM jest obowiązkowy, nie opcjonalny
- Musi być w formacie nadającym się do odczytu maszynowego (nie PDF ani arkusz kalkulacyjny)
- Musi obejmować co najmniej zależności najwyższego poziomu produktów; pokrycie zależności przechodnich jest najlepszą praktyką, lecz wykracza poza ustawowe minimum
Każdy produkt z elementami cyfrowymi wprowadzany do obrotu na rynku UE musi posiadać SBOM nadający się do odczytu maszynowego. Nie istnieje możliwość rezygnacji ani próg wielkości przedsiębiorstwa, poniżej którego obowiązek przestaje obowiązywać.
Załącznik VII: Dokumentacja techniczna
Dokumentacja techniczna zgodnie z Załącznikiem VII wymienia SBOM w dwóch miejscach:
- Pkt 2(b): opis procedur postępowania w przypadku wykrycia podatności, „w tym zestawienie podstawowych materiałów do produkcji oprogramowania", musi stanowić część dokumentacji technicznej prowadzonej przez producenta. Pełna treść Załącznika VII, pkt 2(b):
„niezbędne informacje i specyfikacje wprowadzonych przez producenta procedur postępowania w przypadku wykrycia podatności, w tym zestawienie podstawowych materiałów do produkcji oprogramowania, politykę skoordynowanego ujawniania podatności, dowód, że podano adres do kontaktu do celów zgłaszania podatności, oraz opis rozwiązań technicznych wybranych na potrzeby bezpiecznej dystrybucji aktualizacji"
- Pkt 8: „w stosownych przypadkach zestawienie podstawowych materiałów do produkcji oprogramowania" musi zostać dostarczone „na uzasadniony wniosek organu nadzoru rynku". Pełna treść Załącznika VII, pkt 8:
„w stosownych przypadkach zestawienie podstawowych materiałów do produkcji oprogramowania, na uzasadniony wniosek organu nadzoru rynku, pod warunkiem że jest to niezbędne, aby organ ten mógł sprawdzić zgodność z zasadniczymi wymaganiami w zakresie cyberbezpieczeństwa określonymi w załączniku I"
SBOM nie jest przedkładany proaktywnie. Musi istnieć w chwili wprowadzenia produktu do obrotu na rynku UE i być gotowy do udostępnienia organom na wniosek.
SBOM w Załączniku VII musi umożliwiać:
- śledzenie podatności na poziomie komponentu,
- identyfikację dostawcy,
- weryfikację zgodności z licencjami,
- planowanie okresu zakończenia wsparcia.
Co musi zawierać SBOM zgodny z Załącznikiem VII
Dokumentacja techniczna obejmuje trzy wymagane wymiary SBOM: format, zawartość i zakres. Poniższa tabela odzwierciedla to, co organy nadzoru rynku będą weryfikować.
| Kategoria | Wymaganie | Źródło |
|---|---|---|
| Format | Nadający się do odczytu maszynowego (CycloneDX lub SPDX) | Załącznik I, Część II, pkt 1 |
| Format | Skrócone zestawienie czytelne dla człowieka | Najlepsza praktyka |
| Zawartość | Wszystkie komponenty oprogramowania wymienione | Załącznik I |
| Zawartość | Wersje komponentów podane | Załącznik I |
| Zawartość | Informacje o dostawcy | Załącznik I; TR-03183 |
| Zawartość | Informacje o licencji | TR-03183 |
| Zawartość | Znane podatności w chwili oceny | Załącznik VII, pkt 2(b) |
| Zakres | Zależności bezpośrednie (najwyższego poziomu) | Załącznik I (ustawowe minimum) |
| Zakres | Zależności przechodnie | TR-03183 (najlepsza praktyka) |
| Zakres | Komponenty systemu operacyjnego, jeśli dotyczy | TR-03183 |
| Zakres | Biblioteki zewnętrzne | Załącznik I |
Szczegółowe wymagania dotyczące pól wykraczające poza powyższą listę kontrolną (identyfikatory PURL, wartości skrótów, metadane dokumentu): jak BSI TR-03183 rozszerza wymagania CRA. Porównanie narzędzi dla CycloneDX i SPDX: CycloneDX vs SPDX.
Jak wygląda prawidłowy wpis SBOM
Poprawnie skonstruowany wpis w dokumentacji technicznej Załącznika VII przywołuje plik nadający się do odczytu maszynowego i odnotowuje status podatności w chwili oceny:
ZESTAWIENIE PODSTAWOWYCH MATERIAŁÓW DO PRODUKCJI OPROGRAMOWANIA
Produkt: SmartSense Pro (SSP-3000)
Wersja oprogramowania układowego: 2.4.1
Format SBOM: CycloneDX 1.5
Wygenerowano: 2027-01-15
Narzędzie: Trivy + syft
PLIK SBOM:
sbom-ssp3000-v2.4.1.json (załączony)
PODSUMOWANIE KOMPONENTÓW:
-------------------------------------------------------------
Łączna liczba komponentów: 127
Zależności bezpośrednie: 23
Zależności przechodnie: 104
Według typu:
Biblioteki: 98
Frameworki: 12
System operacyjny: 1 (FreeRTOS)
Moduły oprogramowania układowego: 16
STATUS PODATNOŚCI W CHWILI OCENY:
-------------------------------------------------------------
Data skanu: 2027-01-15
Skaner: Trivy v0.48.0
Krytyczne: 0
Wysokie: 0
Średnie: 2 (zaakceptowane, patrz poniżej)
ZAAKCEPTOWANE PODATNOŚCI:
CVE-2026-XXXXX (Średnia): Komponent xyz v1.2.3
Status: Nie jest możliwa do wykorzystania w naszej konfiguracji
Uzasadnienie: Funkcja nieaktywna, ścieżka kodu nieosiągalna
Data przeglądu: 2027-04-15
-------------------------------------------------------------
ZOBOWIĄZANIE DO AKTUALIZACJI SBOM:
SBOM będzie aktualizowany przy każdym wydaniu oprogramowania układowego
i udostępniany klientom na żądanie.
Kiedy aktualizować SBOM
SBOM nie jest dokumentem jednorazowym. Dokumentacja techniczna musi być aktualna przez cały cykl życia produktu.
Obowiązkowe przesłanki aktualizacji:
| Przesłanka | Co się zmienia | Wymagana aktualizacja SBOM? |
|---|---|---|
| Nowa wersja oprogramowania układowego lub oprogramowania | Nowy artefakt kompilacji | Tak, pełna regeneracja |
| Wydanie poprawki bezpieczeństwa | Wersja komponentu zmieniona | Tak, zmienione komponenty |
| Podatność wykryta i usunięta | VEX lub status możliwości wykorzystania | Tak, pola VEX |
| Komponent dodany, usunięty lub zastąpiony | Graf zależności | Tak, pełna regeneracja |
| Zmiana projektu wpływająca na bezpieczeństwo | Komponenty i architektura | Tak, pełna regeneracja |
| Zmiana stosowanej normy zharmonizowanej | Odniesienie do normy | Tak, metadane |
Przeglądy okresowe:
| Częstotliwość | Zakres |
|---|---|
| Kwartalnie | SBOM i status podatności |
| Rocznie | Pełny przegląd dokumentacji technicznej |
| Przed końcem okresu wsparcia | Ostateczne zamrożenie dokumentacji |
Ręczne tworzenie SBOM jest podatne na błędy i nie skaluje się w przypadku wielu wersji produktu. Każda kompilacja powinna generować aktualny artefakt SBOM. Informacje o tym, co się psuje, gdy zespoły pomijają automatyzację: typowe błędy w SBOM.
Wymogi dotyczące przechowywania dokumentacji
Artykuł 13 ust. 13 nakłada na producentów obowiązek przechowywania dokumentacji technicznej i deklaracji zgodności UE do dyspozycji organów nadzoru rynku przez odpowiedni okres. Treść przepisu:
„Producenci przechowują dokumentację techniczną i deklarację zgodności UE do dyspozycji organów nadzoru rynku przez okres co najmniej 10 lat po wprowadzeniu produktu z elementami cyfrowymi do obrotu lub przez okres wsparcia, w zależności od tego, który z tych okresów jest dłuższy."
Zegar startuje od ostatniej jednostki wprowadzonej do obrotu, nie od pierwszej.
| Zdarzenie | Przykładowa data |
|---|---|
| Pierwsze wprowadzenie produktu do obrotu | Marzec 2027 r. |
| Ostatnia jednostka wprowadzona do obrotu | Grudzień 2030 r. |
| Dokumentacja przechowywana do (minimum 10 lat) | Grudzień 2040 r. |
SBOM należy przechowywać w bezpiecznym, dostępnym miejscu z procedurami tworzenia kopii zapasowych, ochroną integralności oraz możliwością pobrania i udostępnienia na uzasadniony wniosek organu nadzoru rynku. Załącznik VII, pkt 8 precyzuje, że SBOM jest dostarczany „na uzasadniony wniosek", a nie proaktywnie.
Egzekwowanie i sankcje
Pełne egzekwowanie CRA rozpoczyna się 11 grudnia 2027 r. Obowiązek zgłaszania podatności wynikający z Artykułu 14 zaczyna obowiązywać wcześniej, 11 września 2026 r. Produkty wprowadzane do obrotu na rynku UE po grudniu 2027 r. bez zgodnego z przepisami SBOM nie mogą nosić oznakowania CE i nie mogą być legalnie sprzedawane w UE. Pełny harmonogram i zestawienie sankcji: terminy i sankcje dotyczące SBOM zgodnie z CRA.
Najczęściej zadawane pytania
Czy CRA wymaga SBOM nadającego się do odczytu maszynowego, czy wystarczy plik PDF?
Załącznik I wprost wymaga formatu nadającego się do odczytu maszynowego. Plik PDF nie spełnia tego wymogu. CycloneDX lub SPDX serializowane jako JSON lub XML spełniają wymaganie. Arkusz kalkulacyjny ani dokument czytelny wyłącznie dla człowieka nie spełniają go.
Czy CRA wymaga SBOM dla komponentów open source?
Tak. Załącznik I stanowi, że producenci mają obowiązek dokumentowania komponentów w SBOM nadającym się do odczytu maszynowego, bez wyjątku dla oprogramowania open source. Jeśli biblioteka open source jest zawarta w produkcie, musi figurować w SBOM z informacją o wersji i identyfikatorem.
Kiedy SBOM musi zostać przedłożony: przy wprowadzeniu do obrotu czy na wniosek?
SBOM nie musi być przedkładany proaktywnie. Musi stanowić część dokumentacji technicznej (Załącznik VII), być gotowy i dostępny do udostępnienia organom nadzoru rynku na wniosek. Musi istnieć w chwili wprowadzenia produktu do obrotu na rynku UE.
Czym są minimalne elementy NTIA i czy spełniają wymagania CRA?
Minimalne elementy NTIA (nazwa dostawcy, nazwa komponentu, wersja, unikalne identyfikatory, relacje zależności, autor SBOM i znacznik czasu) są w dużej mierze zbieżne z tym, czego na poziomie podstawowym wymagają CRA i BSI TR-03183. Stanowią rozsądne minimum wyjściowe, jednak wymagane pola TR-03183 idą dalej: dla zgodności z CRA oczekiwane są wartości skrótów i identyfikatory PURL.
Czy SBOM od dostawców mogą posłużyć do spełnienia wymagań CRA?
Częściowo. SBOM od dostawców stanowią wartościowe dane wejściowe dla dostarczanych przez nich komponentów, a CRA oczekuje, że producenci będą korzystać z dokumentacji upstream. Obowiązek wynikający z Załącznika I spoczywa jednak na producencie zintegrowanego produktu: producent musi sporządzić i utrzymywać SBOM dla produktu w postaci dostarczanej do klienta, co oznacza konsolidację SBOM od dostawców z własnymi komponentami pierwszej strony i zależnościami kompilacji. Jeśli SBOM dostawcy nie zawiera pól wymaganych przez BSI TR-03183 (PURL, skrót, licencja), producent jest odpowiedzialny za uzupełnienie tych braków. SBOM od dostawców należy traktować jako surowiec, nie jako gotowy artefakt zgodności.