Rola SBOM w CRA
Załącznik I część II wymaga identyfikowania i dokumentowania podatności oraz komponentów produktu, w tym przez sporządzenie SBOM w powszechnie używanym, maszynowo czytelnym formacie, obejmującym co najmniej zależności najwyższego poziomu.
SBOM to nie jednorazowy dokument
- generuj go z powtarzalnego procesu build
- utrzymuj powiązanie z wersją i wydaniem produktu
- normalizuj nazwy, wersje i identyfikatory komponentów
- łącz z monitoringiem podatności i triage
- kontroluj dostęp do informacji wrażliwych
Co powinien zawierać użyteczny SBOM?
Prawne minimum CRA wskazuje zależności najwyższego poziomu. Operacyjny zakres warto dobrać tak, aby po nowym CVE dało się jednoznacznie znaleźć dotknięty produkt i release, bez udawania kompletności, której użyte narzędzie nie zapewnia.
- jednoznaczna tożsamość produktu, wariantu i release'u
- nazwa oraz wersja komponentu i dostawca, gdy jest znany
- relacje zależności i identyfikatory komponentów
- data, źródło i wersja narzędzia generującego
- integralność, pochodzenie i completeness status pliku
Jak włączyć SBOM do pipeline'u?
Ręczny arkusz szybko przestaje odpowiadać faktycznie wydawanemu produktowi. SBOM powinien powstawać powtarzalnie dla konkretnego release'u, przechodzić walidację formatu i trafiać do kontrolowanego repozytorium dowodów razem z identyfikatorami builda lub artefaktu.
Dla firmware, obrazów i dostaw zewnętrznych trzeba jawnie rozróżnić SBOM wygenerowany ze źródeł od obserwacji finalnego artefaktu. Sam manifest repozytorium nie zawsze dowodzi składu tego, co zostało dostarczone klientowi.
Czy obecność komponentu oznacza podatność produktu?
Nie. SBOM pozwala znaleźć kandydatów do analizy, ale dopasowanie komponentu i wersji nie jest automatycznym dowodem affectedness. Human triage powinien uwzględnić używaną funkcję, konfigurację, reachability, vendor fork, backport i dostępne evidence. Wynik tej analizy można następnie wersjonować i wyrazić w VEX.
CycloneDX czy SPDX?
CRA nie sprowadza zgodności do jednego formatu. CycloneDX i SPDX są powszechnie stosowanymi formatami maszynowo czytelnymi; wybór powinien uwzględniać ekosystem, klientów, narzędzia i wymagania łańcucha dostaw.
SBOM i CRA – najczęstsze pytania
Co to jest SBOM?
SBOM (Software Bill of Materials) to ustrukturyzowany wykaz komponentów oprogramowania przypisany do konkretnego produktu i wersji. Pomaga ustalić, jakie zależności zawiera wydanie i które produkty mogą wymagać analizy po ujawnieniu podatności.
Czy CRA wymaga przygotowania SBOM?
Tak. Załącznik I część II pkt 1 CRA wymaga od producenta identyfikowania i dokumentowania podatności oraz komponentów, w tym przez sporządzenie SBOM w powszechnie używanym, maszynowo czytelnym formacie.
Co najmniej co powinien obejmować SBOM według CRA?
CRA wskazuje jako prawne minimum zależności najwyższego poziomu produktu. Praktyczny SBOM może zawierać więcej poziomów i pól, jeżeli pomaga producentowi wiarygodnie identyfikować komponenty, wersje i dotknięte wydania.
Czy SBOM trzeba publikować?
CRA nie ustanawia ogólnego obowiązku publicznego udostępniania SBOM. SBOM jest częścią dokumentacji technicznej; jeżeli producent zdecyduje się udostępnić go użytkownikowi, informacje dla użytkownika powinny wskazywać miejsce dostępu.
Jaki format SBOM wybrać: CycloneDX czy SPDX?
CRA nie narzuca obecnie jednego z tych formatów. CycloneDX i SPDX są formatami maszynowo czytelnymi; wybór powinien zapewniać powtarzalne generowanie, wersjonowanie i powiązanie komponentów z konkretnym wydaniem produktu.
Oficjalne źródła
Podstawa materiału została sprawdzona 12 września 2026.