SBOM-fullstendighet

En SBOM er fullstendig når den oppgir hver komponent som gikk inn i programvaren den beskriver, på alle nivåer i avhengighetstreet, også komponenter som ingen lockfile eller manifest oppgir. SBOM-fullstendighet er nettopp den egenskapen. CISAs 2026 Minimum Elements ber SBOM-forfattere om å angi uttrykkelig når informasjon er ukjent, og påpeker at mottakere kan anse en SBOM som ufullstendig hvis vesentlige komponentdata holdes tilbake.

Fullstendighet, gyldighet og kvalitet er ulike ting

Spørsmål	Hva det betyr	Hva som kontrollerer det	Hva det ikke kan si
Gyldig	Filen følger CycloneDX- eller SPDX-skjemaet	En skjemavalidator	Om komponenter mangler
Feltkvalitet	Hver komponent har navn, versjon, leverandør, identifikator, lisens og hash	Et verktøy for kvalitetsvurdering	Om komponenter mangler
Fullstendig	Ingenting av det som gikk inn i programvaren, mangler	En sammenligning med hva bygget faktisk tok inn	Inndata sammenligningen ikke så

Identifikatoren i andre rad er som regel en package URL eller en CPE. En fil kan bestå de to første kontrollene perfekt og likevel utelate halve programvaren.

Hvorfor fullstendighet er vanskelig å måle i etterkant

En skanner tar utgangspunkt i lockfiler, manifester eller det ferdige resultatet. Den kan ikke vite om en pakke et post-install-skript lastet ned, en crate som er kompilert inn i en binærfil, eller et lag i baseimaget den aldri fikk se. Hver av dem er en skjult avhengighet.

Ta en Node.js-tjeneste der lockfilen oppgir 400 pakker. En av dem har et postinstall-skript som laster ned en ferdigbygd binærfil under npm ci. En SBOM generert fra package-lock.json er gyldig, hver komponent har en versjon og en package URL, og binærfilen er ikke med. Ingen kvalitetsscore flagger det, fordi ingenting i filen peker på det som mangler.

Å bygge på nytt senere avgjør heller ikke spørsmålet: med mindre bygget er et reproduserbart bygg, kan et nytt bygg ta inn noe annet enn det første.

Slik oppgir du fullstendighet ærlig

• Oppgi genereringskonteksten: om SBOM-en ble laget fra kildekoden før bygget, registrert under bygget eller laget ved å analysere resultatet i etterkant.
• Oppgi kjente hull: deler av programvaren verktøyet ikke kunne se, for eksempel vendorert kode, ferdigbygde binærfiler eller komponenter installert utenfor en pakkebehandler.
• Foretrekk en status med begrunnelse framfor en score. En fullstendighetsprosent krever et totaltall, og totaltallet er nettopp det ingen kjenner. En angivelse som «ufullstendig: jobben tillot uovervåket trafikk» kan man handle på.

Beste praksis for SBOM dekker den bredere praksisen med å oppgi hva en SBOM ikke kunne se.

Fullstendighetsstatus i CRACI

CRACI gir hver jobbs SBOM en fullstendighetsstatus, og cacher får også en. Statusene slik CRACIs dokumentasjon definerer dem:

• Complete: «CRACI observerte fullstendig grunnlag for jobben, og hver gjenopprettede cache var fullstendig.»
• Complete with connections: «Kravene ble oppfylt, men jobben brukte én eller flere egendefinerte nettverkstilkoblinger.»
• Incomplete: «CRACI identifiserte en tilstand som kan gjøre at avhengigheter mangler i SBOM-en.»
• Unavailable: «CRACI kunne ikke fullføre vurderingen av grunnlaget.»
• Not recorded: «Jobben er eldre enn rapporteringen av fullstendighet.»

CRACI kan oppgi dette fordi det ser hver jobbs trafikk til pakkekilder og derfor vet når noe kan ha gått utenom: trafikk det ikke overvåket, eller en gjenopprettet cache der den egne SBOM-en var ufullstendig. Når en jobb er ufullstendig, viser jobben årsaken, for eksempel «Unmonitored traffic was allowed». Se SBOM-generering.

Disse statusene gjelder bygg som kjører på CRACI-runnere. For en SBOM fra en leverandør, eller fra en pipeline som ikke kjører på CRACI, bruker du sammenligningene og reglene ovenfor.