Błędy SBOM w CRA: 7 praktycznych poprawek dla producentów

Generator SBOM działa, plik przechodzi walidację, a mimo to kolejny przegląd produktu wciąż wykazuje luki. Powtarzające się problemy z gotowością do CRA to rzadko niejasne przypadki prawne na marginesie. To płytkie drzewa zależności, inwentarze tylko z kodu źródłowego, nieaktualne rekordy i komponenty, których skanery nie potrafią dopasować do podatności. Akt o cyberodporności wymaga powszechnie stosowanego, nadającego się do odczytu maszynowego SBOM obejmującego co najmniej zależności najwyższego poziomu, przechowywanego w dokumentacji technicznej. Artykuł omawia siedem luk między SBOM, który technicznie istnieje, a takim, który może wesprzeć obsługę podatności. To SBOM, który organ nadzoru rynku spodziewa się zobaczyć.

Błędy w skrócie

• Drzewo źródłowe, nie dostarczony artefakt: generuj ze zbudowanego artefaktu lub obrazu, aby skompilowany kod, pakiety systemu operacyjnego i firmware były widoczne.
• Skąpe pola tożsamości: używaj dokładnych wersji, skrótów, PURLi tam gdzie dostępne, i nazw dostawców, aby skanery mogły dopasowywać CVE.
• Tylko zależności bezpośrednie: dodaj skanowanie pliku lock i zbudowanego artefaktu, aby zależności pośrednie i spakowane weszły do SBOM.
• Jednorazowy plik: regeneruj i archiwizuj SBOM przy każdym wydaniu, a następnie utrzymuj dopasowywanie podatności na bieżąco.
• Pominięty kod produktu: komponenty wewnętrzne, zastrzeżone, komercyjne i firmware też potrzebują identyfikatorów i dowodów.
• Kopiowanie od dostawcy: SBOM od dostawców to dane wejściowe. Uzgodnij je z kodem pierwszej strony i finalnym artefaktem wydania.
• Rozproszenie SBOM: utrzymuj jeden autoryzowany SBOM produktu na wydanie, tak aby wersja 1.4.2 miała jeden wiarygodny rekord.

Co liczy się jako dowód SBOM

Ten próg prawny to nie to samo co użyteczny próg zarządzania podatnościami. SBOM obejmujący tylko zależności bezpośrednie może spełniać minimalne wymaganie, ale będzie zbyt płytki, by szybko zidentyfikować dotknięte produkty. BSI TR-03183, wytyczne ENISA, wytyczne CISA SBOM i aktualna praktyka narzędziowa najlepiej traktować jako wskaźniki jakości, które pomagają producentom wdrożyć obowiązek wynikający z CRA.

Błąd 1: SBOM opisuje drzewo źródłowe, a nie produkt, który został wysłany

Manifesty źródłowe są wygodne, ale nie są produktem. Skan kodu źródłowego może nadmiernie raportować zależności deweloperskie i pominąć to, co pojawia się dopiero po kompilacji, pakowaniu, warstwowaniu kontenera, statycznym linkowaniu lub integracji firmware. Dla producenta SBOM powinien odpowiedzieć na pytanie, co znalazło się w wydaniu produktu, a nie tylko co zostało zadeklarowane w pliku pakietu.

Różnica ma największe znaczenie w produktach wbudowanych i skonteneryzowanych. Skan na poziomie języka może pominąć pakiety systemu operacyjnego w bazowej warstwie kontenera. Eksport z Yocto lub Buildroot może pominąć firmware dostawcy krzemu, bootloadery, moduły jądra lub binarne bloki, które trafiły spoza systemu kompilacji. Jeśli te komponenty są w dostarczonym artefakcie, należą do dowodów wydania nawet gdy automatyczny skaner pakietów nie może ich wykryć.

Rozwiązaniem jest generowanie ze zbudowanego artefaktu lub obrazu wydania, a następnie porównanie z wynikami ze źródła i pliku lock. Dla kontenerów skanuj finalny obraz po digest. Dla firmware łącz wyniki ze zbudowanego systemu SBOM z analizą binarną i ręcznymi rekordami dla komponentów, których narzędzia nie potrafią automatycznie zidentyfikować.

Błąd 2: brakujące skróty i PURLe uniemożliwiają dopasowanie komponentów

SBOM bez dokładnej wersji, skrótu, dostawcy i identyfikatorów pakietów jest trudny w użyciu do dopasowywania podatności. Plik może być nadający się do odczytu maszynowego, ale skaner nadal potrzebuje stabilnej tożsamości komponentu, by zdecydować, czy wpis CVE, komunikat OSV, GitHub Security Advisory lub wpis CISA KEV ma zastosowanie.

Każdy komponent powinien nieść wystarczającą tożsamość, by przetrwać automatyczne dopasowywanie:

To nie tylko kwestia porządku. NIST ogłosił 15 kwietnia 2026 r., że wzbogacanie NVD jest teraz priorytetyzowane dla wybranych CVE, ponieważ liczba podatności przewyższyła możliwości pełnego wzbogacania. Sprawia to, że dopasowywanie wyłącznie na podstawie CPE jest słabszą strategią dla przyszłych operacji na podatnościach. Używaj PURL tam gdzie dostępny, zachowuj skróty dla dostarczonych artefaktów i nie traktuj samej nazwy komponentu jako wystarczającej.

Częstym błędem dotyczącym formatu jest stosowanie CycloneDX 1.3 lub wcześniejszego. Podstawowa obsługa VEX pojawiła się w CycloneDX 1.4, a bogatsza struktura evidence komponentu pojawiła się w CycloneDX 1.5. Na potrzeby aktualnego przygotowania do CRA celuj w CycloneDX 1.6 lub nowszy, albo bieżący profil SPDX, który narzędzia potrafią niezawodnie przetworzyć. Sprawdź wyniki generatora zanim przyjmiesz, że format obsługuje pola potrzebne w procesie.

Błąd 3: zatrzymanie się na zależnościach bezpośrednich

Zależności bezpośrednie to minimalny próg CRA. Nie wystarczają do użytecznej obsługi podatności. Zależność przechodnia to komponent pobrany przez inny komponent i może nieść podatność, która ma znaczenie. Gdy CVE dotyczy przechodniego pakietu nieujętego w SBOM, produkt może być dotknięty, podczas gdy pipeline dopasowywania pozostaje cichy.

By zamknąć tę lukę, używaj plików lock tam gdzie ekosystem je obsługuje, skanuj zbudowane artefakty oraz kod źródłowy i sprawdzaj pakiety, które dołączają lub cieniują zależności. Traktuj pokrycie przechodnie jako praktykę jakości audytowej, a nie luźne ustawienie domyślne ukryte w konfiguracji skanera.

Błąd 4: traktowanie SBOM jako dokumentu jednorazowego

SBOM wygenerowany raz i nigdy nieaktualizowany tworzy fałszywe poczucie bezpieczeństwa. Nowe CVE są publikowane dla komponentów już obecnych w produkcie. Nowe wersje firmware, poprawki i aktualizacje dostawców zmieniają produkt. CRA oczekuje też, że dokumentacja techniczna będzie w stosownych przypadkach na bieżąco aktualizowana przez okres wsparcia.

Typowe przesłanki aktualizacji:

CI/CD to praktyczna kontrola. Każde wydanie powinno generować aktualny artefakt SBOM przechowywany razem z kompilacją i powiązany z dokumentacją techniczną. Wpisy ręczne powinny istnieć tylko dla komponentów, których narzędzia nie potrafią wykryć, a te wpisy nadal wymagają przeglądu, gdy produkt się zmienia.

Błąd 5: pomijanie komponentów wewnętrznych, zastrzeżonych i firmware

Częstym skrótem jest dokumentowanie tylko zależności open source z pominięciem bibliotek wewnętrznych, modułów komercyjnych, zastrzeżonego firmware lub obiektów binarnych od dostawców. To nie jest SBOM produktu. Jeśli komponent jest zawarty w produkcie, wchodzi w zakres, nawet gdy nie ma publicznej strony w rejestrze.

Komponenty wewnętrzne często nie mają PURL ani publicznego rekordu pakietu. Należy używać wewnętrznego identyfikatora, własnej organizacji jako dostawcy tam gdzie to stosowne, dokładnej wersji lub ID kompilacji oraz skrótu artefaktu binarnego. Dla komponentów komercyjnych przechowuj nazwę dostawcy, wersję, dowód licencji i referencje kontraktowe w dokumentacji technicznej.

Dla produktów sprzętowo-programowych firmware to miejsce, gdzie staje się to widoczne. Moduły Wi-Fi, modemy, bezpieczne elementy, bootloadery, pliki binarne zaufanego środowiska wykonania i moduły jądra spoza drzewa mogą nieść podatności, a mimo to pozostają niewidoczne dla skanerów pakietów językowych. Używaj SBOM od dostawców tam gdzie dostępne, dodawaj ręczne rekordy tam gdzie nie, i używaj analizy binarnej jako kontroli. Informacje o sprzętowej części pakietu dowodów znajdziesz w HBOM w ramach CRA.

Błąd 6: poleganie na SBOM od dostawców jako gotowym artefakcie

SBOM od dostawców to prawidłowe dane wejściowe. Nie są gotowym SBOM produktu. Producent wprowadza zintegrowany produkt na rynek UE. SBOM produktu musi łączyć komponenty dostawców, kod pierwszej strony, wyniki kompilacji, firmware, kod integracyjny i zależności specyficzne dla produktu.

Błąd jest łatwy do przeoczenia: jeden dostawca dostarcza plik CycloneDX, inny daje SPDX, trzeci daje PDF z inwentarzem, a finalny folder produktu zawiera linki do wszystkich trzech. To dowód od dostawców, nie jeden rekord produktu. Recenzent nadal musi wiedzieć, które komponenty były w wersji 1.4.2 produktu.

Uzgadniaj zamiast kopiować. Łącz SBOM od dostawców do SBOM produktu, normalizuj pola tożsamości, rejestruj znane braki i zachowuj SBOM upstream jako dowody pomocnicze. Jeśli SBOM dostawcy nie ma PURL, skrótu, licencji lub dokładnej wersji, udokumentuj lukę i zamknij co możesz przed wydaniem. URL do pliku upstream to nie to samo co zintegrowany SBOM produktu.

Błąd 7: wiele SBOM, brak jednego rekordu produktu

Rozproszenie SBOM to etap po tym, jak zespoły wdrażają narzędzia. Jest SBOM aplikacji, SBOM kontenera, SBOM firmware, kilka SBOM od dostawców i arkusz kalkulacyjny prowadzony przez product managera. Żaden z nich nie jest autoryzowaną odpowiedzią dla wydania produktu wprowadzonego do obrotu.

To tworzy ryzyko audytowe i operacyjne. Gdy pojawia się nowa aktywnie wykorzystywana podatność, zespół musi przeszukać fragmenty zanim będzie mógł powiedzieć, czy produkt jest dotknięty. Gdy organ składa uzasadnione żądanie, pakiet dowodów nie powinien zależeć od tego, czy ktoś pamięta, który folder zawiera ostatnie połączenie.

Używaj jednego autoryzowanego SBOM produktu na wydanie, z pomocniczymi SBOM komponentów zachowanymi poniżej. Przechowuj go przez co najmniej 10 lat od momentu wprowadzenia produktu do obrotu lub przez okres wsparcia, zależnie od tego, co jest dłuższe. Przechowuj go tam, gdzie wydanie, monitorowanie podatności, decyzje VEX i dokumentacja techniczna mogą wszystkie odwoływać się do tej samej wersji.