Wymogi CRA dla SBOM: format, zakres, aktualizacje i przechowywanie
CRA wymaga, aby każdy produkt z elementami cyfrowymi był dostarczany z Software Bill of Materials (SBOM) w formacie nadającym się do odczytu maszynowego, który wymienia komponenty oprogramowania i obejmuje co najmniej ich zależności najwyższego poziomu. SBOM należy do dokumentacji technicznej i musi być gotowy dla organu nadzoru rynku na żądanie, a nie składany z wyprzedzeniem.
Najważniejsze informacje
- Każdy produkt z elementami cyfrowymi potrzebuje SBOM w formacie maszynowym jako części dowodów dotyczących obsługi podatności. Jest obowiązkowy, bez wyjątku zależnego od wielkości.
- Minimalny poziom prawny to zależności najwyższego poziomu. Pokrycie zależności przechodnich to mocniejsza praktyka i jest oczekiwane przez większość ram jakości SBOM.
- Jeden produkt oznacza jeden zbiór dowodów SBOM, nawet gdy produkt jest zbudowany z wielu repozytoriów lub komponentów.
- Utrzymuj SBOM aktualny w okresie wsparcia, zwłaszcza po wydaniach, zmianach komponentów i decyzjach dotyczących podatności.
- Przechowuj SBOM z dokumentacją techniczną przez co najmniej 10 lat lub przez okres wsparcia, jeśli jest dłuższy.
- Obowiązek zgłaszania podatności zaczyna obowiązywać 11 września 2026 r.; pełne stosowanie CRA przypada na 11 grudnia 2027 r.
Czym jest SBOM?
Software Bill of Materials (SBOM) to ustrukturyzowany spis oprogramowania zawartego w produkcie: bibliotek, frameworków, pakietów systemu operacyjnego i zależności między nimi. Dla CRA to zapis, którego organ nadzoru rynku użyłby, aby sprawdzić, które komponenty są dotknięte zgłoszoną podatnością, więc musi nadawać się do odczytu maszynowego, a nie być dokumentem opisowym.
Czego CRA wymaga w SBOM
Obowiązek SBOM ma dwie praktyczne warstwy: co musi obejmować inwentarz oraz gdzie dowód musi znajdować się w dokumentacji technicznej.
Jakie komponenty musi obejmować SBOM?
Producenci muszą identyfikować i dokumentować komponenty oraz podatności w swoich produktach z elementami cyfrowymi, a także sporządzić SBOM w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmujący co najmniej zależności najwyższego poziomu produktu.
Oznacza to:
- SBOM musi nadawać się do odczytu maszynowego i być w powszechnie używanym formacie. PDF lub arkusz kalkulacyjny może pomóc w przeglądzie inwentarza przez człowieka, ale nie zastępuje pliku SBOM.
- Musi obejmować co najmniej zależności najwyższego poziomu. Pokrycie zależności przechodnich wykracza poza minimum i jest lepszą podstawą do monitorowania podatności.
Każdy produkt z elementami cyfrowymi wprowadzany do obrotu na rynku UE musi mieć SBOM nadający się do odczytu maszynowego. Nie ma możliwości rezygnacji ani progu wielkości, poniżej którego obowiązek znika. Poziom szczegółowości dokumentacji skaluje się z ryzykiem produktu, ale sam obowiązek sporządzenia SBOM nie.
Obecnie przepisy wymagają jedynie powszechnie używanego formatu nadającego się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu. Nie wskazują konkretnego formatu ani stałej listy pól. Ten minimalny poziom może zostać podniesiony: CRA pozostawia Komisji możliwość określenia dokładnego formatu i zestawu pól SBOM w przyszłości. Wybór dziś dobrze wspieranego formatu, CycloneDX lub SPDX, oraz uchwycenie więcej niż samego minimum to najbezpieczniejsze zabezpieczenie na wypadek przyszłego narzuconego formatu.
Gdzie SBOM mieści się w dokumentacji technicznej
SBOM jest częścią dokumentacji technicznej, gromadzonej obok pozostałych dowodów obsługi podatności: polityki skoordynowanego ujawniania podatności, adresu kontaktowego do zgłoszeń oraz opisu bezpiecznej dystrybucji aktualizacji. Nie składa się go z wyprzedzeniem. Musi istnieć, gdy produkt jest wprowadzany do obrotu na rynku UE, i być gotowy dla organu nadzoru rynku, jeśli ten skieruje uzasadniony wniosek.
W praktyce SBOM powinien umożliwiać śledzenie podatności na poziomie komponentu, kontrole dostawcy i pochodzenia, przegląd licencji oraz planowanie końca życia produktu.
Ile SBOM potrzebuje jeden produkt?
Produkt często jest budowany z wielu repozytoriów i komponentów, a każde z nich może wygenerować własny SBOM. CRA ustala jednostkę dowodu na poziomie produktu, nie repozytorium ani kompilacji.
CRA definiuje SBOM jako zapis komponentów oprogramowania produktu i relacji między nimi, i oczekuje, że ten zapis obejmie co najmniej zależności najwyższego poziomu produktu. Obiektem dowodowym jest produkt wprowadzany do obrotu na rynku UE, identyfikowany przez produkt i wersję. Produktu złożonego z dziesięciu repozytoriów nie pokrywa dziesięć luźnych SBOM komponentów, których nic nie spaja. Należny jest dowód SBOM reprezentujący produkt w postaci dostarczonej.
CRA nie nakazuje jednego pliku fizycznego i nie zabrania utrzymywania SBOM komponentów. Sprawdzają się obie drogi, o ile wynik nadaje się do odczytu maszynowego, znajduje się na poziomie produktu i obejmuje co najmniej zależności najwyższego poziomu:
- Komponowanie. Zachowaj SBOM komponentów jako odrębne dokumenty i powiąż je w SBOM produktu, używając komponentów typu assembly w CycloneDX z referencjami BOM-Link albo relacji SPDX z referencjami do dokumentów zewnętrznych.
- Scalanie. Spłaszcz każdy komponent do jednego dokumentu CycloneDX lub SPDX dla danej wersji produktu.
Ponieważ SBOM ma uchwycić relacje między komponentami, sama płaska lista nazw pakietów nie wystarczy. Niezależnie od wybranej drogi SBOM powinien pokazywać, jak komponenty od siebie zależą i jak się zawierają, co zapewniają zarówno grafy zależności CycloneDX, jak i relacje SPDX. Mechanikę formatów opisuje CycloneDX vs SPDX.
Kto musi otrzymać SBOM?
SBOM to materiał dokumentacji technicznej, a nie dokument publiczny. CRA nie wymaga jego publikowania, a jedyną stroną, która może go wyegzekwować, jest organ nadzoru rynku, który może o niego poprosić w uzasadnionym wniosku, gdy musi sprawdzić zgodność. Udostępnianie SBOM użytkownikom jest opcjonalne. Jeśli zdecydujesz się udostępnić go użytkownikom, trzeba wtedy poinformować ich, gdzie mogą go znaleźć.
| Kto | Czego oczekuje CRA |
|---|---|
| Organ nadzoru rynku | Może zażądać SBOM w uzasadnionym wniosku, gdy jest to potrzebne do sprawdzenia zgodności |
| Użytkownicy i opinia publiczna | Brak obowiązku publikowania lub przekazywania; udostępnianie to twój wybór |
| Importerzy i dystrybutorzy | Brak prawa do samego SBOM; muszą móc przekazać twoją dokumentację techniczną organom na żądanie |
| Integratorzy budujący na twoim produkcie | Gdy twój produkt ma być zintegrowany z ich produktem, przekazujesz im informacje potrzebne do spełnienia ich własnych obowiązków, czym nie jest automatycznie pełny SBOM |
Naszym zdaniem nie należy domyślnie publikować SBOM ani wysyłać go użytkownikom. SBOM to dokładna mapa twoich komponentów i wersji, czyli dokładnie to, czego chce atakujący, a CRA nie nakłada obowiązku jego szerokiego udostępniania. Przekazuj go organowi nadzoru rynku, gdy skieruje uzasadniony wniosek, oraz klientom biznesowym, którzy budują na twoim produkcie, na podstawie NDA lub umowy, ponieważ potrzebują go do złożenia własnego SBOM na poziomie produktu i spełnienia własnych obowiązków. Prowadź rejestr, kto otrzymał którą wersję.
Co musi zawierać SBOM
Oddziel minimum prawne CRA od pól, które sprawiają, że SBOM jest użyteczny w realnych procesach obsługi podatności. Rozporządzenie ustala minimum. TR-03183, narzędzia CycloneDX/SPDX i oczekiwania klientów zwykle podnoszą próg operacyjny.
| Obszar | Minimum CRA | Silna implementacja |
|---|---|---|
| Format | Powszechnie używany i maszynowo czytelny | CycloneDX JSON/XML lub SPDX JSON/tag-value, generowany przez narzędzia build |
| Zakres | Co najmniej zależności najwyższego poziomu | Zależności bezpośrednie i przechodnie, biblioteki wewnętrzne, firmware i pakiety OS, jeśli dotyczy |
| Komponenty | Komponenty zawarte w produkcie | Nazwa, wersja, dostawca, PURL lub CPE, hash i dane relacji |
| Podatności | Zidentyfikowane i udokumentowane komponenty oraz podatności | Aktualny status podatności, decyzja VEX lub o możliwości wykorzystania, odniesienie do naprawy i data przeglądu |
| Dowód techniczny | SBOM zawarty w dowodach procesu obsługi podatności | Stała referencja pliku dla wersji produktu, narzędzie, data wygenerowania i wynik walidacji |
| Dostęp organów | Dostępny, gdy jest potrzebny na uzasadniony wniosek nadzoru rynku | Bezpieczne archiwum z właścicielem odzyskiwania, kontrolą integralności i pokryciem okresu wsparcia |
CRA wymaga identyfikacji i dokumentowania podatności, ale nie oznacza to, że dane o podatnościach lub VEX muszą znajdować się wewnątrz samego pliku SBOM. Umieszczanie ich tam to dobra praktyka, nie minimum. Wymagania dotyczące pól wykraczające poza tę listę (identyfikatory PURL, wartości skrótów, metadane dokumentu) opisuje jak BSI TR-03183 rozszerza CRA. Porównanie narzędzi CycloneDX i SPDX znajdziesz w CycloneDX vs SPDX.
Jak wygląda podsumowanie SBOM w dokumentacji technicznej
Silna dokumentacja techniczna łączy SBOM nadający się do odczytu maszynowego z krótkim zapisem podsumowującym. Podsumowanie to strona tytułowa dla przeglądu przez człowieka. Właściwym SBOM jest dołączony plik CycloneDX lub SPDX, na który podsumowanie wskazuje.
PODSUMOWANIE SBOM W DOKUMENTACJI TECHNICZNEJ
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.6
Generated: 2027-01-15
Tools: Syft (generowanie), Trivy (skanowanie)
PLIK SBOM:
sbom-ssp3000-v2.4.1.json (dołączony, maszynowo czytelny)
PODSUMOWANIE KOMPONENTÓW:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
By Type:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
STATUS PODATNOŚCI W CHWILI OCENY:
-------------------------------------------------------------
Scan Date: 2027-01-17
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (zaakceptowane - zob. poniżej)
ZAAKCEPTOWANE PODATNOŚCI:
CVE-2026-15432 (Medium): libexpat 2.5.0
Status: Niewykorzystywalna w naszej konfiguracji
Justification: Funkcja niewłączona, ścieżka kodu nieosiągalna
Review Date: 2027-04-15
-------------------------------------------------------------
Kiedy aktualizować SBOM
SBOM nie jest dokumentem jednorazowym. Dokumentacja techniczna musi być sporządzona przed wprowadzeniem produktu do obrotu i aktualizowana, gdy jest to właściwe, co najmniej przez okres wsparcia. Okres wsparcia odzwierciedla, jak długo produkt ma być w użyciu, i wynosi co najmniej pięć lat, chyba że produkt rzeczywiście ma być w użyciu krócej.
Przejrzyj lub wygeneruj ponownie SBOM, gdy:
| Przesłanka | Co się zmienia | Działanie praktyczne |
|---|---|---|
| Nowa wersja firmware lub oprogramowania | Nowy artefakt kompilacji | Wygeneruj SBOM dla tej wersji produktu |
| Poprawka bezpieczeństwa | Zmienia się wersja komponentu | Zaktualizuj komponenty i zarchiwizuj nowy SBOM |
| Podatność wykryta i oceniona | Zmienia się status VEX lub możliwość wykorzystania | Zaktualizuj status podatności i dowód decyzji |
| Komponent dodany, usunięty lub zastąpiony | Zmienia się graf zależności | Wygeneruj i zwaliduj SBOM |
| Zmiana projektu istotna dla bezpieczeństwa | Zmieniają się komponenty lub architektura | Wygeneruj SBOM i zaktualizuj referencje dokumentacji technicznej |
| Zmiana stosowanych norm lub specyfikacji | Zmieniają się metadane zgodności | Przejrzyj metadane i powiązane dowody |
Przeglądy okresowe. CRA nie ustala stałego interwału przeglądów. Poniższe częstotliwości to praktyczna podstawa:
| 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 |
Każda kompilacja powinna generować aktualny artefakt SBOM, aby dowód nadążał za tym, co dostarczasz. Zobacz typowe błędy w SBOM, aby sprawdzić, co psuje się, gdy zespoły pomijają automatyzację.
Jak długo przechowywać dowody SBOM
Przechowuj SBOM z dokumentacją techniczną przez co najmniej 10 lat po wprowadzeniu produktu z elementami cyfrowymi do obrotu lub przez okres wsparcia, jeśli jest dłuższy. Ta sama reguła przechowywania dotyczy dokumentacji technicznej i deklaracji zgodności UE. Chodzi o przechowywanie dokumentacji. To odrębna kwestia od obowiązku utrzymywania dostępności samych aktualizacji zabezpieczeń, który biegnie własnym torem przez dziesięć lat od momentu wydania każdej aktualizacji.
Dla linii produktów sprzedawanej przez dłuższy czas przechowuj dowody dotyczące wersji i jednostek wprowadzonych do obrotu. Nie traktuj daty pierwszego uruchomienia sprzedaży jako praktycznego końca obowiązku dowodowego, dopóki późniejsze jednostki lub wersje są nadal dostarczane.
| Zdarzenie | Przykładowa data |
|---|---|
| Pierwsze wprowadzenie produktu do obrotu | Marzec 2027 r. |
| Ostatnia jednostka wprowadzona do obrotu | Grudzień 2030 r. |
| Praktyczne pokrycie dowodów | Do grudnia 2040 r. lub dłużej, jeśli wymaga tego okres wsparcia |
Zegar biegnie od ostatniej jednostki wprowadzonej do obrotu, więc grudzień 2030 r. plus dziesięć lat sięga co najmniej grudnia 2040 r., a dłużej, jeśli okres wsparcia wykracza poza tę datę. Przechowuj SBOM w bezpiecznym, dostępnym miejscu z kopiami zapasowymi i ochroną integralności, abyś mógł odzyskać i udostępnić właściwą wersję na uzasadniony wniosek.
Daty i egzekwowanie
Pełne stosowanie CRA przypada na 11 grudnia 2027 r. Obowiązek zgłaszania podatności zaczyna obowiązywać wcześniej, 11 września 2026 r. Ta wcześniejsza data nie jest osobnym terminem składania SBOM, ale wymaga szybkiego ustalenia, które wersje produktu i komponenty są dotknięte podatnością lub incydentem podlegającym zgłoszeniu. Dla produktów wprowadzanych na rynek UE po rozpoczęciu pełnego stosowania SBOM stanowi część podstawy dowodowej dla oceny zgodności, deklaracji zgodności UE i oznakowania CE. Przebieg zgłoszeń opisuje zgłaszanie podatności i incydentów w CRA. Ogólny harmonogram CRA jest w artykule czym jest CRA, a tabela sankcji w sekcji kary i egzekwowanie CRA.
Najczęściej zadawane pytania
Czy CRA wymaga SBOM nadającego się do odczytu maszynowego, czy wystarczy PDF?
SBOM musi być w powszechnie używanym formacie nadającym się do odczytu maszynowego. PDF lub arkusz kalkulacyjny może towarzyszyć plikowi do przeglądu przez człowieka, ale nie zastępuje SBOM. Praktyczną drogą jest CycloneDX lub SPDX serializowany jako JSON albo XML.
Czy CRA wymaga SBOM dla komponentów open source?
Tak. Komponenty open source nadal są komponentami zawartymi w produkcie, więc należą do SBOM wraz z wersją i identyfikatorem. CRA oczekuje też, że producent zachowa należytą staranność wobec integrowanych komponentów od stron trzecich, w tym wobec oprogramowania open source, które nie zostało mu udostępnione komercyjnie, oraz że zgłosi każdą znalezioną w integrowanym komponencie podatność, także w komponencie open source, podmiotowi, który go utrzymuje.
Kiedy SBOM musi zostać przedłożony: przy wprowadzeniu do obrotu czy na wniosek?
SBOM zwykle nie jest składany proaktywnie. Musi stanowić część dokumentacji technicznej, być gotowy i dostępny dla organów nadzoru rynku na uzasadniony wniosek oraz istnieć w momencie 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ą rozsądnym punktem startowym. Same nie odpowiadają na wszystkie pytania dowodowe CRA ani wszystkie oczekiwania jakości TR-03183. W pracy nad CRA waliduj wygenerowany plik względem wybranego formatu, zapisuj status podatności i uzupełniaj bogatsze pola, takie jak PURL/CPE, hashe i dane relacji, gdy wymaga tego twój framework jakości.
Czy SBOM od dostawców mogą posłużyć do spełnienia wymagań CRA?
Częściowo. SBOM od dostawców są prawidłowymi danymi wejściowymi dla dostarczanych komponentów, ale wciąż należny jest jeden SBOM dla produktu w postaci wprowadzonej do obrotu. Oznacza to konsolidację SBOM od dostawców z własnymi komponentami i zależnościami kompilacji w dowód na poziomie produktu, zgodnie z tym, co opisano powyżej w sekcji o tym, ile SBOM potrzebuje jeden produkt. Traktuj SBOM od dostawców jako surowiec, nie jako gotowy artefakt zgodności.
Co zrobić dalej
- Wybierz format: CycloneDX dla nacisku na bezpieczeństwo i natywnej obsługi VEX albo SPDX dla zgodności licencyjnej i szerszego przyjęcia. Zobacz CycloneDX vs SPDX.
- Zautomatyzuj generowanie w CI/CD przy użyciu Syft, Trivy, cdxgen lub narzędzi do analizy składu oprogramowania (SCA). Jednorazowy eksport nie spełnia obowiązku ciągłego.
- Waliduj jakość pól względem BSI TR-03183 lub wewnętrznej bramki jakości SBOM: nazwa i wersja, dostawca, PURL/CPE, zależności, hashe i licencje.
- Podłącz SBOM do monitorowania podatności (NVD, OSV, GitHub Advisory Database, CISA KEV) przed startem obowiązków zgłaszania 11 września 2026 r.
- Umieść SBOM w dokumentacji technicznej. Przewodnik po dokumentacji technicznej wyjaśnia, gdzie SBOM wpisuje się w całość. Jeśli wolisz nie budować przyjmowania SBOM od zera, CRA Evidence obsługuje intake CycloneDX/SPDX i ocenę jakości TR-03183 dla wersji produktów.