Lista kontrolna jakości SBOM: jak walidować SBOM-y od Państwa dostawców

Trzy warstwy jakości SBOM

Warstwa	Pytanie	Co to sprawdza	Czego nie powie
Poprawny	Czy plik się parsuje i czy jest zgodny ze schematem formatu i wersji, które deklaruje?	Walidatory schematu	Czy którekolwiek pole zawiera coś przydatnego
Użyteczny	Czy są potrzebne pola i czy narzędzie może z nich skorzystać: identyfikatory pasujące do biuletynów, licencje, skróty, relacje?	Kontrole pól, profile zgodności i oceny jakości	Czego w pliku brakuje
Kompletny	Czy wymienia wszystko, co jest w otrzymanym oprogramowaniu?	Porównanie z buildem lub z analizą dostarczonego pliku binarnego	Nic, co czyta wyłącznie SBOM, nie odpowie na to pytanie

Większość zespołów odbiorczych zatrzymuje się na pierwszej warstwie. „Plik przechodzi walidację” to początek kontroli, nie jej wynik. Trzecia warstwa to kompletność SBOM.

Ramy w minutę

Proszę wskazywać ramę w każdym wymaganiu i każdej informacji zwrotnej, aby poprzeczka była opublikowana, a nie wynikała z Państwa opinii.

• NTIA, The Minimum Elements for a Software Bill of Materials (12 lipca 2021). Siedem pól danych (nazwa dostawcy, nazwa komponentu, wersja, inne unikalne identyfikatory, relacja zależności, autor danych SBOM, znacznik czasu), obsługa automatyzacji w SPDX, CycloneDX lub tagach SWID oraz praktyki: częstotliwość, głębokość, znane niewiadome, dystrybucja i dostarczanie, kontrola dostępu, obsługa błędów. Skróty, licencje, faza cyklu życia i podpisy są wymienione jako zalecane, ponad minimum.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29 lipca 2026, po projekcie z 22 sierpnia 2025). Zastępuje elementy NTIA. Opracowany przez 18 organizacji z 14 krajów, w tym CISA, NSA, FBI, niemiecki BSI oraz japońskie METI i NCO. Zawiera 17 pól danych, z czego dziesięć nowych: podpis autora SBOM, nazwa formatu danych, wersja formatu danych, kontekst generowania, nazwa narzędzia, wersja narzędzia, wersja SBOM, wartość skrótu komponentu, algorytm skrótu komponentu i licencja komponentu. „Supplier Name” staje się „Component Producer”. Praktyki to pokrycie, wyraźne oznaczanie nieznanych informacji, dane przetwarzalne maszynowo, obsługa aktualizacji, częstotliwość oraz dystrybucja i dostarczanie. Dokument formułuje każdy element ze słowem „should” i stwierdza, że nie tworzy nowych wymagań; wiążącym czynią go kupujący, wpisując go do umów.
• BSI, TR-03183-2 w wersji 2.1.0 (20 sierpnia 2025), Niemcy. Najsurowszy z trzech, napisany z użyciem MUST: JSON lub XML, CycloneDX 1.6 lub nowszy albo SPDX 3.0.1 lub nowszy, jeden SBOM na wersję oprogramowania, rekurencyjne rozwiązywanie zależności z podaniem kompletności każdej listy zależności, skrót SHA-512 każdego wdrażanego komponentu, nazwa pliku komponentu, licencje dystrybucyjne jako identyfikatory SPDX oraz package URL lub CPE, „if it exists”. Stwierdza też, że SBOM nie może zawierać informacji o podatnościach; należą one do dokumentu VEX lub biuletynu.
• Uzgodnienia międzynarodowe. A Shared Vision of SBOM for Cybersecurity (3 września 2025) podpisało 18 organizacji z 15 krajów. Prace G7 nad SBOM dotyczą systemów AI („A shared G7 vision on SBOM for AI”, 2025, oraz „SBOM for AI – Minimum Elements”, maj 2026) i nie stawiają wymagań wobec SBOM-ów wbudowanych od dostawców.
• Motoryzacja. Auto-ISAC opublikował SBOM Informational Report 11 lutego 2025.

Lista kontrolna

Jak czytać komórki: Wymagane oznacza, że dokument mówi „must”. Element minimalny oznacza, że jest na liście minimalnej tego dokumentu (podstawa NTIA lub elementy „should” CISA). Zalecane oznacza, że dokument wymienia to ponad minimum. Nie wymieniono oznacza, że dokument tego nie wymaga. Jak testować każdą kontrolę i jaką informację zwrotną wysłać, opisuje następna sekcja.

Kontrole na poziomie SBOM

Kontrola	Dlaczego to ważne	NTIA 2021	CISA 2026	BSI TR-03183-2
1. Parsuje się i przechodzi walidację względem zadeklarowanego schematu	Plik, którego Państwa narzędzia nie odczytają, nie jest SBOM-em	Wymagane: SPDX, CycloneDX lub tagi SWID	Praktyka: SPDX lub CycloneDX przetwarzalne maszynowo	Wymagane: JSON lub XML
2. Wersja specyfikacji spełnia Państwa próg	Stare wersje nie mieszczą potrzebnych pól	Nie wymieniono	Element minimalny: nazwa i wersja formatu danych; unikać przestarzałych wersji	Wymagane: CycloneDX 1.6+ lub SPDX 3.0.1+
3. Autor SBOM	Ktoś odpowiada za treść	Element minimalny: „Author of SBOM Data”	Element minimalny: „SBOM Author”, organizacja, nie narzędzie	Wymagane: „Creator of the SBOM”, e-mail lub URL
4. Znacznik czasu	Pokazuje, który SBOM jest aktualny	Element minimalny	Element minimalny	Wymagane; zalecany UTC
5. Nazwa i wersja narzędzia	Pokazuje, co SBOM może wiarygodnie obejmować	Nie wymieniono	Element minimalny	Nie wymieniono
6. Kontekst generowania	Skan źródeł i zapis buildu tego samego wydania się różnią	Zalecane: faza cyklu życia („source”, „build”, „post-build”)	Element minimalny: „before build”, „build” lub „after build”	Brak pola; treść musi odpowiadać temu, co było dostępne podczas buildu
7. Wersja lub numer seryjny SBOM	Odróżnia poprawkę od oryginału	Nie wymieniono	Element minimalny: „SBOM Version”	Wymagane, jeśli format je ma: „SBOM-URI”
8. Podpis autora	Pokazuje, że plik przyszedł od dostawcy bez zmian	Zalecane: podpisywanie jest zachęcane	Element minimalny: „SBOM Author Signature”	Wyłącznie informacyjnie: „ideally” podpisany
9. Komponent najwyższego poziomu odpowiada temu, co Państwo otrzymali	SBOM niewłaściwego wydania jest gorszy niż żaden	Element minimalny: komponenty główne	Element minimalny: komponent docelowy	Wymagane: komponent główny, korzeń drzewa

Kontrole na poziomie komponentów

Kontrola	Dlaczego to ważne	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Nazwa komponentu	Pierwsza rzecz, której używa każde dopasowanie	Element minimalny	Element minimalny	Wymagane; nazwa pliku, jeśli brak nazwy
11. Wersja: bez wartości latest, unknown ani pustych	Biuletyny dotyczą zakresów wersji	Element minimalny	Element minimalny; podać, jeśli nieznana	Wymagane; data pliku, jeśli brak wersji
12. Producent lub dostawca	Odróżnia dwa komponenty o tej samej nazwie i mówi, kto je naprawia	Element minimalny: „Supplier Name”	Element minimalny: „Component Producer”	Wymagane: „Component creator”, e-mail lub URL
13. Package URL wszędzie, gdzie ekosystem go ma, CPE tam, gdzie nie; oba poprawnie zbudowane	Bez identyfikatora (package URL, CPE) niczego nie da się dopasować do bazy podatności	Element minimalny: „Other Unique Identifiers”, np. CPE, SWID lub PURL, jeśli istnieją	Element minimalny: co najmniej jeden identyfikator, np. CPE lub PURL; podać wszystkie	Wymagane, jeśli istnieje: CPE lub purl
14. Wartość i algorytm skrótu, zgodne z otrzymanym plikiem	Dowodzi, że ten SBOM opisuje ten plik binarny	Zalecane	Element minimalny: skrót artefaktu wykonywalnego, z algorytmem zatwierdzonym przez organ taki jak NIST	Wymagane: SHA-512 wdrażanego komponentu
15. Licencja jako identyfikatory lub wyrażenia SPDX, bez masowego NOASSERTION	Na tej podstawie Państwa specjalista ds. licencji ocenia copyleft i inne obowiązki	Zalecane	Element minimalny; identyfikatory SPDX, gdy to możliwe	Wymagane: licencje dystrybucyjne, w pierwszej kolejności identyfikatory SPDX
16. Relacje zależności i to, czy lista jest kompletna	Pokazuje, co wciągnęło podatny pakiet, i czy można ufać lukom	Element minimalny; podać, gdy zależności bezpośrednie są wymienione w całości	Element minimalny	Wymagane, z podaniem kompletności każdej listy
17. Nazwa pliku	Wiąże wpis z plikiem na urządzeniu	Nie wymieniono	Nie wymieniono	Wymagane
18. Właściwości: plik wykonywalny, archiwum, struktura	Mówi, jakiego rodzaju plikiem jest każdy komponent	Nie wymieniono	Nie wymieniono	Wymagane

Kontrole pokrycia

Kontrola	Dlaczego to ważne	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Głębokość przechodnia, nie tylko najwyższy poziom	Większość podatnego kodu trafia do produktu pośrednio	Najwyższy poziom wymagany; przechodnie zalecane	Praktyka pokrycia: uwzględnić zależności przechodnie; bez minimalnej głębokości	Wymagane: rozwiązywanie rekurencyjne
20. Podane znane niewiadome	SBOM, który podaje swoje luki, jest wiarygodny w tym, co wymienia	Wymagana praktyka	Praktyka: oznaczone informacje nieznane i zatajone	Wymagane poprzez deklarację kompletności
21. Jeden SBOM na dostarczoną wersję oprogramowania	Liczy się wersja, którą Państwo uruchamiają	Wymagane: nowy SBOM dla każdego buildu lub wydania	Praktyka: częstotliwość	Wymagane
22. Poprawki wysyłane jako nowy SBOM	Błędu naprawionego po cichu nie da się prześledzić	Praktyka: obsługa błędów	Praktyka: obsługa aktualizacji	Wymagane: zaktualizowany SBOM po poprawieniu błędów
23. Wiarygodność: brak duplikatów, liczba komponentów pasująca do produktu, pakiety systemu operacyjnego obecne dla urządzenia z Linuxem	Najtańszy test kompletności	Nie wymieniono	Praktyka pokrycia: wiele instancji wymienionych osobno	Wiele instancji musi być wymienionych osobno

Jak testować każdą kontrolę i co przekazać dostawcy

Kontrola	Jak ją przetestować automatycznie	Informacja zwrotna dla dostawcy
1, 2. Schemat i wersja specyfikacji	Walidator schematu dla zadeklarowanego formatu i wersji; następnie porównanie specVersion (CycloneDX) lub wersji SPDX z Państwa progiem	„Plik nie przechodzi walidacji schematu CycloneDX 1.6 w wymienionych ścieżkach. Prosimy wygenerować go ponownie generatorem i zwalidować przed wysłaniem.”
3 do 7. Autor, znacznik czasu, narzędzie, kontekst, wersja	Obecne wymagane metadane: w CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber i version; w SPDX informacje o utworzeniu	„SBOM nie podaje narzędzia, które go utworzyło, ani kontekstu generowania. Oba są Minimum Elements CISA 2026.”
8. Podpis	Podpis jest obecny i weryfikuje się kluczem opublikowanym przez dostawcę	„Prosimy podpisać SBOM lub przesłać podpis odłączony, zgodnie z elementem CISA 2026 SBOM Author Signature.”
9. Komponent najwyższego poziomu	Nazwa i wersja metadata.component (CycloneDX) lub opisanego elementu głównego (SPDX) odpowiadają numerowi części i wersji oprogramowania, które Państwo otrzymali	„Ten SBOM opisuje wersję 5.2.0; otrzymaliśmy 5.3.0. Prosimy o SBOM dla 5.3.0.”
10, 11. Nazwa i wersja	Brak pustych nazw; brak pustych wersji oraz wersji latest lub unknown, chyba że zadeklarowano je jako nieznane	„14 komponentów nie ma wersji. Prosimy podać dokładną wersję lub oznaczyć ją jako nieznaną.”
12. Producent	Dostawca, producent lub autor przy każdym komponencie	„Komponenty nie mają producenta, o którego prosi element CISA 2026 Component Producer.”
13. Identyfikatory	Każdy purl parsuje się biblioteką package URL zgodną z ECMA-427; każdy CPE ma poprawną składnię CPE 2.3 i istnieje w słowniku CPE NVD	„Żaden komponent nie ma package URL ani CPE, więc żadnego nie można dopasować do baz podatności. Prosimy dodać purl dla każdego pakietu z menedżera pakietów.”
14. Skróty	Wpis SHA-512 przy każdym wdrażanym komponencie; obliczyć sha512sum otrzymanego pliku i porównać	„SBOM nie zawiera skrótów. BSI TR-03183-2 wymaga SHA-512 każdego wdrażanego komponentu.”
15. Licencje	Identyfikatory lub wyrażenia licencji, które rozwiązują się na liście licencji SPDX; policzyć NOASSERTION i puste wartości	„92% komponentów ma NOASSERTION jako licencję. Prosimy podać identyfikatory licencji SPDX.”
16. Zależności	Graf dependencies (CycloneDX) lub relacje zależności (SPDX); deklaracja kompletności, np. CycloneDX compositions z wartością aggregate	„SBOM jest płaską listą. Prosimy uwzględnić relacje zależności i podać, czy każda lista jest kompletna.”
17, 18. Nazwa pliku i właściwości pliku	Obecne są właściwości, które BSI TR-03183-2 definiuje dla każdego formatu	„Prosimy dodać nazwę pliku oraz właściwości: plik wykonywalny, archiwum i struktura, zgodnie z wymaganiami BSI TR-03183-2 v2.1.0.”
19 do 23. Pokrycie	Głębokość grafu zależności, wykrywanie duplikatów, liczba komponentów w porównaniu z podobnymi produktami, oczekiwane komponenty według typu produktu	„SBOM nie wymienia jądra, bootloadera ani pakietów systemu bazowego dla wyświetlacza opartego na Linuxie. Prosimy o SBOM całego obrazu.”

Wartości procentowe i liczby w informacjach zwrotnych są przykładowe. Proszę wpisać rzeczywiste liczby i za każdym razem wskazać ramę i jej wersję.

Czego nie wychwyci nawet dobry wynik

Plik może przejść walidację, uzyskać 9 na 10 punktów i wciąż pomijać połowę produktu. Oceny jakości czytają pola, które są; nie widzą komponentów, których brakuje.

Przykład. Dostawca wysyła SBOM wyświetlacza opartego na Linuxie. To poprawny CycloneDX 1.6, każdy komponent ma wersję, package URL, licencję i skrót SHA-512, a graf zależności jest poprawnie zbudowany. Wymienia aplikację wyświetlacza i 40 bibliotek. Nie wymienia jądra Linux, bootloadera ani żadnego pakietu systemu bazowego. Każda kontrola pól przechodzi. SBOM jest bezużyteczny w odniesieniu do CVE jądra, pod kątem których urządzenie z Linuxem trzeba monitorować, bo jądra w nim nie ma.

Jak zespół odbiorczy może sprawdzić kompletność:

• Porównać z analizą binarną dostarczonego firmware. Niektórzy OEM-owie używają jej jako zastępczego SBOM, dopóki SBOM dostawcy nie jest wystarczająco dobry, a potem jako kontroli krzyżowej.
• Sprawdzić oczekiwane komponenty według typu produktu. Obraz Linuxa ma jądro, bibliotekę C i system init; sterownik przemysłowy ma swoje stosy protokołów.
• Zapytać o kontekst generowania i narzędzie. Skan źródeł nie widzi tego, co pobrał build.
• Zapytać, czy SBOM pochodzi z buildu, który wytworzył otrzymane oprogramowanie. To pytanie rozstrzyga o trzeciej warstwie.

Małe SBOM-y mogą być uzasadnione. ECU typu bare-metal z własnościowym firmware i kalibracją dostawcy może uczciwie mieć dwa komponenty. Proszę to zaakceptować, gdy SBOM to mówi i podaje swoje znane niewiadome, zamiast karać go za rozmiar.

Narzędzia automatyzujące kontrole

Sprawdzono na GitHubie 11 listopada 2026. Żadne z tych repozytoriów nie jest zarchiwizowane.

Narzędzie	Co sprawdza	Czego nie sprawdza	Stan
CycloneDX CLI	Walidacja schematu CycloneDX 1.0 do 1.7, JSON lub XML; --fail-on-errors dla CI	SPDX, jakość pól, profile ram	v0.33.1, lipiec 2026
sbom-utility	Walidacja schematu CycloneDX 1.2 do 1.7 i SPDX 2.1 do 2.3 JSON, z własnymi wariantami schematu	SPDX 3, XML, profile ram	v0.19.2, czerwiec 2026
SPDX tools-java	Verify dla SPDX 2.0 do 2.3 i 3.0.1	CycloneDX, profile ram	v2.0.7, czerwiec 2026
SPDX tools-python	pyspdxtools -i: pełna walidacja SPDX 2.2 i 2.3	Odczyt SPDX 3, którego obsługa jest eksperymentalna	v0.8.5, marzec 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 i 3.0 względem NTIA 2021, CISA FSCT3 i BSI TR-03183-2 v2.1.0; także wersja webowa	CycloneDX; CISA 2026 to otwarte zgłoszenie	v6.0.0, październik 2026
sbomqs	score od 0 do 10 obejmujący identyfikację, pochodzenie, integralność, kompletność, licencjonowanie, podatności i strukturę; profile compliance dla CISA 2026, NTIA 2021, BSI TR-03183-2 v1.1 do v2.1.0, FSCT v3 i OpenChain Telco	Wykrywanie brakujących komponentów	v2.1.3, październik 2026; profil CISA 2026 od v2.1.0, poprawiony w v2.1.2
sbom-scorecard	Ważona ocena zgodności ze specyfikacją, informacji o generowaniu oraz identyfikatorów, wersji i licencji pakietów	Profile ram	0.0.7, kwiecień 2023, ostatnie wydanie

Na razie tylko sbomqs sprawdza Minimum Elements CISA 2026. Przed oparciem się na profilu proszę przeczytać informacje o wydaniu każdego narzędzia: w sbomqs 2.1.1 flaga CISA 2026 przez pomyłkę uruchamiała kontrolę z 2021 roku. Dla BSI TR-03183-2 v2.1.0 w sbomqs należy użyć --bsi-v21 lub --bsi; --bsi-v2 sprawdza v2.0.0.

Minimalny krok przyjęcia SBOM CycloneDX od dostawcy:

# 1. Valid: fail the intake on schema errors
cyclonedx-cli validate --input-file supplier-sbom.json --input-format json --fail-on-errors

# 2. Usable: run the profile your requirement names
sbomqs compliance --bsi-v21 supplier-sbom.json
sbomqs compliance --ntia supplier-sbom.json   # CISA 2026 Minimum Elements

# 3. Track field quality over time
sbomqs score supplier-sbom.json

# 4. The hash in the SBOM matches the file you received
sha512sum firmware-5.3.0.bin

Dla SPDX proszę użyć sbomcheck -s spdx3 -c bsi supplier-sbom.json z NTIA Conformance Checker. Proszę przeczytać raport zgodności i odrzucić plik przy kontrolach, które Państwa wymaganie czyni obowiązkowymi, a następnie odesłać go dostawcy z powyższymi informacjami zwrotnymi.

Wpisanie tego do wymagań wobec dostawców

Lista kontrolna, której dostawca nigdy nie widział, nie jest wymaganiem. Proszę umieścić ją w załączniku do umowy:

• Rama i wersja: na przykład „BSI TR-03183-2 v2.1.0” lub „CISA 2026 Minimum Elements”. Proszę wskazać jedną; nie pisać „standard branżowy”.
• Format i minimalna wersja specyfikacji: na przykład CycloneDX 1.6 lub nowszy albo SPDX 3.0.1 lub nowszy, JSON.
• Pola, których wymagają Państwo dodatkowo, np. skróty SHA-512 lub package URL dla każdego pakietu.
• Dostarczanie: jeden SBOM na dostarczoną wersję oprogramowania, przed oprogramowaniem lub razem z nim.
• Walidacja, którą dostawca wykonuje przed wysłaniem, wskazana z nazwy narzędzia i profilu.
• Pętla informacji zwrotnej: kto otrzymuje informację zwrotną i w jakim terminie należy dostarczyć poprawiony SBOM.

Strona dostawcy w tej samej umowie jest opisana w przewodniku SBOM dla dostawców. Dla dostawcy oprogramowania odpowiadającego na jednorazową prośbę: zob. prośby klientów o SBOM.

Naprawa SBOM, który nie przeszedł kontroli (dla dostawców)

• Pliki pisane ręcznie. Proszę używać generatora lub biblioteki SBOM, nigdy edytora tekstu.
• Brakujące package URL. Proszę generować je z menedżera pakietów lub z buildu, nie ręcznie. Wpisany ręcznie purl to purl zgadnięty.
• Brakujące licencje. Proszę pobrać zadeklarowaną licencję z metadanych pakietu, jako identyfikator SPDX.
• Brak skrótów. Proszę obliczać je dla plików faktycznie dostarczanych, na końcu buildu.
• Niewłaściwe wydanie. Proszę generować SBOM w buildzie wydania i nazywać go według wersji.
• Tylko najwyższy poziom. Proszę użyć metody, która rozwiązuje zależności przechodnie.

Najpewniejszy sposób, by jednocześnie naprawić kompletność i identyfikatory, to generowanie SBOM z buildu, który wytworzył dostarczone oprogramowanie. Zob. SBOM-y z czasu buildu i dobre praktyki SBOM.

Skąd biorą się dobre SBOM-y i gdzie pasuje CRACI

Dla dostawców, którzy budują w GitHub Actions, CRACI zastępuje runnery hostowane przez GitHub i rejestruje SBOM podczas buildu, więc wymienia on to, co build faktycznie pobrał.

• Każdy pakiet z package URL i każdy komponent z zadeklarowaną licencją.
• Zależności przechodnie, na każdym poziomie, do którego dotarł build.
• Stan kompletności dla każdego zadania, który odpowiada na pytanie o znane niewiadome dla każdego buildu: Complete, Complete with connections, Incomplete, Unavailable lub Not recorded.
• Eksport jako CycloneDX lub SPDX; API SBOM zwraca CycloneDX 1.7 JSON.

Dla całej organizacji inżynierskiej zob. standaryzacja generowania SBOM, a dla wbudowanego Linuxa dlaczego skanery pomijają to, co jest w buildach Yocto.

Dla OEM-ów: SBOM-y stron trzecich można dodać do CRACI, aby kupowane komponenty były monitorowane pod kątem nowych podatności razem z Państwa własnymi buildami. Porównanie znajdą Państwo w narzędziach do zarządzania SBOM.

Kiedy CRACI nie jest odpowiedzią

• Walidacja i ocena otrzymywanych SBOM-ów. CRACI nie oferuje walidatora SBOM ani oceny jakości. Proszę użyć powyższych narzędzi.
• Dostawcy bez CI lub tacy, których kod jest generowany przez narzędzia modelowe bez pobierania pakietów. Rejestrator buildu niewiele tu wnosi; realistyczną odpowiedzią jest zwalidowany SBOM z biblioteki generatora.
• Firmware otrzymywany wyłącznie jako plik binarny. Na to odpowiada analiza binarna.
• Podpisane SBOM-y, podpis autora z CISA 2026. CRACI nie podpisuje SBOM-ów.

Jakość i walidacja SBOM: najczęściej zadawane pytania

Jak sprawdzić jakość SBOM, który przysłał mi dostawca?

Proszę przetestować trzy warstwy. Zwalidować plik względem schematu, sprawdzić pola względem wskazanej ramy, takiej jak BSI TR-03183-2 lub CISA 2026 Minimum Elements, a następnie zbadać kompletność: porównać z analizą binarną otrzymanego oprogramowania i sprawdzić komponenty, które musi zawierać dany typ produktu.

Jakie pola musi zawierać SBOM?

To zależy od wskazanej ramy. Minimum Elements CISA z 2026 roku wymieniają 17 pól, w tym autora, znacznik czasu, narzędzie, kontekst generowania, a dla każdego komponentu nazwę, wersję, producenta, identyfikatory, skrót i licencję. BSI TR-03183-2 dodaje skrót SHA-512, nazwę pliku i właściwości pliku, i ich wymaga.

Co się zmieniło między minimalnymi elementami NTIA a Minimum Elements CISA z 2026 roku?

Lista CISA z 2026 roku zastępuje siedem pól NTIA siedemnastoma. Nowe są: podpis autora, nazwa i wersja formatu danych, kontekst generowania, nazwa i wersja narzędzia, wersja SBOM, wartość i algorytm skrótu komponentu oraz licencja komponentu. Supplier Name stał się Component Producer, a głębokość stała się pokryciem.

Czego BSI TR-03183-2 wymaga w SBOM?

Wersja 2.1.0 wymaga CycloneDX 1.6+ lub SPDX 3.0.1+ w JSON lub XML, jednego SBOM na wersję oprogramowania, rekurencyjnych zależności z podaną kompletnością, a dla każdego komponentu twórcy, nazwy, wersji, nazwy pliku, licencji, skrótu SHA-512 i właściwości pliku, z package URL lub CPE, jeśli istnieje.

Czy SBOM potrzebuje skrótów? Jakiego algorytmu?

NTIA je zalecała; CISA 2026 czyni skrót elementem minimalnym, z algorytmem zatwierdzonym przez organ taki jak NIST; BSI TR-03183-2 wymaga SHA-512 każdego wdrażanego komponentu. Proszę żądać SHA-512 i porównywać go z otrzymanym plikiem.

Czy potrzebuję zarówno CPE, jak i PURL?

Nie zawsze. Proszę żądać package URL wszędzie, gdzie ekosystem go ma, a CPE tam, gdzie nie, jak w przypadku wielu komponentów komercyjnych lub wbudowanych. CISA 2026 wymaga co najmniej jednego identyfikatora i wszystkich znanych; BSI wymaga każdego, jeśli istnieje.

Jak zwalidować plik CycloneDX lub SPDX?

Dla CycloneDX: cyclonedx-cli validate z --fail-on-errors lub sbom-utility. Dla SPDX: polecenie Verify z SPDX tools-java lub pyspdxtools dla SPDX 2.2 i 2.3. Następnie proszę uruchomić profil ramy w sbomqs lub SPDX NTIA Conformance Checker.

Jaki wynik jakości SBOM jest dobry?

Nie ma standardowego progu ani benchmarku, który moglibyśmy przytoczyć. Wynik mierzy obecne pola, a nie kompletność: plik może uzyskać 9 na 10 i pomijać połowę produktu. Zamiast tego proszę ustalić kryteria zaliczenia dla każdej kontroli w wymaganiu wobec dostawców i śledzić wynik jako trend.