SBOM-fullständighet

En SBOM är fullständig när den listar varje komponent som gick in i den programvara den beskriver, på alla nivåer i beroendeträdet, även komponenter som ingen lockfile eller manifest listar. SBOM-fullständighet är just den egenskapen. CISA:s 2026 Minimum Elements ber SBOM-författare att uttryckligen ange när information är okänd, och konstaterar att mottagare kan betrakta en SBOM som ofullständig om väsentliga komponentdata hålls inne.

Fullständighet, giltighet och kvalitet är olika saker

Fråga	Vad det betyder	Vad som kontrollerar det	Vad det inte kan säga
Giltig	Filen följer CycloneDX- eller SPDX-schemat	En schemavalidator	Om komponenter saknas
Fältkvalitet	Varje komponent har namn, version, leverantör, identifierare, licens och hash	Ett kvalitetsbedömningsverktyg	Om komponenter saknas
Fullständig	Inget av det som gick in i programvaran saknas	En jämförelse med vad bygget faktiskt tog in	Indata som jämförelsen inte såg

Identifieraren i andra raden är oftast en package URL eller en CPE. En fil kan klara de två första kontrollerna perfekt och ändå utelämna halva programvaran.

Varför fullständighet är svår att mäta i efterhand

En skanner utgår från lockfiler, manifest eller det färdiga resultatet. Den kan inte känna till ett paket som ett post-install-skript laddade ner, ett crate som kompilerats in i en binär eller ett lager i basavbildningen som den aldrig fick se. Vart och ett av dem är ett dolt beroende.

Ta en Node.js-tjänst vars lockfile listar 400 paket. Ett av dem har ett postinstall-skript som laddar ner en förbyggd binär under npm ci. En SBOM som genererats från package-lock.json är giltig, varje komponent har en version och en package URL, och binären saknas. Inget kvalitetsbetyg flaggar det, eftersom inget i filen pekar på det som saknas.

Att bygga om senare avgör inte heller frågan: om bygget inte är ett reproducerbart bygge kan ett andra bygge ta in något annat än det första.

Hur du redovisar fullständighet ärligt

• Ange genereringskontexten: om SBOM:en togs fram från källkoden före bygget, registrerades under bygget eller skapades genom att analysera resultatet i efterhand.
• Lista kända luckor: delar av programvaran som verktyget inte kunde se, till exempel vendorad kod, förbyggda binärer eller komponenter som installerats utanför en pakethanterare.
• Föredra en status med skäl framför ett betyg. En fullständighetsprocent kräver en total, och den totalen är precis vad ingen känner till. En uppgift som "ofullständig: jobbet tillät oövervakad trafik" går att agera på.

Bästa praxis för SBOM tar upp den bredare praxisen att ange vad en SBOM inte kunde se.

Fullständighetsstatus i CRACI

CRACI ger varje jobbs SBOM en fullständighetsstatus, och även cachar får en. Statusarna enligt CRACI:s dokumentation:

• Complete: "CRACI observerade fullständiga underlag för jobbet, och varje återställd cache var fullständig."
• Complete with connections: "Kraven uppfylldes, men jobbet använde en eller flera anpassade nätverksanslutningar."
• Incomplete: "CRACI identifierade ett förhållande som kan göra att beroenden saknas i SBOM:en."
• Unavailable: "CRACI kunde inte slutföra utvärderingen av underlaget."
• Not recorded: "Jobbet är äldre än fullständighetsrapporteringen."

CRACI kan ange detta eftersom det ser varje jobbs trafik till paketkällor och därför vet när något kan ha gått förbi: trafik som det inte övervakade, eller en återställd cache vars egen SBOM var ofullständig. När ett jobb är ofullständigt visar jobbet skälet, till exempel "Unmonitored traffic was allowed". Se SBOM-generering.

De här statusarna gäller byggen som körs på CRACI:s runners. För en SBOM från en leverantör, eller från en pipeline som inte körs på CRACI, använder du jämförelserna och reglerna ovan.