Tjekliste for SBOM-kvalitet: sådan validerer du leverandørernes SBOM'er

De tre lag af SBOM-kvalitet

Lag	Spørgsmål	Hvad tjekker det	Hvad det ikke kan fortælle dig
Gyldig	Kan filen parses, og følger den skemaet for det format og den version, den angiver?	Skemavalidatorer	Om nogen af felterne indeholder noget brugbart
Brugbar	Er de felter, du har brug for, til stede, og kan et værktøj bruge dem: identifikatorer, der matcher advisories, licenser, hashes, relationer?	Felttjek, compliance-profiler og kvalitetsscorer	Hvad der mangler i filen
Komplet	Indeholder den alt i den software, du har modtaget?	Sammenligning med buildet eller med en analyse af den leverede binærfil	Intet, der kun læser SBOM'en, kan svare på det

De fleste modtagende teams stopper ved første lag. "Filen validerer" er starten på tjekket, ikke resultatet. Det tredje lag er SBOM-fuldstændighed.

Rammeværkerne på ét minut

Nævn rammeværket i hver anmodning og hver feedback, så barren er en offentliggjort standard og ikke din mening.

• NTIA, The Minimum Elements for a Software Bill of Materials (12. juli 2021). Syv datafelter (leverandørnavn, komponentnavn, version, andre unikke identifikatorer, afhængighedsrelation, forfatter af SBOM-data, tidsstempel), understøttelse af automatisering i SPDX, CycloneDX eller SWID-tags samt praksisser: hyppighed, dybde, kendte ukendte, distribution og levering, adgangskontrol og håndtering af fejl. Hashes, licenser, livscyklusfase og signaturer er anført som anbefalede ud over minimum.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29. juli 2026, efter et udkast den 22. august 2025). Erstatter NTIA-elementerne. Skrevet af 18 organisationer fra 14 lande, blandt dem CISA, NSA, FBI, Tysklands BSI samt Japans METI og NCO. Den har 17 datafelter, hvoraf ti er nye: SBOM author signature, data format name, data format version, generation context, tool name, tool version, SBOM version, component hash value, component hash algorithm og component license. "Supplier name" bliver til "Component Producer". Praksisserne er dækning, eksplicit markering af ukendt information, maskinlæsbare data, håndtering af opdateringer, hyppighed samt distribution og levering. Dokumentet formulerer hvert element med "should" og siger, at det ikke skaber nye krav; købere gør det bindende ved at skrive det ind i kontrakter.
• BSI, TR-03183-2 version 2.1.0 (20. august 2025), Tyskland. Den strengeste af de tre, skrevet med MUST: JSON eller XML, CycloneDX 1.6 eller nyere eller SPDX 3.0.1 eller nyere, én SBOM pr. softwareversion, rekursiv opløsning af afhængigheder med angivelse af, om hver afhængighedsliste er komplet, en SHA-512-hash af hver komponent, der kan udrulles, komponentens filnavn, distributionslicenser som SPDX-identifikatorer og package URL eller CPE "if it exists". Den siger også, at en SBOM ikke må indeholde sårbarhedsinformation; den hører hjemme i et VEX-dokument eller en advisory.
• International samordning. A Shared Vision of SBOM for Cybersecurity (3. september 2025) er underskrevet af 18 organisationer fra 15 lande. G7's arbejde med SBOM'er handler om AI-systemer ("A shared G7 vision on SBOM for AI", 2025, og "SBOM for AI – Minimum Elements", maj 2026) og stiller ingen krav til indlejrede leverandør-SBOM'er.
• Bilindustrien. Auto-ISAC offentliggjorde en SBOM Informational Report den 11. februar 2025.

Tjeklisten

Sådan læser du cellerne: Påkrævet betyder, at dokumentet siger must. Minimumselement betyder, at det står på dokumentets minimumsliste (NTIA's baseline eller CISA's "should"-elementer). Anbefalet betyder, at dokumentet nævner det ud over minimum. Ikke nævnt betyder, at dokumentet ikke beder om det. Hvordan du tester hvert tjek, og hvilken feedbacklinje du sender, følger i næste afsnit.

Tjek på SBOM-niveau

Tjek	Hvorfor det betyder noget	NTIA 2021	CISA 2026	BSI TR-03183-2
1. Kan parses og validerer mod det angivne skema	En fil, dine værktøjer ikke kan læse, er ikke en SBOM	Påkrævet: SPDX, CycloneDX eller SWID-tags	Praksis: maskinlæsbar SPDX eller CycloneDX	Påkrævet: JSON eller XML
2. Specifikationsversionen lever op til dit minimum	Gamle versioner kan ikke rumme felter, du har brug for	Ikke nævnt	Minimumselement: navn og version på dataformatet; undgå udfasede versioner	Påkrævet: CycloneDX 1.6+ eller SPDX 3.0.1+
3. SBOM-forfatter	Nogen står inde for indholdet	Minimumselement: "Author of SBOM Data"	Minimumselement: "SBOM Author", organisationen, ikke værktøjet	Påkrævet: "Creator of the SBOM", e-mail eller URL
4. Tidsstempel	Fortæller dig, hvilken SBOM der er den aktuelle	Minimumselement	Minimumselement	Påkrævet; UTC anbefales
5. Værktøjets navn og version	Fortæller dig, hvad SBOM'en kan forventes at dække	Ikke nævnt	Minimumselement	Ikke nævnt
6. Genereringskontekst	En kildescanning og en build-registrering af samme release er forskellige	Anbefalet: livscyklusfase ("source", "build", "post-build")	Minimumselement: "before build", "build" eller "after build"	Intet felt; indholdet skal svare til det, der var tilgængeligt under buildet
7. SBOM-version eller serienummer	Skelner en rettelse fra originalen	Ikke nævnt	Minimumselement: "SBOM Version"	Påkrævet, hvis formatet har et: "SBOM-URI"
8. Forfattersignatur	Viser, at filen kom uændret fra leverandøren	Anbefalet: signering opfordres der til	Minimumselement: "SBOM Author Signature"	Kun vejledende: "ideally" signeret
9. Komponenten på øverste niveau svarer til det, du har modtaget	SBOM'en for den forkerte release er værre end ingen	Minimumselement: primære komponenter	Minimumselement: målkomponenten	Påkrævet: den primære komponent, træets rod

Tjek på komponentniveau

Tjek	Hvorfor det betyder noget	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Komponentnavn	Det første, ethvert match bruger	Minimumselement	Minimumselement	Påkrævet; filnavnet, hvis der ikke er noget navn
11. Version: ingen latest, unknown eller tomme værdier	Advisories gælder for versionsintervaller	Minimumselement	Minimumselement; sig det, hvis den er ukendt	Påkrævet; filens dato, hvis der ikke er nogen version
12. Producent eller leverandør	Skelner to komponenter med samme navn og fortæller, hvem der retter fejlen	Minimumselement: "Supplier Name"	Minimumselement: "Component Producer"	Påkrævet: "Component creator", e-mail eller URL
13. Package URL, hvor økosystemet har en, ellers CPE; begge korrekt opbygget	Uden en identifikator (package URL, CPE) kan intet matches mod en sårbarhedsdatabase	Minimumselement: "Other Unique Identifiers", såsom CPE, SWID eller PURL, hvis de findes	Minimumselement: mindst én identifikator, såsom CPE eller PURL; medtag alle	Påkrævet, hvis den findes: CPE eller purl
14. Hashværdi og algoritme, der matcher den fil, du har modtaget	Beviser, at denne SBOM beskriver denne binærfil	Anbefalet	Minimumselement: hash af det eksekverbare artefakt med en algoritme godkendt af en myndighed som NIST	Påkrævet: SHA-512 af den komponent, der kan udrulles
15. Licens som SPDX-identifikatorer eller -udtryk, ingen generel NOASSERTION	Din licensspecialist vurderer copyleft og andre forpligtelser ud fra den	Anbefalet	Minimumselement; SPDX-identifikatorer, når det er muligt	Påkrævet: distributionslicenser, SPDX-identifikatorer først
16. Afhængighedsrelationer, og om listen er komplet	Viser, hvad der trak en sårbar pakke ind, og om du kan stole på hullerne	Minimumselement; angiv, når de direkte afhængigheder er fuldt opført	Minimumselement	Påkrævet, med angivelse af, om hver liste er komplet
17. Filnavn	Knytter posten til en fil på enheden	Ikke nævnt	Ikke nævnt	Påkrævet
18. Egenskaberne executable, archive og structured	Fortæller, hvilken slags fil hver komponent er	Ikke nævnt	Ikke nævnt	Påkrævet

Tjek af dækning

Tjek	Hvorfor det betyder noget	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Transitiv dybde, ikke kun øverste niveau	Det meste sårbare kode kommer ind indirekte	Øverste niveau påkrævet; transitive anbefalet	Praksis for dækning: medtag transitive afhængigheder; ingen minimumsdybde	Påkrævet: rekursiv opløsning
20. Kendte ukendte er angivet	En SBOM, der angiver sine huller, er til at stole på for det, den opfører	Påkrævet praksis	Praksis: ukendt og tilbageholdt information markeret	Påkrævet via angivelsen af fuldstændighed
21. Én SBOM pr. leveret softwareversion	Det er den version, du kører, der tæller	Påkrævet: en ny SBOM for hvert build eller hver release	Praksis: hyppighed	Påkrævet
22. Rettelser sendes som en ny SBOM	En fejl, der rettes i stilhed, kan ikke spores	Praksis: håndtering af fejl	Praksis: håndtering af opdateringer	Påkrævet: en opdateret SBOM, når fejl rettes
23. Plausibilitet: ingen dubletter, et antal komponenter, der passer til produktet, styresystempakker med for en Linux-baseret enhed	Den billigste test af fuldstændighed	Ikke nævnt	Praksis for dækning: flere forekomster opført hver for sig	Flere forekomster skal opføres hver for sig

Sådan tester du hvert tjek, og hvad du siger til leverandøren

Tjek	Sådan tester du det automatisk	Feedbacklinje til leverandøren
1, 2. Skema og specifikationsversion	En skemavalidator for det angivne format og den angivne version; sammenlign derefter specVersion (CycloneDX) eller SPDX-versionen med dit minimum	"Filen fejler skemavalidering for CycloneDX 1.6 på de anførte stier. Generér den igen med en generator, og validér den, før du sender den."
3 til 7. Forfatter, tidsstempel, værktøj, kontekst, version	De påkrævede metadata er til stede: i CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber og version; i SPDX oplysningerne om oprettelsen	"SBOM'en angiver hverken det værktøj, der producerede den, eller genereringskonteksten. Begge er CISA 2026 Minimum Elements."
8. Signatur	Der er en signatur, og den kan verificeres mod den nøgle, leverandøren har offentliggjort	"Signér venligst SBOM'en, eller send en separat signatur, som CISA 2026-elementet SBOM Author Signature beskriver."
9. Komponent på øverste niveau	Navn og version i metadata.component (CycloneDX) eller det beskrevne rodelement (SPDX) svarer til det varenummer og den softwareversion, du har modtaget	"Denne SBOM beskriver version 5.2.0; vi har modtaget 5.3.0. Send venligst SBOM'en for 5.3.0."
10, 11. Navn og version	Ingen tomme navne; ingen tomme versioner eller versioner med latest eller unknown, medmindre de er erklæret ukendte	"14 komponenter har ingen version. Angiv venligst den præcise version, eller markér den som ukendt."
12. Producent	En leverandør, producent eller forfatter på hver komponent	"Komponenterne har ingen producent, som CISA 2026-elementet Component Producer beder om."
13. Identifikatorer	Hver purl kan parses med et package URL-bibliotek efter ECMA-427; hver CPE har gyldig CPE 2.3-syntaks og findes i NVD's CPE-ordbog	"Ingen komponent har en package URL eller CPE, så ingen kan matches mod sårbarhedsdatabaser. Tilføj venligst en purl for hver pakke fra en pakkemanager."
14. Hashes	En SHA-512-post på hver komponent, der kan udrulles; beregn sha512sum af den fil, du har modtaget, og sammenlign	"SBOM'en har ingen hashes. BSI TR-03183-2 beder om SHA-512 for hver komponent, der kan udrulles."
15. Licenser	Licens-ID'er eller -udtryk, der kan slås op i SPDX-licenslisten; tæl NOASSERTION og tomme værdier	"92 % af komponenterne har NOASSERTION som licens. Angiv venligst SPDX-licensidentifikatorer."
16. Afhængigheder	En dependencies-graf (CycloneDX) eller afhængighedsrelationer (SPDX); en angivelse af fuldstændighed, såsom CycloneDX compositions med en aggregate-værdi	"SBOM'en er en flad liste. Medtag venligst afhængighedsrelationer, og angiv, om hver liste er komplet."
17, 18. Filnavn og filegenskaber	De egenskaber, BSI TR-03183-2 definerer for hvert format, er til stede	"Tilføj venligst filnavnet og egenskaberne executable, archive og structured, som BSI TR-03183-2 v2.1.0 kræver."
19 til 23. Dækning	Afhængighedsgrafens dybde, registrering af dubletter, antallet af komponenter sammenlignet med lignende produkter, forventede komponenter efter produkttype	"SBOM'en indeholder hverken kerne, bootloader eller basissystemets pakker for et Linux-baseret display. Send venligst SBOM'en for hele imaget."

Procentsatserne og antallene i feedbacklinjerne er eksempler. Sæt de rigtige tal ind, og nævn rammeværket og versionen hver gang.

Hvad en bestået score stadig overser

En fil kan validere, score 9 ud af 10 og stadig mangle halvdelen af produktet. Kvalitetsscorer læser de felter, der er der; de kan ikke se de komponenter, der ikke er.

Eksempel. En leverandør sender SBOM'en for et Linux-baseret display. Den er gyldig CycloneDX 1.6, hver komponent har en version, en package URL, en licens og en SHA-512-hash, og afhængighedsgrafen er korrekt opbygget. Den indeholder displayapplikationen og 40 biblioteker. Den indeholder ikke Linux-kernen, bootloaderen eller nogen af basissystemets pakker. Alle felttjek består. SBOM'en er ubrugelig til kerne-CVE'er, som en Linux-enhed skal overvåges for, fordi kernen ikke er med i den.

Sådan kan et modtagende team teste fuldstændigheden:

• Sammenlign med en binær analyse af den leverede firmware. Nogle OEM'er bruger den som midlertidig SBOM, indtil leverandørens SBOM er god nok, og som krydstjek bagefter.
• Tjek for forventede komponenter efter produkttype. Et Linux-image har en kerne, et C-bibliotek og et init-system; en industriel controller har sine protokolstakke.
• Spørg efter genereringskonteksten og værktøjet. En kildescanning kan ikke se, hvad buildet hentede.
• Spørg, om SBOM'en kom fra det build, der producerede den software, du har modtaget. Det er det spørgsmål, der afgør det tredje lag.

Små SBOM'er kan være legitime. En bare-metal-ECU med proprietær firmware og en kalibrering fra leverandøren kan ærligt talt have to komponenter. Acceptér det, når SBOM'en siger det og angiver sine kendte ukendte, i stedet for at straffe den for dens størrelse.

Værktøjer, der automatiserer tjekkene

Tjekket på GitHub den 11. november 2026. Ingen af disse repositories er arkiveret.

Værktøj	Hvad det tjekker	Hvad det ikke tjekker	Status
CycloneDX CLI	Skemavalidering af CycloneDX 1.0 til 1.7, JSON eller XML; --fail-on-errors til CI	SPDX, feltkvalitet, profiler for rammeværker	v0.33.1, juli 2026
sbom-utility	Skemavalidering af CycloneDX 1.2 til 1.7 og SPDX 2.1 til 2.3 JSON, med tilpassede skemavarianter	SPDX 3, XML, profiler for rammeværker	v0.19.2, juni 2026
SPDX tools-java	Verify for SPDX 2.0 til 2.3 og 3.0.1	CycloneDX, profiler for rammeværker	v2.0.7, juni 2026
SPDX tools-python	pyspdxtools -i: fuld validering af SPDX 2.2 og 2.3	Læsning af SPDX 3, hvor understøttelsen er eksperimentel	v0.8.5, marts 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 og 3.0 mod NTIA 2021, CISA FSCT3 og BSI TR-03183-2 v2.1.0; findes også i en webversion	CycloneDX; CISA 2026 er en åben anmodning	v6.0.0, oktober 2026
sbomqs	En score fra 0 til 10 på tværs af identifikation, oprindelse, integritet, fuldstændighed, licenser, sårbarheder 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 manglende komponenter	v2.1.3, oktober 2026; CISA 2026-profil siden v2.1.0, rettet i v2.1.2
sbom-scorecard	En vægtet score for overholdelse af specifikationen, oplysninger om genereringen samt pakkernes identifikatorer, versioner og licenser	Profiler for rammeværker	0.0.7, april 2023, den seneste release

Indtil videre er det kun sbomqs, der tjekker CISA 2026 Minimum Elements. Læs hvert værktøjs release notes, før du stoler på en profil: I sbomqs 2.1.1 kørte CISA 2026-flaget ved en fejl 2021-tjekket. Til BSI TR-03183-2 v2.1.0 i sbomqs bruger du --bsi-v21 eller --bsi; --bsi-v2 tjekker v2.0.0.

Et minimalt modtagetrin for en leverandø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

Til SPDX bruger du sbomcheck -s spdx3 -c bsi supplier-sbom.json fra NTIA Conformance Checker. Læs compliance-rapporten, og afvis filen på de tjek, dit krav gør obligatoriske; send den tilbage til leverandøren med feedbacklinjerne ovenfor.

Skriv det ind i leverandørkravene

En tjekliste, leverandøren aldrig har set, er ikke et krav. Sæt den i kontraktens bilag:

• Rammeværket og versionen: for eksempel "BSI TR-03183-2 v2.1.0" eller "CISA 2026 Minimum Elements". Nævn ét; skriv ikke "branchestandard".
• Formatet og den laveste specifikationsversion: for eksempel CycloneDX 1.6 eller nyere eller SPDX 3.0.1 eller nyere, JSON.
• De felter, du kræver ud over det, såsom SHA-512-hashes eller package URLs for hver pakke.
• Levering: én SBOM pr. leveret softwareversion, før eller sammen med softwaren.
• Den validering, leverandøren kører før afsendelse, angivet med værktøj og profil.
• Feedbacksløjfen: hvem der modtager feedbacken, og hvor hurtigt en rettet SBOM skal komme.

Leverandørens side af samme aftale finder du i SBOM-guiden for leverandører. Er du softwareleverandør og skal svare på en enkeltstående anmodning, så se kunders SBOM-anmodninger.

Sådan retter du en SBOM, der ikke bestod (for leverandører)

• Håndskrevne filer. Brug en generator eller et SBOM-bibliotek, aldrig en teksteditor.
• Manglende package URLs. Generér dem fra pakkemanageren eller buildet, ikke i hånden. En indtastet purl er en gættet purl.
• Manglende licenser. Tag den deklarerede licens fra pakkens metadata som en SPDX-identifikator.
• Ingen hashes. Beregn dem over de filer, du faktisk leverer, i slutningen af buildet.
• Den forkerte release. Generér SBOM'en i release-buildet, og navngiv den efter versionen.
• Kun øverste niveau. Brug en metode, der opløser transitive afhængigheder.

Den mest pålidelige måde at rette fuldstændighed og identifikatorer på én gang er at generere SBOM'en fra det build, der producerede den leverede software. Se SBOM'er fra buildet og bedste praksis for SBOM'er.

Hvor gode SBOM'er kommer fra, og hvor CRACI passer ind

For leverandører, der bygger på GitHub Actions, erstatter CRACI de GitHub-hostede runners og registrerer SBOM'en under buildet, så den viser, hvad buildet faktisk hentede ind.

• Hver pakke med en package URL, og hver komponent med sin deklarerede licens.
• Transitive afhængigheder i alle de lag, buildet nåede.
• En fuldstændighedsstatus for hvert job, som besvarer spørgsmålet om kendte ukendte for hvert build: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded.
• Eksporteres som CycloneDX eller SPDX; SBOM-API'et returnerer CycloneDX 1.7 JSON.

For en hel udviklingsorganisation, se standardisering af SBOM-generering, og for indlejret Linux, hvorfor scannere overser det, der er i Yocto-builds.

For OEM'er kan tredjeparts-SBOM'er tilføjes i CRACI, så komponenter, du køber ind, overvåges for nye sårbarheder side om side med dine egne builds. Se værktøjer til SBOM-administration for en sammenligning.

Når CRACI ikke er svaret

• Validering og scoring af de SBOM'er, du modtager. CRACI tilbyder hverken en SBOM-validator eller en kvalitetsscore. Brug værktøjerne ovenfor.
• Leverandører uden CI, eller hvis kode genereres af modelbaserede værktøjer uden pakkehentning. En build-registrering tilføjer ikke meget; en valideret SBOM fra et generatorbibliotek er det realistiske svar.
• Firmware, du kun modtager som binærfil. Det svarer binær analyse på.
• Signerede SBOM'er, CISA 2026's forfattersignatur. CRACI signerer ikke SBOM'er.

SBOM-kvalitet og validering: ofte stillede spørgsmål

Hvordan tjekker jeg kvaliteten af en SBOM, en leverandør har sendt mig?

Test tre lag. Validér filen mod dens skema, tjek felterne mod et navngivet rammeværk som BSI TR-03183-2 eller CISA 2026 Minimum Elements, og test derefter fuldstændigheden: Sammenlign med en binær analyse af det, du har modtaget, og tjek for de komponenter, produkttypen skal indeholde.

Hvilke felter skal en SBOM indeholde?

Det afhænger af det rammeværk, du henviser til. CISA's 2026 Minimum Elements opregner 17 felter, blandt andet forfatter, tidsstempel, værktøj, genereringskontekst og for hver komponent navn, version, producent, identifikatorer, hash og licens. BSI TR-03183-2 tilføjer en SHA-512-hash, filnavnet og filegenskaber og gør dem påkrævede.

Hvad ændrede sig fra NTIA's minimumselementer til CISA's 2026 Minimum Elements?

CISA's liste fra 2026 erstatter NTIA's syv felter med 17. Nye er forfattersignatur, dataformatets navn og version, genereringskontekst, værktøjets navn og version, SBOM-version, komponentens hashværdi og algoritme samt komponentens licens. Supplier name blev til Component Producer, og dybde blev til dækning.

Hvad kræver BSI TR-03183-2 af en SBOM?

Version 2.1.0 kræver CycloneDX 1.6+ eller SPDX 3.0.1+ i JSON eller XML, én SBOM pr. softwareversion, rekursive afhængigheder med angivelse af fuldstændighed og for hver komponent skaber, navn, version, filnavn, licenser, SHA-512-hash og filegenskaber samt en package URL eller CPE, hvis den findes.

Skal en SBOM have hashes? Hvilken algoritme?

NTIA anbefalede dem; CISA 2026 gør hashen til et minimumselement med en algoritme godkendt af en myndighed som NIST; BSI TR-03183-2 kræver SHA-512 af hver komponent, der kan udrulles. Bed om SHA-512, og sammenlign den med den fil, du har modtaget.

Har jeg brug for både en CPE og en PURL?

Ikke altid. Bed om en package URL, hvor økosystemet har en, og en CPE, hvor det ikke har, som for mange kommercielle eller indlejrede komponenter. CISA 2026 beder om mindst én identifikator og alle, der kendes; BSI kræver hver af dem, hvis den findes.

Hvordan validerer jeg en CycloneDX- eller SPDX-fil?

Til CycloneDX: cyclonedx-cli validate med --fail-on-errors eller sbom-utility. Til SPDX: Verify-kommandoen i SPDX tools-java eller pyspdxtools til SPDX 2.2 og 2.3. Kør derefter en profil for et rammeværk med sbomqs eller SPDX NTIA Conformance Checker.

Hvad er en god kvalitetsscore for en SBOM?

Der findes ingen standardgrænse og intet benchmark, vi vil citere. En score måler de felter, der er til stede, ikke fuldstændigheden: En fil kan score 9 ud af 10 og mangle halvdelen af produktet. Fastsæt i stedet kriterier for hvert tjek i dit leverandørkrav, og følg scoren som en tendens.