Wymagania SBOM w ramach unijnego Cyber Resilience Act (CRA)

Unijny Cyber Resilience Act (CRA) wprowadza listę materiałów oprogramowania (SBOM) jako wymóg prawny dla każdego produktu z elementami cyfrowymi sprzedawanego na terenie Unii Europejskiej. Regulacja ta dotyczy szerokiego spektrum produktów: od oprogramowania komputerowego i aplikacji mobilnych, przez urządzenia IoT, aż po systemy przemysłowe i komponenty sieciowe. Niniejszy przewodnik wyjaśnia, czego CRA i BSI TR-03183 wymagają od SBOM, jakie formaty są akceptowane, jakie pola musi zawierać SBOM, jakie kary grożą za brak zgodności oraz kiedy przypadają kluczowe terminy wdrożeniowe.

Czym jest SBOM?

Lista materiałów oprogramowania (SBOM, Software Bill of Materials) to ustrukturyzowany spis każdego komponentu oprogramowania w produkcie: bibliotek, frameworków, pakietów systemowych i ich zależności. Można go porównać do etykiety składników dla oprogramowania: wymienia dokładnie, co znajduje się w środku, dzięki czemu nabywcy i regulatorzy mogą ocenić ryzyko, śledzić podatności i weryfikować zgodność licencyjną. W kontekście CRA, SBOM pełni rolę centralnego dokumentu umożliwiającego organom nadzoru rynku szybką identyfikację, które produkty są dotknięte nowo odkrytą podatnością, na przykład w przypadku pojawienia się kolejnej luki klasy Log4Shell.

Czego CRA wymaga od SBOM?

CRA odwołuje się do SBOM w dwóch kluczowych sekcjach regulacji. Zrozumienie obu jest niezbędne, ponieważ definiują one zarówno wymagania techniczne dotyczące samego SBOM, jak i sposób jego włączenia do dokumentacji technicznej produktu.

Załącznik I: Wymagania zasadnicze

"Producenci identyfikują i dokumentują podatności i komponenty zawarte w produktach, w tym sporządzając listę materiałów oprogramowania w powszechnie stosowanym formacie nadającym się do odczytu maszynowego."

To oznacza:

• SBOM są obowiązkowe, nie opcjonalne
• Muszą być w formacie nadającym się do odczytu maszynowego (nie PDF ani arkusze kalkulacyjne)
• Muszą obejmować wszystkie komponenty, w tym zależności przechodnie

Załącznik VII: Dokumentacja techniczna

Załącznik VII definiuje zawartość dokumentacji technicznej (tzw. technical file), którą producent musi przygotować w ramach procedury oceny zgodności. Dokumentacja techniczna musi zawierać informacje SBOM umożliwiające:

• Śledzenie podatności na poziomie komponentu
• Identyfikację dostawców i źródeł komponentów
• Weryfikację zgodności licencyjnej
• Planowanie końca życia produktu i zarządzanie okresem wsparcia

SBOM stanowi zatem integralną część dokumentacji technicznej, nie jest osobnym dokumentem, lecz elementem dowodu zgodności z wymaganiami CRA.

Jakie formaty SBOM są akceptowane w ramach CRA?

CRA wymaga formatów "powszechnie stosowanych i nadających się do odczytu maszynowego". W praktyce kwalifikują się dwa standardy:

Oba formaty są akceptowane, ale CycloneDX jest coraz częściej preferowany w przypadkach użycia związanych z bezpieczeństwem ze względu na natywne wsparcie dla:

• Vulnerability Exploitability eXchange (VEX): dokumentów określających, czy dana podatność faktycznie wpływa na produkt
• Powiadomień bezpieczeństwa i adnotacji o ryzyku
• Grafów zależności z pełną hierarchią komponentów

W praktyce wiele organizacji generuje SBOM w obu formatach jednocześnie: CycloneDX dla wewnętrznego zarządzania bezpieczeństwem i SPDX na potrzeby klientów wymagających informacji licencyjnych.

graph TD
    SBOM((SBOM))
    SCN[Nazwy Komponentów] --> SBOM
    VS[Wersje] --> SBOM
    SUP[Informacje o Dostawcy] --> SBOM
    DEP[Zależności] --> SBOM
    LIC[Licencje] --> SBOM
    PURL[Adresy URL Pakietów] --> SBOM
    HASH[Wartości Hash] --> SBOM
    OSC[Komponenty Open Source] --> SBOM
    style SBOM fill:#008080,color:#fff,stroke:#006666,stroke-width:4px
    style SCN fill:#e8f4f8,stroke:#008080,color:#333
    style VS fill:#e8f4f8,stroke:#008080,color:#333
    style SUP fill:#e8f4f8,stroke:#008080,color:#333
    style DEP fill:#e8f4f8,stroke:#008080,color:#333
    style LIC fill:#e8f4f8,stroke:#008080,color:#333
    style PURL fill:#e8f4f8,stroke:#008080,color:#333
    style HASH fill:#e8f4f8,stroke:#008080,color:#333
    style OSC fill:#e8f4f8,stroke:#008080,color:#333

Jakie pola musi zawierać SBOM?

Niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji (BSI) opublikował TR-03183, który zawiera szczegółowe wymagania jakościowe SBOM wykraczające poza minimum CRA. Wykorzystaj go jako docelowy standard zgodności.

Pola obowiązkowe (BSI TR-03183)

• Nazwa i wersja komponentu
• Informacje o dostawcy/producencie
• Unikalne identyfikatory (PURL, CPE)
• Relacje zależności
• Informacje o licencji

Poziomy jakości

TR-03183 definiuje trzy poziomy jakości:

Choć TR-03183 jest niemieckim standardem, staje się de facto punktem odniesienia jakości dla zgodności z CRA w całej Unii Europejskiej. Producenci powinni celować co najmniej w poziom standardowy, a w przypadku produktów krytycznych (Klasa I i II według CRA) celować w poziom kompleksowy.

Jakie są terminy zgodności SBOM w CRA?

CRA wprowadza stopniowy harmonogram egzekwowania przepisów:

Produkty wprowadzone na rynek UE po grudniu 2027, które nie posiadają zgodnego SBOM, nie mogą nosić oznakowania CE i nie mogą być legalnie sprzedawane. Warto podkreślić, że już od września 2026 obowiązek raportowania podatności wymaga de facto posiadania aktualnego SBOM. Bez niego producent nie jest w stanie skutecznie identyfikować, które komponenty w jego produktach są dotknięte nowo odkrytą podatnością.

Co się stanie w przypadku niezgodności?

Brak zgodności z CRA niesie ze sobą poważne konsekwencje:

• Kary do 15 milionów EUR lub 2,5% globalnego rocznego obrotu (w zależności od tego, która kwota jest wyższa)
• Wycofanie produktu ze sprzedaży lub z rynku UE
• Zakaz wprowadzenia na rynek: niezgodne produkty nie mogą nosić oznakowania CE
• Wpływ na łańcuch dostaw: Twoi klienci mogą nie być w stanie wykorzystać Twojego produktu w ramach własnej zgodności z CRA

Organy nadzoru rynku w każdym państwie członkowskim UE będą egzekwować te kary. W Polsce funkcję tę pełni NASK (Naukowa i Akademicka Sieć Komputerowa) jako krajowy CSIRT, we współpracy z Urzędem Ochrony Konkurencji i Konsumentów (UOKiK) w zakresie nadzoru rynku produktów cyfrowych.

Częste błędy SBOM

Poniżej przedstawiamy najczęstsze problemy, które widzimy w SBOM przesyłanych przez producentów przygotowujących się do zgodności z CRA. Każdy z tych błędów może skutkować odrzuceniem SBOM podczas oceny zgodności.

1. Niepełne drzewa zależności

Wiele narzędzi przechwytuje wyłącznie bezpośrednie zależności. CRA wymaga zależności przechodnich, czyli komponentów, od których zależą Twoje zależności. W typowej aplikacji webowej stosunek zależności przechodnich do bezpośrednich wynosi od 5:1 do 10:1, co oznacza, że SBOM obejmujący jedynie zależności bezpośrednie pomija zdecydowaną większość komponentów.

Twój Produkt
├── Biblioteka A (bezpośrednia) ✓
│   ├── Biblioteka B (przechodnia) ← Często brakuje!
│   └── Biblioteka C (przechodnia) ← Często brakuje!
└── Biblioteka D (bezpośrednia) ✓

2. Brak informacji o wersji

SBOM bez dokładnych informacji o wersji jest niemal bezużyteczny do dopasowywania podatności. Upewnij się, że każdy komponent zawiera:

• Dokładne numery wersji (nie zakresy)
• Wartości hash dla komponentów binarnych
• Identyfikatory PURL wszędzie tam, gdzie to możliwe

3. Nieaktualne SBOM

SBOM wygenerowany w czasie budowania, ale nigdy nieaktualizowany, tworzy fałszywe poczucie bezpieczeństwa. CRA wymaga, aby SBOM był aktualny przez cały okres wsparcia produktu, co oznacza regularne odświeżanie przy każdym wydaniu. Wdróż:

• Integrację CI/CD dla automatycznego generowania SBOM przy każdym buildzie
• Kontrolę wersji dla artefaktów SBOM (przechowywanie historii zmian)
• Regularne wykrywanie odchyleń (drift detection) między kompilacjami, aby identyfikować nieoczekiwane zmiany w zależnościach

4. Ignorowanie firmware i hardware

CRA obejmuje nie tylko oprogramowanie aplikacyjne, ale również produkty z elementami cyfrowymi zawierające firmware. Dla produktów z wbudowanymi komponentami pamiętaj o uwzględnieniu:

• Wersji i komponentów firmware (w tym systemu operacyjnego czasu rzeczywistego, jeśli jest stosowany)
• Listy materiałów sprzętowych (HBOM) tam, gdzie ma to zastosowanie
• Komponentów bootloadera i jądra systemu
• Sterowników i bibliotek dostarczanych przez producenta sprzętu

Jak zacząć?

Wdrożenie praktyk SBOM zgodnych z CRA nie musi być przytłaczające. Oto sześć praktycznych kroków, które pozwolą Ci systematycznie dojść do pełnej zgodności:

1. Zbadaj obecny stan: Czy generujesz już SBOM? W jakim formacie? Jakie jest pokrycie komponentów? Przeprowadź inwentaryzację wszystkich produktów z elementami cyfrowymi, które wprowadzasz na rynek UE

2. Wybierz format: CycloneDX dla fokusa na bezpieczeństwie, SPDX dla zgodności licencyjnej (lub oba, CRA akceptuje obydwa). Jeśli dopiero zaczynasz, CycloneDX jest prostszy do wdrożenia i lepiej wspiera przypadki użycia wymagane przez CRA

3. Zautomatyzuj generowanie: Zintegruj generowanie SBOM z pipeline CI/CD przy użyciu narzędzi takich jak Syft, Trivy lub cdxgen. Ręczne tworzenie SBOM jest podatne na błędy i nie skaluje się przy wielu produktach. Przed publikacją waliduj zgodność ze schematem, kompletność i dokładność wersji

4. Zweryfikuj jakość: Sprawdź swoje SBOM pod kątem wymagań TR-03183. Czy wszystkie obowiązkowe pola są uzupełnione? Celuj w poziom co najmniej standardowy. Zwróć szczególną uwagę na kompletność drzewa zależności i obecność identyfikatorów PURL

5. Wdróż monitoring: Połącz SBOM z bazami danych podatności (NVD, OSV, GitHub Advisory Database, CISA KEV) w celu ciągłego śledzenia zagrożeń. To kluczowy krok w kontekście obowiązku raportowania podatności od września 2026

6. Zaplanuj cykl aktualizacji: Ustanów procesy tak, aby każde wydanie produktu generowało świeży, zwalidowany SBOM. Przechowuj artefakty SBOM przez cały okres wsparcia produktu (minimum 5 lat zgodnie z CRA). Zdefiniuj odpowiedzialność za utrzymanie SBOM w zespole

Najczęściej zadawane pytania

Jakie formaty SBOM akceptuje CRA?

CRA wymaga formatów "powszechnie stosowanych i czytelnych maszynowo." CycloneDX (OWASP) i SPDX (Linux Foundation) spełniają ten wymóg. Rozporządzenie nie wymienia ich wprost, ale żaden inny format nie osiąga tego poziomu w praktyce.

Czy elementy minimalne NTIA spełniają wymagania CRA?

Elementy minimalne NTIA (nazwa dostawcy, nazwa komponentu, wersja, unikalne identyfikatory, relacje zależności, autor SBOM i znacznik czasu) są ogólnie zgodne z tym, czego wymagają CRA i CERT Polska (NASK) na poziomie podstawowym. Ale BSI TR-03183 idzie dalej: wartości hash i identyfikatory PURL są oczekiwane dla zgodności z CRA.

Czy CRA wymaga SBOM dla komponentów open source?

Tak. Załącznik I zobowiązuje producentów do dokumentowania wszystkich komponentów w czytelnym maszynowo SBOM, bez wyjątku dla oprogramowania open source. Każda biblioteka open source w Twoim produkcie musi pojawić się w SBOM z wersją i identyfikatorami.

Kiedy SBOM musi zostać złożony: przy wprowadzeniu na rynek czy na żądanie?

SBOM nie musi być składany proaktywnie. Stanowi część dokumentacji technicznej (Załącznik VII) i musi być dostępny dla organów nadzoru rynku na żądanie. Musi istnieć w momencie wprowadzenia produktu na rynek UE.

Czy CRA wymaga SBOM czytelnego maszynowo czy wystarczy plik PDF?

Załącznik I wyraźnie wymaga formatu czytelnego maszynowo. Plik PDF nie jest akceptowalny. CycloneDX lub SPDX w formacie JSON lub XML spełnia wymaganie. Arkusz kalkulacyjny ani dokument czytelny przez człowieka nie spełnia tego wymogu.

Jak długo SBOM musi być przechowywany po wycofaniu produktu?

Dokumentacja techniczna, która obejmuje SBOM, musi być przechowywana przez 10 lat od ostatniego wprowadzenia produktu na rynek lub przez przewidywany okres użytkowania, jeśli jest on dłuższy (CRA Artykuł 23). SBOM musi być aktualny przez cały aktywny okres wsparcia, który CRA ustala na minimum 5 lat.

Następne kroki

Zarządzasz zgodnością CRA dla wielu produktów? CRA Evidence śledzi Twoje SBOM, ocenia je według poziomów jakości BSI TR-03183 i zgłasza nowe podatności, gdy tylko się pojawią.

Po wyborze formatu zapoznaj się z przewodnikiem generowania SBOM, aby zautomatyzować tworzenie w CI/CD. Sprawdź przewodnik po dokumentacji technicznej Załącznik VII, aby zrozumieć, gdzie Twój SBOM wpisuje się w szerszą dokumentację zgodności.

Ten artykuł służy wyłącznie celom informacyjnym i nie stanowi porady prawnej. W celu uzyskania konkretnych wskazówek dotyczących zgodności skonsultuj się z wykwalifikowanym radcą prawnym.