Sjekkliste for SBOM-kvalitet: slik validerer du SBOM-ene leverandørene sender

De tre lagene i SBOM-kvalitet

Lag	Spørsmål	Hva som sjekker det	Hva det ikke kan fortelle deg
Gyldig	Kan filen parses, og følger den skjemaet for formatet og versjonen den oppgir?	Skjemavalidatorer	Om noe felt er fylt med noe nyttig
Brukbar	Finnes feltene du trenger, og kan et verktøy bruke dem: identifikatorer som matcher advisories, lisenser, hasher, relasjoner?	Feltsjekker, samsvarsprofiler og kvalitetspoeng	Hva som mangler i filen
Fullstendig	Lister den opp alt i programvaren du mottok?	Sammenligning med bygget, eller med en analyse av den leverte binærfilen	Ingenting som bare leser SBOM-en, kan svare på dette

De fleste mottakende team stopper ved det første laget. «Filen validerer» er starten på sjekken, ikke resultatet. Det tredje laget er SBOM-fullstendighet.

Rammeverkene på ett minutt

Nevn rammeverket i hver forespørsel og hver tilbakemelding, så listen er en publisert standard og ikke din mening.

• NTIA, The Minimum Elements for a Software Bill of Materials (12. juli 2021). Sju datafelt (leverandørnavn, komponentnavn, versjon, andre unike identifikatorer, avhengighetsrelasjon, forfatter av SBOM-dataene, tidsstempel), støtte for automatisering i SPDX, CycloneDX eller SWID-tagger, og praksiser: frekvens, dybde, kjente ukjente, distribusjon og levering, tilgangskontroll, håndtering av feil. Hasher, lisenser, livssyklusfase og signaturer er oppført som anbefalt, utover minimum.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29. juli 2026, etter et utkast 22. august 2025). Erstatter NTIA-elementene. Skrevet av 18 organisasjoner fra 14 land, blant dem CISA, NSA, FBI, tyske BSI og japanske METI og NCO. Den har 17 datafelt, ti av dem nye: signatur fra SBOM-forfatteren, navn på dataformatet, versjon av dataformatet, genereringskontekst, verktøynavn, verktøyversjon, SBOM-versjon, hashverdi for komponenten, hashalgoritme for komponenten og komponentens lisens. «Supplier Name» blir «Component Producer». Praksisene er dekning, eksplisitt markering av ukjent informasjon, maskinlesbare data, håndtering av oppdateringer, frekvens samt distribusjon og levering. Dokumentet formulerer hvert element med «should» og sier at det ikke skaper nye krav; kjøpere gjør det bindende ved å skrive det inn i kontrakter.
• BSI, TR-03183-2 versjon 2.1.0 (20. august 2025), Tyskland. Den strengeste av de tre, skrevet med MUST: JSON eller XML, CycloneDX 1.6 eller nyere eller SPDX 3.0.1 eller nyere, én SBOM per programvareversjon, rekursiv oppløsning av avhengigheter med fullstendigheten av hver avhengighetsliste oppgitt, en SHA-512-hash av hver komponent som kan rulles ut, komponentens filnavn, distribusjonslisenser som SPDX-identifikatorer, og package URL eller CPE «if it exists». Den sier også at en SBOM ikke skal inneholde sårbarhetsinformasjon; den hører hjemme i et VEX-dokument eller en advisory.
• Internasjonal samordning. A Shared Vision of SBOM for Cybersecurity (3. september 2025) er signert av 18 organisasjoner fra 15 land. G7-arbeidet med SBOM-er handler om KI-systemer («A shared G7 vision on SBOM for AI», 2025, og «SBOM for AI – Minimum Elements», mai 2026) og stiller ingen krav til innebygde SBOM-er fra leverandører.
• Bilindustrien. Auto-ISAC publiserte en SBOM Informational Report 11. februar 2025.

Sjekklisten

Slik leser du cellene: Påkrevd betyr at dokumentet sier «must». Minimumselement betyr at det står i dokumentets minimumsliste (NTIAs grunnlinje, eller CISAs «should»-elementer). Anbefalt betyr at dokumentet nevner det utover minimum. Ikke nevnt betyr at dokumentet ikke ber om det. Hvordan du tester hver sjekk, og tilbakemeldingen du sender, følger i neste avsnitt.

Sjekker på SBOM-nivå

Sjekk	Hvorfor det betyr noe	NTIA 2021	CISA 2026	BSI TR-03183-2
1. Kan parses og validerer mot skjemaet den oppgir	En fil verktøyene dine ikke kan lese, er ikke en SBOM	Påkrevd: SPDX, CycloneDX eller SWID-tagger	Praksis: maskinlesbar SPDX eller CycloneDX	Påkrevd: JSON eller XML
2. Spesifikasjonsversjonen når minstekravet ditt	Gamle versjoner kan ikke bære felt du trenger	Ikke nevnt	Minimumselement: navn og versjon på dataformatet; unngå utfasede versjoner	Påkrevd: CycloneDX 1.6+ eller SPDX 3.0.1+
3. SBOM-forfatter	Noen står ansvarlig for innholdet	Minimumselement: «Author of SBOM Data»	Minimumselement: «SBOM Author», organisasjonen, ikke verktøyet	Påkrevd: «Creator of the SBOM», e-post eller URL
4. Tidsstempel	Forteller hvilken SBOM som er gjeldende	Minimumselement	Minimumselement	Påkrevd; UTC anbefalt
5. Verktøynavn og -versjon	Forteller hva SBOM-en kan stoles på å dekke	Ikke nevnt	Minimumselement	Ikke nevnt
6. Genereringskontekst	En kildeskanning og en byggeregistrering av samme utgivelse er forskjellige	Anbefalt: livssyklusfase («source», «build», «post-build»)	Minimumselement: «before build», «build» eller «after build»	Ikke noe felt; innholdet må samsvare med det som var tilgjengelig under bygget
7. SBOM-versjon eller serienummer	Skiller en rettelse fra originalen	Ikke nevnt	Minimumselement: «SBOM Version»	Påkrevd hvis formatet har det: «SBOM-URI»
8. Forfattersignatur	Viser at filen kom uendret fra leverandøren	Anbefalt: signering oppmuntres	Minimumselement: «SBOM Author Signature»	Kun informativt: «ideally» signert
9. Toppkomponenten samsvarer med det du mottok	SBOM-en for feil utgivelse er verre enn ingen	Minimumselement: primærkomponenter	Minimumselement: målkomponenten	Påkrevd: primærkomponenten, roten i treet

Sjekker på komponentnivå

Sjekk	Hvorfor det betyr noe	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Komponentnavn	Det første hver matching bruker	Minimumselement	Minimumselement	Påkrevd; filnavnet hvis det ikke finnes noe navn
11. Versjon: ingen latest, unknown eller tomme verdier	Advisories gjelder versjonsintervaller	Minimumselement	Minimumselement; oppgi det hvis ukjent	Påkrevd; fildatoen hvis det ikke finnes noen versjon
12. Produsent eller leverandør	Skiller to komponenter med samme navn, og sier hvem som retter dem	Minimumselement: «Supplier Name»	Minimumselement: «Component Producer»	Påkrevd: «Component creator», e-post eller URL
13. Package URL der økosystemet har en, CPE der det ikke har det; begge velformede	Uten en identifikator (package URL, CPE) kan ingenting matches mot en sårbarhetsdatabase	Minimumselement: «Other Unique Identifiers», som CPE, SWID eller PURL, hvis de finnes	Minimumselement: minst én identifikator, som CPE eller PURL; ta med alle	Påkrevd hvis den finnes: CPE eller purl
14. Hashverdi og algoritme, som samsvarer med filen du mottok	Beviser at denne SBOM-en beskriver denne binærfilen	Anbefalt	Minimumselement: hash av den kjørbare artefakten, med en algoritme godkjent av en myndighet som NIST	Påkrevd: SHA-512 av komponenten som rulles ut
15. Lisens som SPDX-identifikatorer eller -uttrykk, ingen generell NOASSERTION	Lisensspesialisten din vurderer copyleft og andre forpliktelser ut fra den	Anbefalt	Minimumselement; SPDX-identifikatorer når det er mulig	Påkrevd: distribusjonslisenser, SPDX-identifikatorer først
16. Avhengighetsrelasjoner, og om listen er fullstendig	Viser hva som trakk inn en sårbar pakke, og om du kan stole på hullene	Minimumselement; oppgi når direkte avhengigheter er fullstendig listet	Minimumselement	Påkrevd, med fullstendigheten av hver liste oppgitt
17. Filnavn	Knytter oppføringen til en fil på enheten	Ikke nevnt	Ikke nevnt	Påkrevd
18. Egenskapene kjørbar, arkiv og strukturert	Sier hva slags fil hver komponent er	Ikke nevnt	Ikke nevnt	Påkrevd

Sjekker av dekning

Sjekk	Hvorfor det betyr noe	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Transitiv dybde, ikke bare toppnivået	Mest sårbar kode kommer inn indirekte	Toppnivå påkrevd; transitive anbefalt	Praksis for dekning: ta med transitive avhengigheter; ingen minstedybde	Påkrevd: rekursiv oppløsning
20. Kjente ukjente oppgitt	En SBOM som oppgir hullene sine, kan stoles på for det den lister	Påkrevd praksis	Praksis: ukjent og tilbakeholdt informasjon markert	Påkrevd gjennom fullstendighetserklæringen
21. Én SBOM per levert programvareversjon	Det er versjonen du kjører som teller	Påkrevd: en ny SBOM for hvert bygg eller hver utgivelse	Praksis: frekvens	Påkrevd
22. Rettelser sendt som en ny SBOM	En feil som rettes i det stille, kan ikke spores	Praksis: håndtering av feil	Praksis: håndtering av oppdateringer	Påkrevd: en oppdatert SBOM når feil rettes
23. Plausibilitet: ingen duplikater, et komponentantall som passer produktet, operativsystempakker til stede for en Linux-basert enhet	Den billigste stikkprøven av fullstendighet	Ikke nevnt	Praksis for dekning: flere instanser listet hver for seg	Flere instanser må listes hver for seg

Slik tester du hver sjekk, og hva du sier til leverandøren

Sjekk	Slik tester du den automatisk	Tilbakemelding til leverandøren
1, 2. Skjema og spesifikasjonsversjon	En skjemavalidator for formatet og versjonen som er oppgitt; sammenlign deretter specVersion (CycloneDX) eller SPDX-versjonen med minstekravet ditt	«Filen feiler skjemavalidering for CycloneDX 1.6 på stiene som er listet. Generer den på nytt med en generator, og valider den før du sender den.»
3 til 7. Forfatter, tidsstempel, verktøy, kontekst, versjon	Påkrevde metadata finnes: i CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber og version; i SPDX opprettelsesinformasjonen	«SBOM-en oppgir ikke verktøyet som produserte den, eller genereringskonteksten. Begge er Minimum Elements i CISA 2026.»
8. Signatur	En signatur finnes og verifiseres mot nøkkelen leverandøren har publisert	«Signer SBOM-en, eller send en separat signatur, slik CISA 2026-elementet SBOM Author Signature beskriver.»
9. Toppkomponent	Navnet og versjonen i metadata.component (CycloneDX) eller det beskrevne rotelementet (SPDX) samsvarer med delenummeret og programvareversjonen du mottok	«Denne SBOM-en beskriver versjon 5.2.0; vi mottok 5.3.0. Send SBOM-en for 5.3.0.»
10, 11. Navn og versjon	Ingen tomme navn; ingen tomme versjoner eller latest eller unknown, med mindre de er erklært ukjente	«14 komponenter har ingen versjon. Oppgi den nøyaktige versjonen, eller merk den som ukjent.»
12. Produsent	En leverandør, produsent eller forfatter på hver komponent	«Komponentene har ingen produsent, som CISA 2026-elementet Component Producer ber om.»
13. Identifikatorer	Hver purl kan parses med et package URL-bibliotek etter ECMA-427; hver CPE har gyldig CPE 2.3-syntaks og finnes i NVDs CPE-ordbok	«Ingen komponenter har en package URL eller CPE, så ingen kan matches mot sårbarhetsdatabaser. Legg til en purl for hver pakke fra en pakkebehandler.»
14. Hasher	En SHA-512-oppføring på hver komponent som rulles ut; beregn sha512sum av filen du mottok, og sammenlign	«SBOM-en har ingen hasher. BSI TR-03183-2 ber om SHA-512 av hver komponent som rulles ut.»
15. Lisenser	Lisens-ID-er eller -uttrykk som slår opp i SPDX-lisenslisten; tell NOASSERTION og tomme verdier	«92 % av komponentene har NOASSERTION som lisens. Oppgi SPDX-lisensidentifikatorer.»
16. Avhengigheter	En dependencies-graf (CycloneDX) eller avhengighetsrelasjoner (SPDX); en fullstendighetserklæring, som CycloneDX compositions med en aggregate-verdi	«SBOM-en er en flat liste. Ta med avhengighetsrelasjoner, og oppgi om hver liste er fullstendig.»
17, 18. Filnavn og filegenskaper	Egenskapene BSI TR-03183-2 definerer for hvert format, finnes	«Legg til filnavnet og egenskapene kjørbar, arkiv og strukturert, slik BSI TR-03183-2 v2.1.0 krever.»
19 til 23. Dekning	Dybden i avhengighetsgrafen, deteksjon av duplikater, et komponentantall sammenlignet med lignende produkter, forventede komponenter etter produkttype	«SBOM-en lister ingen kjerne, bootloader eller basissystempakker for en Linux-basert skjerm. Send SBOM-en for hele imaget.»

Prosentene og antallene i tilbakemeldingene er eksempler. Sett inn de faktiske tallene, og nevn rammeverk og versjon hver gang.

Hva en bestått score fortsatt går glipp av

En fil kan validere, få 9 av 10 poeng og likevel mangle halve produktet. Kvalitetspoeng leser feltene som finnes; de ser ikke komponentene som mangler.

Eksempel. En leverandør sender SBOM-en for en Linux-basert skjerm. Den er gyldig CycloneDX 1.6, hver komponent har en versjon, en package URL, en lisens og en SHA-512-hash, og avhengighetsgrafen er velformet. Den lister skjermapplikasjonen og 40 biblioteker. Den lister ikke Linux-kjernen, bootloaderen eller noen basissystempakke. Hver feltsjekk består. SBOM-en er ubrukelig for kjerne-CVE-er, som en Linux-enhet må overvåkes for, fordi kjernen ikke er med.

Slik kan et mottakende team teste fullstendigheten:

• Sammenlign med en binæranalyse av den leverte fastvaren. Noen OEM-er bruker den som erstatnings-SBOM til leverandørens SBOM er god nok, og som krysssjekk etterpå.
• Se etter forventede komponenter etter produkttype. Et Linux-image har en kjerne, et C-bibliotek og et init-system; en industriell kontroller har protokollstakkene sine.
• Spør om genereringskonteksten og verktøyet. En kildeskanning ser ikke det bygget hentet.
• Spør om SBOM-en kom fra bygget som produserte programvaren du mottok. Det er spørsmålet som avgjør det tredje laget.

Små SBOM-er kan være legitime. En bare-metal-ECU med proprietær fastvare og en leverandørkalibrering kan ærlig talt ha to komponenter. Godta det når SBOM-en sier det og oppgir sine kjente ukjente, i stedet for å straffe den for størrelsen.

Verktøy som automatiserer sjekkene

Sjekket på GitHub 11. november 2026. Ingen av disse repositoriene er arkivert.

Verktøy	Hva det sjekker	Hva det ikke sjekker	Status
CycloneDX CLI	Skjemavalidering av CycloneDX 1.0 til 1.7, JSON eller XML; --fail-on-errors for CI	SPDX, feltkvalitet, rammeverksprofiler	v0.33.1, juli 2026
sbom-utility	Skjemavalidering av CycloneDX 1.2 til 1.7 og SPDX 2.1 til 2.3 JSON, med egne skjemavarianter	SPDX 3, XML, rammeverksprofiler	v0.19.2, juni 2026
SPDX tools-java	Verify for SPDX 2.0 til 2.3 og 3.0.1	CycloneDX, rammeverksprofiler	v2.0.7, juni 2026
SPDX tools-python	pyspdxtools -i: full validering av SPDX 2.2 og 2.3	Lesing av SPDX 3, der støtten er eksperimentell	v0.8.5, mars 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 og 3.0 mot NTIA 2021, CISA FSCT3 og BSI TR-03183-2 v2.1.0; også en nettversjon	CycloneDX; CISA 2026 er en åpen forespørsel	v6.0.0, oktober 2026
sbomqs	En score fra 0 til 10 på tvers av identifikasjon, opprinnelse, integritet, fullstendighet, lisensiering, sårbarheter og struktur; compliance-profiler for CISA 2026, NTIA 2021, BSI TR-03183-2 v1.1 til v2.1.0, FSCT v3 og OpenChain Telco	Se komponenter som mangler	v2.1.3, oktober 2026; CISA 2026-profil siden v2.1.0, rettet i v2.1.2
sbom-scorecard	En vektet score for samsvar med spesifikasjonen, genereringsinformasjon, og pakkeidentifikatorer, versjoner og lisenser	Rammeverksprofiler	0.0.7, april 2023, den siste utgivelsen

Foreløpig er det bare sbomqs som sjekker CISA 2026 Minimum Elements. Sjekk utgivelsesnotatene for hvert verktøy før du stoler på en profil: I sbomqs 2.1.1 kjørte CISA 2026-flagget 2021-sjekken ved en feil. For BSI TR-03183-2 v2.1.0 i sbomqs bruker du --bsi-v21 eller --bsi; --bsi-v2 sjekker v2.0.0.

Et minimalt mottakssteg for en CycloneDX-SBOM fra en leverandør:

# 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

For SPDX bruker du sbomcheck -s spdx3 -c bsi supplier-sbom.json fra NTIA Conformance Checker. Les samsvarsrapporten og avvis filen på sjekkene kravet ditt gjør obligatoriske; send den tilbake til leverandøren med tilbakemeldingene ovenfor.

Skriv det inn i leverandørkravene

En sjekkliste leverandøren aldri har sett, er ikke et krav. Legg den i kontraktsvedlegget:

• Rammeverket og versjonen: for eksempel «BSI TR-03183-2 v2.1.0» eller «CISA 2026 Minimum Elements». Nevn ett; ikke skriv «bransjestandard».
• Formatet og minste spesifikasjonsversjon: for eksempel CycloneDX 1.6 eller nyere, eller SPDX 3.0.1 eller nyere, JSON.
• Feltene du legger til i tillegg, som SHA-512-hasher eller package URL-er for hver pakke.
• Levering: én SBOM per levert programvareversjon, før eller sammen med programvaren.
• Valideringen leverandøren kjører før sending, navngitt etter verktøy og profil.
• Tilbakemeldingssløyfen: hvem som mottar tilbakemeldingen, og hvor raskt en rettet SBOM skal komme.

Leverandørens side av den samme avtalen står i SBOM-guiden for leverandører. For en programvareleverandør som svarer på en enkeltstående forespørsel, se SBOM-forespørsler fra kunder.

Slik retter du en SBOM som feilet (for leverandører)

• Håndskrevne filer. Bruk en generator eller et SBOM-bibliotek, aldri et tekstredigeringsprogram.
• Manglende package URL-er. Generer dem fra pakkebehandleren eller bygget, ikke for hånd. En håndskrevet purl er en gjettet purl.
• Manglende lisenser. Hent den deklarerte lisensen fra pakkens metadata, som en SPDX-identifikator.
• Ingen hasher. Beregn dem over filene du faktisk leverer, på slutten av bygget.
• Feil utgivelse. Generer SBOM-en i utgivelsesbygget, og gi den navn etter versjonen.
• Bare toppnivået. Bruk en metode som løser opp transitive avhengigheter.

Den mest pålitelige måten å rette fullstendighet og identifikatorer på samtidig, er å generere SBOM-en fra bygget som produserte den leverte programvaren. Se SBOM-er fra bygget og beste praksis for SBOM.

Hvor gode SBOM-er kommer fra, og hvor CRACI passer inn

For leverandører som bygger på GitHub Actions, erstatter CRACI de GitHub-hostede runnerne og registrerer SBOM-en under bygget, så den lister det bygget faktisk trakk inn.

• Hver pakke med en package URL, og hver komponent med sin deklarerte lisens.
• Transitive avhengigheter, på hvert nivå bygget nådde.
• En fullstendighetsstatus for hver jobb, som besvarer spørsmålet om kjente ukjente per bygg: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.
• Eksportert som CycloneDX eller SPDX; SBOM-API-et returnerer CycloneDX 1.7 JSON.

For en hel utviklingsorganisasjon, se standardisering av SBOM-generering, og for innebygd Linux, hvorfor skannere går glipp av det som er i Yocto-bygg.

For OEM-er kan SBOM-er fra tredjeparter legges til i CRACI, så komponenter du kjøper inn, overvåkes for nye sårbarheter sammen med dine egne bygg. Se verktøy for SBOM-håndtering for hvordan det sammenlignes.

Når CRACI ikke er svaret

• Validering og poengsetting av SBOM-ene du mottar. CRACI tilbyr ingen SBOM-validator eller kvalitetspoeng. Bruk verktøyene ovenfor.
• Leverandører uten CI, eller der koden genereres av modellbaserte verktøy uten pakkehenting. En byggeregistrering tilfører lite; en validert SBOM fra et generatorbibliotek er det realistiske svaret.
• Fastvare du bare mottar som binærfil. Det besvarer binæranalyse.
• Signerte SBOM-er, forfattersignaturen i CISA 2026. CRACI signerer ikke SBOM-er.

SBOM-kvalitet og validering: ofte stilte spørsmål

Hvordan sjekker jeg kvaliteten på en SBOM en leverandør har sendt meg?

Test tre lag. Valider filen mot skjemaet, sjekk feltene mot et navngitt rammeverk som BSI TR-03183-2 eller CISA 2026 Minimum Elements, og test deretter fullstendigheten: sammenlign med en binæranalyse av det du mottok, og se etter komponentene produkttypen må inneholde.

Hvilke felt må en SBOM inneholde?

Det avhenger av rammeverket du nevner. CISAs Minimum Elements fra 2026 lister 17 felt, blant dem forfatter, tidsstempel, verktøy, genereringskontekst og per komponent navn, versjon, produsent, identifikatorer, hash og lisens. BSI TR-03183-2 legger til en SHA-512-hash, filnavnet og filegenskaper, og krever dem.

Hva endret seg mellom NTIAs minimumselementer og CISAs Minimum Elements fra 2026?

CISAs liste fra 2026 erstatter NTIAs sju felt med 17. Nye er forfattersignaturen, navn og versjon på dataformatet, genereringskontekst, verktøynavn og -versjon, SBOM-versjon, hashverdi og algoritme for komponenten, og komponentens lisens. Supplier Name ble Component Producer, og dybde ble dekning.

Hva krever BSI TR-03183-2 i en SBOM?

Versjon 2.1.0 krever CycloneDX 1.6+ eller SPDX 3.0.1+ i JSON eller XML, én SBOM per programvareversjon, rekursive avhengigheter med fullstendigheten oppgitt, og per komponent oppretter, navn, versjon, filnavn, lisenser, SHA-512-hash og filegenskaper, med en package URL eller CPE hvis den finnes.

Trenger en SBOM hasher? Hvilken algoritme?

NTIA anbefalte dem; CISA 2026 gjør hashen til et minimumselement med en algoritme godkjent av en myndighet som NIST; BSI TR-03183-2 krever SHA-512 av hver komponent som rulles ut. Be om SHA-512, og sammenlign den med filen du mottok.

Trenger jeg både en CPE og en PURL?

Ikke alltid. Be om en package URL der økosystemet har en, og en CPE der det ikke har det, som for mange kommersielle eller innebygde komponenter. CISA 2026 ber om minst én identifikator og alle som er kjent; BSI krever hver av dem hvis den finnes.

Hvordan validerer jeg en CycloneDX- eller SPDX-fil?

For CycloneDX: cyclonedx-cli validate med --fail-on-errors, eller sbom-utility. For SPDX: Verify-kommandoen i SPDX tools-java, eller pyspdxtools for SPDX 2.2 og 2.3. Kjør deretter en rammeverksprofil med sbomqs eller SPDX NTIA Conformance Checker.

Hva er en god kvalitetsscore for en SBOM?

Det finnes ingen standard terskel, og ingen referanseverdi vi ville sitere. En score måler feltene som finnes, ikke fullstendigheten: en fil kan få 9 av 10 og mangle halve produktet. Sett heller beståttkriterier per sjekk i leverandørkravet ditt, og følg scoren som en trend.