Checklista för SBOM-kvalitet: så validerar du SBOM:erna från dina leverantörer

SBOM-kvalitetens tre lager

Lager	Fråga	Vad som kontrollerar det	Vad det inte kan säga dig
Giltig	Går filen att tolka, och följer den schemat för det format och den version den anger?	Schemavaliderare	Om något fält är ifyllt med något användbart
Användbar	Finns fälten du behöver, och kan ett verktyg använda dem: identifierare som matchar säkerhetsmeddelanden, licenser, hashvärden, relationer?	Fältkontroller, efterlevnadsprofiler och kvalitetspoäng	Vad som saknas i filen
Fullständig	Listar den allt i programvaran du har fått?	Jämförelse med bygget, eller med en analys av den levererade binärfilen	Inget som bara läser SBOM:en kan svara på det

De flesta mottagande team stannar vid det första lagret. "Filen validerar" är början på kontrollen, inte resultatet. Det tredje lagret är SBOM-fullständighet.

Ramverken på en minut

Nämn ramverket i varje förfrågan och varje återkoppling, så att ribban är en publicerad ribba och inte din åsikt.

• NTIA, The Minimum Elements for a Software Bill of Materials (12 juli 2021). Sju datafält (leverantörens namn, komponentnamn, version, andra unika identifierare, beroenderelation, upphovsperson för SBOM-data, tidsstämpel), stöd för automatisering i SPDX, CycloneDX eller SWID-taggar, och praxis: frekvens, djup, kända okända, distribution och leverans, åtkomstkontroll och hantering av misstag. Hashvärden, licenser, livscykelfas och signaturer listas som rekommenderade, utöver minimikraven.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29 juli 2026, efter ett utkast den 22 augusti 2025). Ersätter NTIA:s element. Skrivet av 18 organisationer från 14 länder, bland dem CISA, NSA, FBI, tyska BSI och japanska METI och NCO. Det har 17 datafält, varav tio är nya: SBOM author signature, data format name, data format version, generation context, tool name, tool version, SBOM version, component hash value, component hash algorithm och component license. "Supplier name" blir "Component Producer" (komponentens producent). Dess praxis är täckning, att uttryckligen markera okänd information, maskinläsbara data, hantering av uppdateringar, frekvens samt distribution och leverans. Dokumentet formulerar varje element med "should" och säger att det inte skapar nya krav; köpare gör det bindande genom att skriva in det i avtal.
• BSI, TR-03183-2 version 2.1.0 (20 augusti 2025), Tyskland. Den striktaste av de tre, skriven med MUST: JSON eller XML, CycloneDX 1.6 eller senare eller SPDX 3.0.1 eller senare, en SBOM per programvaruversion, rekursiv upplösning av beroenden där fullständigheten för varje beroendelista anges, en SHA-512-hash för varje driftsättningsbar komponent, komponentens filnamn, distributionslicenser som SPDX-identifierare, och package URL eller CPE "if it exists". Den säger också att en SBOM inte får innehålla sårbarhetsinformation; den hör hemma i ett VEX-dokument eller ett säkerhetsmeddelande.
• Internationell samordning. A Shared Vision of SBOM for Cybersecurity (3 september 2025) är undertecknad av 18 organisationer från 15 länder. G7:s arbete med SBOM:er gäller AI-system ("A shared G7 vision on SBOM for AI", 2025, och "SBOM for AI – Minimum Elements", maj 2026) och ställer inga krav på SBOM:er från leverantörer av inbyggda system.
• Fordonsindustrin. Auto-ISAC publicerade en SBOM Informational Report den 11 februari 2025.

Checklistan

Så läser du cellerna: Krav betyder att dokumentet säger must. Minimielement betyder att det finns i dokumentets minimilista (NTIA:s baslinje, eller CISA:s "should"-element). Rekommenderat betyder att dokumentet listar det utöver minimikraven. Nämns inte betyder att dokumentet inte ber om det. Hur du testar varje kontroll, och raden att skicka som återkoppling, följer i nästa avsnitt.

Kontroller på SBOM-nivå

Kontroll	Varför det spelar roll	NTIA 2021	CISA 2026	BSI TR-03183-2
1. Går att tolka och validerar mot det angivna schemat	En fil som dina verktyg inte kan läsa är ingen SBOM	Krav: SPDX, CycloneDX eller SWID-taggar	Praxis: maskinläsbar SPDX eller CycloneDX	Krav: JSON eller XML
2. Specifikationsversionen når upp till din lägstanivå	Gamla versioner kan inte bära fält du behöver	Nämns inte	Minimielement: dataformatets namn och version; undvik utfasade versioner	Krav: CycloneDX 1.6+ eller SPDX 3.0.1+
3. SBOM-upphovsperson	Någon står för innehållet	Minimielement: "Author of SBOM Data"	Minimielement: "SBOM Author", organisationen, inte verktyget	Krav: "Creator of the SBOM", e-post eller URL
4. Tidsstämpel	Visar vilken SBOM som är aktuell	Minimielement	Minimielement	Krav; UTC rekommenderas
5. Verktygets namn och version	Visar vad SBOM:en går att lita på att den täcker	Nämns inte	Minimielement	Nämns inte
6. Genereringskontext	En källkodsskanning och en registrering från bygget av samma release skiljer sig åt	Rekommenderat: livscykelfas ("source", "build", "post-build")	Minimielement: "before build", "build" eller "after build"	Inget fält; innehållet måste motsvara det som fanns tillgängligt under bygget
7. SBOM-version eller serienummer	Skiljer en rättelse från originalet	Nämns inte	Minimielement: "SBOM Version"	Krav om formatet har ett sådant: "SBOM-URI"
8. Upphovspersonens signatur	Visar att filen kom oförändrad från leverantören	Rekommenderat: signering uppmuntras	Minimielement: "SBOM Author Signature"	Endast informativt: "ideally" signerad
9. Toppkomponenten motsvarar det du har fått	SBOM:en för fel release är värre än ingen alls	Minimielement: primära komponenter	Minimielement: målkomponenten	Krav: den primära komponenten, roten i trädet

Kontroller på komponentnivå

Kontroll	Varför det spelar roll	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Komponentnamn	Det första som varje matchning använder	Minimielement	Minimielement	Krav; filnamnet om det inte finns något namn
11. Version: inga värden som latest, unknown eller tomma	Säkerhetsmeddelanden gäller versionsintervall	Minimielement	Minimielement; ange om den är okänd	Krav; filens datum om det inte finns någon version
12. Producent eller leverantör	Skiljer två komponenter med samma namn åt och visar vem som rättar felet	Minimielement: "Supplier Name"	Minimielement: "Component Producer"	Krav: "Component creator", e-post eller URL
13. Package URL där ekosystemet har en, CPE där det saknas; båda korrekt formade	Utan en identifierare (package URL, CPE) kan inget matchas mot en sårbarhetsdatabas	Minimielement: "Other Unique Identifiers", som CPE, SWID eller PURL, om de finns	Minimielement: minst en identifierare, som CPE eller PURL; ta med alla	Krav om den finns: CPE eller purl
14. Hashvärde och algoritm, som stämmer med filen du har fått	Bevisar att den här SBOM:en beskriver den här binärfilen	Rekommenderat	Minimielement: hash av den körbara artefakten, med en algoritm som godkänts av en myndighet som NIST	Krav: SHA-512 av den driftsättningsbara komponenten
15. Licens som SPDX-identifierare eller uttryck, inget generellt NOASSERTION	Din licensspecialist bedömer copyleft och andra skyldigheter utifrån den	Rekommenderat	Minimielement; SPDX-identifierare när det går	Krav: distributionslicenser, i första hand SPDX-identifierare
16. Beroenderelationer, och om listan är fullständig	Visar vad som drog in ett sårbart paket, och om du kan lita på luckorna	Minimielement; ange när direkta beroenden är fullständigt listade	Minimielement	Krav, med fullständigheten för varje lista angiven
17. Filnamn	Knyter posten till en fil på enheten	Nämns inte	Nämns inte	Krav
18. Egenskaperna körbar, arkiv och strukturerad	Visar vilken sorts fil varje komponent är	Nämns inte	Nämns inte	Krav

Kontroller av täckning

Kontroll	Varför det spelar roll	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Transitivt djup, inte bara högsta nivån	Den mesta sårbara koden kommer in indirekt	Högsta nivån krav; transitiva rekommenderas	Praxis för täckning: ta med transitiva beroenden; inget minsta djup	Krav: rekursiv upplösning
20. Kända okända angivna	En SBOM som anger sina luckor går att lita på för det den listar	Krav: praxis	Praxis: okänd och undanhållen information markeras	Krav genom fullständighetsangivelsen
21. En SBOM per levererad programvaruversion	Det är versionen du kör som spelar roll	Krav: en ny SBOM för varje bygge eller release	Praxis: frekvens	Krav
22. Rättelser skickas som en ny SBOM	Ett fel som rättas i tysthet går inte att spåra	Praxis: hantering av misstag	Praxis: hantering av uppdateringar	Krav: en uppdaterad SBOM när fel rättas
23. Rimlighet: inga dubbletter, ett antal komponenter som passar produkten, operativsystemets paket med för en Linuxbaserad enhet	Det billigaste sättet att testa fullständigheten	Nämns inte	Praxis för täckning: flera instanser listas var för sig	Flera instanser måste listas var för sig

Så testar du varje kontroll, och vad du säger till leverantören

Kontroll	Så testar du det automatiskt	Återkoppling till leverantören
1, 2. Schema och specifikationsversion	En schemavaliderare för angivet format och version; jämför sedan specVersion (CycloneDX) eller SPDX-versionen med din lägstanivå	"Filen klarar inte schemavalideringen för CycloneDX 1.6 på de angivna sökvägarna. Ta fram den på nytt med en generator och validera den innan du skickar den."
3 till 7. Upphovsperson, tidsstämpel, verktyg, kontext, version	Obligatoriska metadata finns: i CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber och version; i SPDX informationen om hur dokumentet skapades	"SBOM:en anger inte vilket verktyg som tog fram den eller genereringskontexten. Båda är CISA 2026 Minimum Elements."
8. Signatur	En signatur finns och verifieras mot nyckeln som leverantören har publicerat	"Signera SBOM:en, eller skicka en fristående signatur, enligt CISA 2026-elementet SBOM Author Signature."
9. Toppkomponent	Namnet och versionen i metadata.component (CycloneDX) eller det beskrivna rotelementet (SPDX) stämmer med artikelnumret och programvaruversionen du har fått	"Den här SBOM:en beskriver version 5.2.0; vi har fått 5.3.0. Skicka SBOM:en för 5.3.0."
10, 11. Namn och version	Inga tomma namn; inga tomma versioner eller latest eller unknown, om de inte har angetts som okända	"14 komponenter saknar version. Ange den exakta versionen, eller markera den som okänd."
12. Producent	En leverantör, tillverkare eller upphovsperson på varje komponent	"Komponenterna saknar producent, som CISA 2026-elementet Component Producer kräver."
13. Identifierare	Varje purl kan tolkas med ett package URL-bibliotek enligt ECMA-427; varje CPE har giltig CPE 2.3-syntax och finns i NVD:s CPE-ordlista	"Ingen komponent har en package URL eller CPE, så ingen kan matchas mot sårbarhetsdatabaser. Lägg till en purl för varje paket från en pakethanterare."
14. Hashvärden	En SHA-512-post på varje driftsättningsbar komponent; beräkna sha512sum för filen du har fått och jämför	"SBOM:en saknar hashvärden. BSI TR-03183-2 kräver SHA-512 för varje driftsättningsbar komponent."
15. Licenser	Licens-ID:n eller uttryck som går att slå upp i SPDX-licenslistan; räkna NOASSERTION och tomma värden	"92 % av komponenterna har NOASSERTION som licens. Ange SPDX-licensidentifierare."
16. Beroenden	En dependencies-graf (CycloneDX) eller beroenderelationer (SPDX); en angivelse av fullständighet, som CycloneDX compositions med ett aggregate-värde	"SBOM:en är en platt lista. Ta med beroenderelationer och ange om varje lista är fullständig."
17, 18. Filnamn och filegenskaper	De egenskaper som BSI TR-03183-2 definierar för varje format finns med	"Lägg till filnamnet och egenskaperna körbar, arkiv och strukturerad, som BSI TR-03183-2 v2.1.0 kräver."
19 till 23. Täckning	Beroendegrafens djup, upptäckt av dubbletter, antalet komponenter jämfört med liknande produkter, förväntade komponenter per produkttyp	"SBOM:en listar ingen kärna, ingen starthanterare och inga baspaket för en Linuxbaserad display. Skicka SBOM:en för hela avbildningen."

Procentsatserna och antalen i återkopplingsraderna är exempel. Fyll i de verkliga siffrorna, och nämn ramverk och version varje gång.

Vad ett godkänt resultat ändå missar

En fil kan validera, få 9 av 10 poäng och ändå sakna halva produkten. Kvalitetspoäng läser de fält som finns; de kan inte se komponenterna som saknas.

Exempel. En leverantör skickar SBOM:en för en Linuxbaserad display. Den är giltig CycloneDX 1.6, varje komponent har en version, en package URL, en licens och en SHA-512-hash, och beroendegrafen är korrekt formad. Den listar displayapplikationen och 40 bibliotek. Den listar inte Linuxkärnan, starthanteraren eller något baspaket. Varje fältkontroll går igenom. SBOM:en är oanvändbar för CVE:er i kärnan, som en Linuxenhet måste bevakas för, eftersom kärnan inte finns i den.

Så kan ett mottagande team testa fullständigheten:

• Jämför med en binäranalys av den levererade firmwaren. Vissa OEM:er använder den som ersättning för en SBOM tills leverantörens SBOM är tillräckligt bra, och som en korskontroll efteråt.
• Kontrollera förväntade komponenter per produkttyp. En Linuxavbildning har en kärna, ett C-bibliotek och ett init-system; en industriell styrenhet har sina protokollstackar.
• Fråga efter genereringskontexten och verktyget. En källkodsskanning kan inte se vad bygget hämtade.
• Fråga om SBOM:en kom från bygget som producerade programvaran du fick. Det är frågan som avgör det tredje lagret.

Små SBOM:er kan vara helt legitima. En bare metal-ECU med proprietär firmware och en kalibrering från en leverantör kan ärligt ha två komponenter. Godta det när SBOM:en säger det och anger sina kända okända, i stället för att straffa den för storleken.

Verktyg som automatiserar kontrollerna

Kontrollerade på GitHub den 11 november 2026. Inget av dessa repon är arkiverat.

Verktyg	Vad det kontrollerar	Vad det inte gör	Status
CycloneDX CLI	Schemavalidering av CycloneDX 1.0 till 1.7, JSON eller XML; --fail-on-errors för CI	SPDX, fältkvalitet, ramverksprofiler	v0.33.1, juli 2026
sbom-utility	Schemavalidering av CycloneDX 1.2 till 1.7 och SPDX 2.1 till 2.3 i JSON, med egna schemavarianter	SPDX 3, XML, ramverksprofiler	v0.19.2, juni 2026
SPDX tools-java	Verify för SPDX 2.0 till 2.3 och 3.0.1	CycloneDX, ramverksprofiler	v2.0.7, juni 2026
SPDX tools-python	pyspdxtools -i: fullständig validering av SPDX 2.2 och 2.3	Läsa SPDX 3, vars stöd är experimentellt	v0.8.5, mars 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 och 3.0 mot NTIA 2021, CISA FSCT3 och BSI TR-03183-2 v2.1.0; finns också i en webbversion	CycloneDX; CISA 2026 är en öppen förfrågan	v6.0.0, oktober 2026
sbomqs	En score från 0 till 10 för identifiering, proveniens, integritet, fullständighet, licenser, sårbarheter och struktur; compliance-profiler för CISA 2026, NTIA 2021, BSI TR-03183-2 v1.1 till v2.1.0, FSCT v3 och OpenChain Telco	Se komponenter som saknas	v2.1.3, oktober 2026; CISA 2026-profil sedan v2.1.0, rättad i v2.1.2
sbom-scorecard	En viktad poäng för efterlevnad av specifikationen, genereringsinformation samt paketens identifierare, versioner och licenser	Ramverksprofiler	0.0.7, april 2023, den senaste releasen

Hittills kontrollerar bara sbomqs CISA 2026 Minimum Elements. Läs varje verktygs release notes innan du förlitar dig på en profil: i sbomqs 2.1.1 körde CISA 2026-flaggan av misstag kontrollen från 2021. För BSI TR-03183-2 v2.1.0 i sbomqs använder du --bsi-v21 eller --bsi; --bsi-v2 kontrollerar v2.0.0.

Ett minimalt mottagningssteg för en leverantörs CycloneDX-SBOM:

# 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

För SPDX använder du sbomcheck -s spdx3 -c bsi supplier-sbom.json från NTIA Conformance Checker. Läs efterlevnadsrapporten och avvisa filen på de kontroller som ditt krav gör obligatoriska; skicka tillbaka den till leverantören med återkopplingsraderna ovan.

Att skriva in det i leverantörskraven

En checklista som leverantören aldrig har sett är inget krav. Lägg in den i avtalsbilagan:

• Ramverket och versionen: till exempel "BSI TR-03183-2 v2.1.0" eller "CISA 2026 Minimum Elements". Nämn ett; skriv inte "branschstandard".
• Formatet och lägsta specifikationsversion: till exempel CycloneDX 1.6 eller senare, eller SPDX 3.0.1 eller senare, JSON.
• De fält du lägger till utöver det, som SHA-512-hashvärden eller package URL:er för varje paket.
• Leverans: en SBOM per levererad programvaruversion, före eller tillsammans med programvaran.
• Valideringen som leverantören kör innan den skickar, angiven med verktyg och profil.
• Återkopplingen: vem som tar emot den, och hur snabbt en rättad SBOM ska komma.

Leverantörens sida av samma överenskommelse finns i SBOM-guiden för leverantörer. För en programvaruleverantör som svarar på en enstaka förfrågan, se kunders SBOM-förfrågningar.

Att rätta en underkänd SBOM (för leverantörer)

• Handskrivna filer. Använd en generator eller ett SBOM-bibliotek, aldrig en textredigerare.
• Package URL:er saknas. Generera dem från pakethanteraren eller bygget, inte för hand. En inskriven purl är en gissad purl.
• Licenser saknas. Ta den angivna licensen från paketets metadata, som en SPDX-identifierare.
• Inga hashvärden. Beräkna dem för de filer du faktiskt levererar, i slutet av bygget.
• Fel release. Ta fram SBOM:en i releasebygget och namnge den efter versionen.
• Bara högsta nivån. Använd en metod som löser upp transitiva beroenden.

Det mest tillförlitliga sättet att rätta fullständighet och identifierare samtidigt är att ta fram SBOM:en från bygget som producerade den levererade programvaran. Se SBOM:er från bygget och bästa praxis för SBOM.

Var bra SBOM:er kommer ifrån, och var CRACI passar in

För leverantörer som bygger på GitHub Actions ersätter CRACI de GitHub-hostade runnerna och registrerar SBOM:en under bygget, så att den listar det som bygget faktiskt drog in.

• Varje paket med en package URL, och varje komponent med sin angivna licens.
• Transitiva beroenden, på varje djup som bygget nådde.
• En fullständighetsstatus för varje jobb, som besvarar frågan om kända okända per bygge: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.
• Exporteras som CycloneDX eller SPDX; SBOM-API:t returnerar CycloneDX 1.7 JSON.

För en hel utvecklingsorganisation, se att standardisera SBOM-genereringen, och för inbyggd Linux, varför skannrar missar det som finns i Yocto-byggen.

För OEM:er kan SBOM:er från tredje part läggas till i CRACI, så att komponenter du köper in bevakas för nya sårbarheter tillsammans med dina egna byggen. Se verktyg för SBOM-hantering för hur det står sig.

När CRACI inte är svaret

• Att validera och poängsätta SBOM:erna du tar emot. CRACI erbjuder ingen SBOM-validerare eller kvalitetspoäng. Använd verktygen ovan.
• Leverantörer utan CI, eller vars kod genereras av modellbaserade verktyg utan att några paket hämtas. En byggregistrering tillför lite; en validerad SBOM från ett generatorbibliotek är det realistiska svaret.
• Firmware som du bara får som binärfil. Binäranalys svarar på det.
• Signerade SBOM:er, CISA 2026:s author signature. CRACI signerar inte SBOM:er.

SBOM-kvalitet och validering: vanliga frågor

Hur kontrollerar jag kvaliteten på en SBOM som en leverantör har skickat?

Testa tre lager. Validera filen mot dess schema, kontrollera fälten mot ett namngivet ramverk som BSI TR-03183-2 eller CISA 2026 Minimum Elements, och testa sedan fullständigheten: jämför med en binäranalys av det du har fått och kontrollera att komponenterna som produkttypen måste innehålla finns med.

Vilka fält måste en SBOM innehålla?

Det beror på vilket ramverk du anger. CISA:s Minimum Elements från 2026 listar 17 fält, bland dem upphovsperson, tidsstämpel, verktyg, genereringskontext och för varje komponent namn, version, producent, identifierare, hash och licens. BSI TR-03183-2 lägger till en SHA-512-hash, filnamnet och filegenskaper, och kräver dem.

Vad ändrades mellan NTIA:s minimielement och CISA:s Minimum Elements från 2026?

CISA:s lista från 2026 ersätter NTIA:s sju fält med 17. Nya är upphovspersonens signatur, dataformatets namn och version, genereringskontext, verktygets namn och version, SBOM-version, komponentens hashvärde och algoritm samt komponentens licens. Supplier name blev Component Producer, och djup blev täckning.

Vad kräver BSI TR-03183-2 av en SBOM?

Version 2.1.0 kräver CycloneDX 1.6+ eller SPDX 3.0.1+ i JSON eller XML, en SBOM per programvaruversion, rekursiva beroenden med fullständigheten angiven, och för varje komponent upphovsman, namn, version, filnamn, licenser, SHA-512-hash och filegenskaper, med en package URL eller CPE om en sådan finns.

Behöver en SBOM hashvärden? Vilken algoritm?

NTIA rekommenderade dem; CISA 2026 gör hashvärdet till ett minimielement med en algoritm som godkänts av en myndighet som NIST; BSI TR-03183-2 kräver SHA-512 för varje driftsättningsbar komponent. Be om SHA-512 och jämför med filen du har fått.

Behöver jag både en CPE och en PURL?

Inte alltid. Be om en package URL där ekosystemet har en, och en CPE där det saknas, som för många kommersiella eller inbyggda komponenter. CISA 2026 ber om minst en identifierare och alla som är kända; BSI kräver var och en om den finns.

Hur validerar jag en CycloneDX- eller SPDX-fil?

För CycloneDX: cyclonedx-cli validate med --fail-on-errors, eller sbom-utility. För SPDX: kommandot Verify i SPDX tools-java, eller pyspdxtools för SPDX 2.2 och 2.3. Kör sedan en ramverksprofil med sbomqs eller SPDX NTIA Conformance Checker.

Vad är en bra kvalitetspoäng för en SBOM?

Det finns ingen standardgräns och inget riktmärke vi skulle vilja citera. En poäng mäter vilka fält som finns, inte fullständigheten: en fil kan få 9 av 10 och sakna halva produkten. Sätt i stället godkännandekriterier per kontroll i ditt leverantörskrav, och följ poängen som en trend.