Co wpisać w żądaniu SBOM do dostawcy?
- nazwa i dokładna wersja komponentu albo artefaktu
- produkt i release, w którym komponent jest używany
- preferowany maszynowo czytelny format, np. CycloneDX lub SPDX
- oczekiwany zakres zależności i informacja o zależnościach najwyższego poziomu
- data wygenerowania i identyfikator narzędzia lub procesu
- kontakt do wyjaśnień oraz termin odpowiedzi
- prośba o wskazanie replacementu, jeżeli przesłany SBOM zostanie poprawiony
Jak zweryfikować otrzymany SBOM bez udawania skanera
Review powinien najpierw sprawdzić strukturę i zastosowanie dokumentu: format, możliwość odczytu, deklarowaną wersję, identyfikatory komponentów, datę oraz relację z targetem requestu. Taki przegląd nie potwierdza kompletności kodu ani braku podatności.
| Kontrola | Wynik pozytywny | Bezpieczny wynik przy braku danych |
|---|---|---|
| Format | plik jest maszynowo czytelny i zgodny z deklarowanym formatem | REVIEW_REQUIRED |
| Wersja | SBOM jawnie odnosi się do żądanej wersji komponentu | UNDETERMINED |
| Target | istnieje jawny link do produktu, release'u i component occurrence | UNDETERMINED |
| Historia | replacement zachowuje poprzedni plik, checksum i lineage | nie nadpisuj dokumentu |
| Zakres | dostawca opisał zakres zależności i ograniczenia | zażądaj uzupełnienia |
Nowa wersja komponentu wymaga nowej oceny freshness
SBOM dla Component X v3.2 może pozostać historycznie poprawny dla release'u, w którym użyto v3.2, ale nie powinien być oznaczony jako current dla v3.3. Nie kopiuj zastosowania na podstawie podobnej nazwy komponentu, daty uploadu albo tekstu dostawcy.
Zachowaj oba rekordy: starszy jako evidence dla historycznego targetu, nowszy jako osobną wersję do review. To umożliwia późniejsze ustalenie, które wydania produktu zawierały daną zależność.
SBOM i VEX od dostawcy pełnią różne role
SBOM opisuje komponenty i zależności, a VEX przekazuje stanowisko o wpływie konkretnych podatności. Supplier VEX jest źródłowym oświadczeniem. Nie powinien automatycznie ustawiać AFFECTED, NOT_AFFECTED, FIXED ani uruchamiać Article 14.
Po przyjęciu do rejestru producent może jawnie przekazać SBOM lub VEX do swojego procesu Vulnerability Intelligence, zachowując pochodzenie, wersję i dokładny target.
Supplier Portal bez konta Workspace
Accountless portal ogranicza dostęp do jednego requestu i pozwala dostawcy przesłać plik, wersję oraz odpowiedź bez wglądu w Product Inventory. Link powinien wygasać, być unieważniany przy supersession i nie ujawniać nazw innych dostawców, produktów ani wewnętrznego review.
SBOM od dostawców — FAQ
Czy producent może użyć SBOM dostawcy w swoim SBOM?
Może wykorzystać go jako źródło, ale musi kontrolować dopasowanie do dokładnej wersji komponentu i własnego release'u. Import nie powinien bez przeglądu zmieniać inventory ani oceny podatności.
Czy CRA wymaga formatu CycloneDX albo SPDX?
CRA wymaga SBOM w powszechnie używanym i maszynowo czytelnym formacie, obejmującym co najmniej zależności najwyższego poziomu. Rozporządzenie nie wskazuje wyłącznie jednego formatu; CycloneDX i SPDX są praktycznymi formatami wymiany.
Co zrobić, gdy dostawca nie podaje wersji komponentu?
Nie zgaduj na podstawie nazwy pliku lub daty. Oznacz target jako nieustalony, poproś o uzupełnienie i nie uznawaj evidence za aktualne dla konkretnego release'u.
Czy otrzymany SBOM oznacza, że komponent nie ma podatności?
Nie. SBOM jest inventory, a nie wynikiem skanowania ani stanowiskiem o wpływie. Potrzebne są źródła podatności, dopasowanie wersji i human triage w kontekście produktu.
Czy poprawiony SBOM może zastąpić wcześniejszy plik?
Może być następcą, ale nie powinien usuwać historii. Zachowaj pierwotne bajty, checksum, datę, autora lub źródło oraz jawne powiązanie replacementu z poprzednią wersją.
Oficjalne źródła
Podstawa materiału została sprawdzona 1 września 2026.