Większość producentów odkrywa luki w SBOM dopiero podczas pierwszego przeglądu zgodności, a nie przed nim. Do tego momentu termin egzekwowania jest bliższy, a zakres działań naprawczych szerszy. Obowiązek SBOM wynikający z Załącznika I CRA jest prosty w opisaniu: format nadający się do odczytu maszynowego, zależności najwyższego poziomu jako minimum, przechowywany w dokumentacji technicznej zgodnie z Załącznikiem VII. To, co sprawia producentom trudności, to sformułowanie „co najmniej". Niniejsza strona omawia sześć błędów, które tworzą największą przepaść między formalnym SBOM a dokumentem, który przetrwałby kontrolę organu nadzoru rynku.
Najważniejsze informacje
- Zatrzymanie się na zależnościach bezpośrednich pozostawia podatności przechodnie poza zakresem SBOM
- SBOM stworzony jednorazowo staje się nieaktualny w ciągu kilku tygodni wraz z publikacją nowych CVE
- Brak wartości skrótów i identyfikatorów PURL nie spełnia wymogów jakościowych BSI TR-03183
- Ręczne tworzenie SBOM nie zaspokaja ciągłego obowiązku aktualizacji wynikającego z CRA
- Komponenty wewnętrzne i zastrzeżone muszą figurować obok bibliotek open source
- SBOM od dostawców to surowiec, a nie gotowy artefakt zgodności
Przegląd błędów
| # | Błąd | Dlaczego nie spełnia wymogów | Rozwiązanie |
|---|---|---|---|
| 1 | Zatrzymanie się na zależnościach bezpośrednich | Przechodnie CVE niewidoczne dla skanerów | Pliki lock oraz skanowanie artefaktów skompilowanych |
| 2 | Traktowanie SBOM jako dokumentu jednorazowego | Nieaktualny w ciągu kilku tygodni od nowych CVE | Generowanie w CI/CD przy każdej kompilacji |
| 3 | Brak pól tożsamości | Brak dopasowania CVE, TR-03183 nie spełnione | Dokładna wersja, SHA-256, PURL, dostawca |
| 4 | Generowanie ręczne | Nie nadąża za tempem wydań | Automatyzacja: Syft, Trivy lub cdxgen |
| 5 | Pomijanie komponentów wewnętrznych i zastrzeżonych | Załącznik I nie czyni takiego rozróżnienia | Wewnętrzne identyfikatory, własna organizacja jako dostawca, SHA-256 |
| 6 | Traktowanie SBOM od dostawców jako artefaktu końcowego | Obowiązek z Załącznika I spoczywa na producencie | Konsolidacja do jednego SBOM produktu |
Błąd 1: zatrzymanie się na zależnościach bezpośrednich
Załącznik I, Część II, pkt 1 wyznacza prawne minimum na poziomie zależności najwyższego poziomu. Wielu producentów zatrzymuje się dokładnie w tym miejscu. Problem nie leży w niespełnieniu prawnego minimum. Problem tkwi w ryzyku, które to minimum pozostawia poza obszarem widoczności. Zależność przechodnia (biblioteka, od której zależy bezpośrednia zależność) jest tak samo podatna na ataki jak zależność bezpośrednia. Gdy CVE jest publikowane dla pakietu przechodniego nieujętego w SBOM, dopasowanie jest niemożliwe, zgłoszenie niemożliwe, a producent jest narażony bez wiedzy o tym fakcie.
Twój produkt
+-- Biblioteka A (bezpośrednia) ← prawne minimum, poziom Załącznika I
| +-- Biblioteka B (przechodnia) ← poza SBOM, niewidoczna dla skanerów podatności
| \-- Biblioteka C (przechodnia) ← poza SBOM, niewidoczna dla skanerów podatności
\-- Biblioteka D (bezpośrednia) ← prawne minimum, poziom Załącznika I
Rozwiązaniem jest odpowiednie oprzyrządowanie i konfiguracja. Należy korzystać z plików lock i skanować artefakty skompilowane, a nie tylko kod źródłowy. Trivy, Syft i cdxgen obsługują przechwytywanie zależności przechodnich przy prawidłowej konfiguracji. BSI TR-03183 traktuje pełne pokrycie przechodnie jako wskaźnik jakości odróżniający SBOM spełniający minimum od naprawdę użytecznego. Wymagania dotyczące pól na każdym poziomie jakości przedstawia strona poziomy jakości BSI TR-03183.
Błąd 2: traktowanie SBOM jako dokumentu jednorazowego
SBOM wygenerowany raz i nigdy nieaktualizowany tworzy fałszywe poczucie bezpieczeństwa. Nowe CVE są codziennie publikowane dla komponentów już obecnych w produkcie. SBOM dokładny w chwili kompilacji staje się nieaktualny w ciągu kilku tygodni. Obowiązek wynikający z Załącznika I CRA ma charakter ciągły: SBOM musi odzwierciedlać aktualny stan produktu przez cały okres wsparcia.
Obowiązkowe przesłanki aktualizacji wynikające z CRA:
| 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 |
Rozwiązaniem jest integracja z CI/CD. Każda kompilacja powinna generować aktualny artefakt SBOM przechowywany razem z wydaniem. Ręczny eksport nie nadąża za częstotliwością aktualizacji wymaganą przez CRA. Pełna lista przesłanek i 10-letni zegar przechowywania: wymogi CRA dotyczące SBOM.
Od 11 września 2026 r. producent musi zgłaszać aktywnie wykorzystywane podatności do ENISA w ciągu 24 godzin. Nieaktualny SBOM uniemożliwia ustalenie przed startem zegara, czy produkt jest podatny. Aktualne dane o komponentach muszą być dostępne przed incydentem, a nie po nim.
Błąd 3: brak pól tożsamości
SBOM bez dokładnych pól wersji, skrótu i identyfikatora jest praktycznie bezużyteczny do dopasowywania podatności. Pola te łączą wpis komponentu z rekordem CVE w Krajowej Bazie Danych Podatności (NVD), OSV lub CISA KEV. Bez nich skanery podatności nie mogą dopasować wyników do komponentów, a kontrole jakości BSI TR-03183 zakończą się niepowodzeniem.
Każdy komponent musi zawierać:
| Pole | Dlaczego jest istotne | Źródło |
|---|---|---|
| Dokładny numer wersji | Wymagany do dopasowania CVE/NVD/OSV (nie „latest" ani zakresy) | Załącznik I; TR-03183 obowiązkowy |
| Skrót SHA-256 | Weryfikacja integralności składników binarnych | TR-03183 obowiązkowy |
| Identyfikator PURL | Łączy komponent z wpisem w rejestrze | TR-03183 obowiązkowy |
| Nazwa dostawcy | Wymagana na każdym poziomie jakości | Załącznik I; TR-03183 |
Częstym błędem dotyczącym wersji jest stosowanie CycloneDX 1.3 lub wcześniejszego. Podstawowa obsługa VEX została dodana w CycloneDX 1.4 (styczeń 2022 r.), a bogatsza struktura evidence komponentu (identity, occurrences) używana do demonstrowania identyfikowalności CRA pojawiła się w wersji 1.5 (czerwiec 2023 r.). W celu zgodności z CRA należy używać CycloneDX 1.6 lub nowszego. Przed założeniem zgodności warto sprawdzić wersję wyjściową stosowanego narzędzia.
Błąd 4: ręczne generowanie SBOM
Ręczne tworzenie SBOM jest podatne na błędy i nie skaluje się w przypadku wielu wersji produktu. Ręcznie tworzony SBOM pomija komponenty, które znalazłyby automatyczne narzędzia, zawiera błędy w ciągach wersji i nie może być wiarygodnie regenerowany przy zmianie komponentu. Co ważniejsze, proces ręczny nie może sprostać ciągłemu obowiązkowi aktualizacji wynikającemu z CRA: każde wydanie, każda poprawka i każda zmiana komponentu wymaga zaktualizowanego SBOM.
Generowanie należy zautomatyzować za pomocą Syft, Trivy lub cdxgen. Wpisy ręczne powinny być zarezerwowane dla komponentów, których automatyczne narzędzia nie mogą wykryć, takich jak biblioteki komercyjne bez wpisów w bazach pakietów lub zastrzeżone obiekty binarne oprogramowania układowego. Pozostałe komponenty powinny pochodzić z procesu kompilacji. Organy nadzoru rynku mogą zażądać SBOM w dowolnym momencie; musi on odzwierciedlać aktualny stan produktu.
Błąd 5: pomijanie komponentów wewnętrznych i zastrzeżonych
Powszechnym skrótem jest dokumentowanie wyłącznie zależności open source z pominięciem bibliotek wewnętrznych, zastrzeżonych modułów lub obiektów binarnych oprogramowania układowego. Załącznik I nie czyni takiego rozróżnienia. Jeśli komponent jest zawarty w produkcie, należy do SBOM.
Komponenty wewnętrzne często nie mają PURL ani wpisu w rejestrze. Właściwym podejściem jest przypisanie wewnętrznego identyfikatora, wskazanie własnej organizacji jako dostawcy oraz podanie skrótu SHA-256 artefaktu binarnego. BSI TR-03183 wprost obejmuje komponenty zastrzeżone na wszystkich poziomach jakości.
W przypadku produktów z wbudowanym oprogramowaniem układowym od ODM lub producenta układu scalono nie można przeprowadzić audytu tego, czego się nie zbudowało. Rozwiązaniem jest klauzula umowna: należy wymagać od dostawców oprogramowania układowego dostarczenia SBOM. Zgodnie z CRA producent ponosi odpowiedzialność za cały produkt, niezależnie od tego, kto napisał kod. W przypadku produktów łączących sprzęt i oprogramowanie: HBOM w ramach CRA wyjaśnia, kiedy obok SBOM potrzebny jest zestawienie podstawowych materiałów sprzętowych.
Błąd 6: traktowanie SBOM od dostawców jako gotowego artefaktu
SBOM od dostawców stanowią prawidłowe dane wejściowe, a CRA oczekuje, że producenci będą korzystać z dokumentacji upstream. Nie zastępują one jednak zintegrowanego SBOM produktu. Obowiązek wynikający z Załącznika I spoczywa na producencie produktu wprowadzanego do obrotu na rynku UE: producent musi skonsolidować SBOM od dostawców z własnymi komponentami pierwszej strony, zależnościami kompilacji i kodem spinającym w jeden SBOM dla zintegrowanego produktu.
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 przed wprowadzeniem produktu na rynek. SBOM od dostawców należy traktować jako surowiec. SBOM produktu jest gotowym artefaktem zgodności.
Najczęściej zadawane pytania
Czy SBOM od dostawców może posłużyć do spełnienia wymogów CRA?
Częściowo. SBOM od dostawców stanowią prawidłowe 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 produktu wprowadzanego do obrotu na rynku UE: producent musi sporządzić i utrzymywać SBOM dla zintegrowanego produktu, co oznacza konsolidację SBOM od dostawców z własnymi komponentami pierwszej strony, zależnościami kompilacji i kodem spinającym. 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 przed wprowadzeniem produktu na rynek. SBOM od dostawców należy traktować jako surowiec, a nie jako gotowy artefakt zgodności.
Jakie jest prawne minimum pokrycia zależności SBOM wynikające z CRA?
Załącznik I, Część II, pkt 1 wyznacza minimum na poziomie zależności najwyższego poziomu. Oficjalny tekst 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, że zależności bezpośrednie stanowią prawne minimum. Zależności przechodnie nie są prawnie wymagane, ale są zdecydowanie zalecane jako najlepsza praktyka: to one są faktycznie potrzebne skanerom podatności do dokładnego dopasowywania CVE, a BSI TR-03183 traktuje pokrycie przechodnie jako wskaźnik jakości.
Czy SBOM wymaga aktualizacji przy każdym wydaniu poprawki?
Tak. Każde wydanie poprawki bezpieczeństwa stanowi obowiązkową przesłankę aktualizacji SBOM wynikającą z CRA. Dokumentacja techniczna, obejmująca SBOM, musi być aktualna przez cały cykl życia produktu. Po wprowadzeniu poprawki do podatnego komponentu SBOM musi odzwierciedlać nową wersję. Generowanie SBOM należy zautomatyzować w CI/CD, tak aby wydania poprawek automatycznie generowały zaktualizowany artefakt SBOM bez ręcznego kroku, który może zostać pominięty pod presją czasu.