SBOM-fuldstændighed

En SBOM er fuldstændig, når den angiver hver komponent, der gik ind i den software, den beskriver, på alle niveauer af afhængighedstræet, også komponenter, som ingen lockfile eller manifest angiver. SBOM-fuldstændighed er netop den egenskab. CISA's 2026 Minimum Elements beder SBOM-forfattere om udtrykkeligt at angive, når oplysninger er ukendte, og bemærker, at modtagere kan betragte en SBOM som ufuldstændig, hvis væsentlige komponentdata holdes tilbage.

Fuldstændighed, gyldighed og kvalitet er forskellige ting

Spørgsmål	Hvad det betyder	Hvad der kontrollerer det	Hvad det ikke kan fortælle
Gyldig	Filen overholder CycloneDX- eller SPDX-skemaet	En skemavalidator	Om der mangler komponenter
Feltkvalitet	Hver komponent har navn, version, leverandør, identifikator, licens og hash	Et værktøj til kvalitetsscoring	Om der mangler komponenter
Fuldstændig	Intet af det, der gik ind i softwaren, mangler	En sammenligning med, hvad buildet faktisk tog ind	Input, som sammenligningen ikke så

Identifikatoren i anden række er som regel en package URL eller en CPE. En fil kan bestå de første to kontroller perfekt og alligevel udelade halvdelen af softwaren.

Hvorfor fuldstændighed er svær at måle bagefter

En scanner arbejder ud fra lockfiler, manifester eller det færdige output. Den kan ikke kende til en pakke, som et post-install-script downloadede, en crate, der er kompileret ind i en binær, eller et lag i base imaget, den aldrig fik at se. Hver af dem er en skjult afhængighed.

Tag en Node.js-tjeneste, hvis lockfile angiver 400 pakker. En af dem har et postinstall-script, der downloader en færdigbygget binær under npm ci. En SBOM genereret fra package-lock.json er gyldig, hver komponent har en version og en package URL, og binæren er ikke med. Ingen kvalitetsscore markerer det, fordi intet i filen peger på det, der mangler.

At bygge igen senere afgør heller ikke spørgsmålet: medmindre buildet er et reproducerbart build, kan et andet build tage noget andet ind end det første.

Sådan angiver du fuldstændighed ærligt

• Angiv genereringskonteksten: om SBOM'en blev lavet ud fra kildekoden før buildet, registreret under buildet eller lavet ved at analysere outputtet bagefter.
• Angiv kendte huller: dele af softwaren, som værktøjet ikke kunne se, for eksempel vendoret kode, færdigbyggede binærer eller komponenter installeret uden for en pakkehåndtering.
• Foretræk en status med begrundelser frem for en score. En fuldstændighedsprocent kræver et samlet tal, og det tal er netop det, ingen kender. En angivelse som "ufuldstændig: jobbet tillod ikke-overvåget trafik" kan man handle på.

SBOM best practices dækker den bredere praksis med at angive, hvad en SBOM ikke kunne se.

Fuldstændighedsstatus i CRACI

CRACI giver hvert jobs SBOM en fuldstændighedsstatus, og caches får også en. Statusserne, som CRACI's dokumentation definerer dem:

• Complete: "CRACI observerede fuldstændigt grundlag for jobbet, og hver gendannet cache var fuldstændig."
• Complete with connections: "Kravene blev opfyldt, men jobbet brugte en eller flere brugerdefinerede netværksforbindelser."
• Incomplete: "CRACI identificerede en tilstand, der kan få afhængigheder til at mangle i SBOM'en."
• Unavailable: "CRACI kunne ikke færdiggøre evalueringen af grundlaget."
• Not recorded: "Jobbet er ældre end rapporteringen af fuldstændighed."

CRACI kan angive det, fordi det ser hvert jobs trafik til pakkekilder og derfor ved, hvornår noget kan være gået uden om det: trafik, det ikke overvågede, eller en gendannet cache, hvis egen SBOM var ufuldstændig. Når et job er ufuldstændigt, viser jobbet årsagen, for eksempel "Unmonitored traffic was allowed". Se SBOM-generering.

Disse statusser gælder for builds, der kører på CRACI-runners. For en SBOM fra en leverandør eller fra en pipeline, der ikke kører på CRACI, skal du bruge sammenligningerne og reglerne ovenfor.