SBOM-volledigheid

Een SBOM is volledig wanneer ze elk component vermeldt dat in de beschreven software is gegaan, op elk niveau van de afhankelijkheidsboom, inclusief componenten die geen lockfile of manifest vermeldt. SBOM-volledigheid is die eigenschap. De 2026 Minimum Elements van CISA vragen SBOM-auteurs om expliciet te vermelden wanneer informatie onbekend is, en merken op dat ontvangers een SBOM als onvolledig kunnen beschouwen als essentiële componentgegevens worden achtergehouden.

Volledigheid, geldigheid en kwaliteit zijn verschillende dingen

Vraag	Wat het betekent	Wat het controleert	Wat het niet kan zeggen
Geldig	Het bestand voldoet aan het schema van CycloneDX of SPDX	Een schemavalidator	Of er componenten ontbreken
Veldkwaliteit	Elk component heeft een naam, versie, leverancier, identificator, licentie en hash	Een kwaliteitsscorer	Of er componenten ontbreken
Volledig	Er ontbreekt niets van wat in de software is gegaan	Een vergelijking met wat de build werkelijk binnenkreeg	Invoer die de vergelijking niet zag

De identificator in de tweede rij is meestal een package URL of een CPE. Een bestand kan de eerste twee controles perfect doorstaan en toch de helft van de software weglaten.

Waarom volledigheid achteraf moeilijk te meten is

Een scanner werkt met lockfiles, manifesten of de afgeronde uitvoer. Hij kan niets weten van een pakket dat een post-installscript heeft gedownload, een crate die in een binary is gecompileerd, of een laag van de base image die hij nooit te zien kreeg. Elk daarvan is een verborgen afhankelijkheid.

Neem een Node.js-service waarvan de lockfile 400 pakketten vermeldt. Een daarvan heeft een postinstall-script dat tijdens npm ci een vooraf gebouwde binary downloadt. Een SBOM die uit package-lock.json is gegenereerd, is geldig, elk component heeft een versie en een package URL, en de binary staat er niet in. Geen kwaliteitsscore meldt dat, omdat niets in het bestand wijst op wat ontbreekt.

Later opnieuw bouwen beantwoordt de vraag evenmin: tenzij de build een reproduceerbare build is, kan een tweede build iets anders binnenkrijgen dan de eerste.

Hoe u volledigheid eerlijk vermeldt

• Vermeld de context van het genereren: of de SBOM vóór de build uit de broncode is gemaakt, tijdens de build is vastgelegd of achteraf door analyse van de uitvoer is gemaakt.
• Vermeld bekende gaten: delen van de software die het tool niet kon zien, zoals gevendorde code, vooraf gebouwde binaries of componenten die buiten een pakketbeheerder zijn geïnstalleerd.
• Geef de voorkeur aan een status met redenen boven een score. Een volledigheidspercentage vraagt om een totaal, en dat totaal is precies wat niemand kent. Een vermelding als "onvolledig: de job stond niet-gemonitord verkeer toe" is iets waar u mee verder kunt.

SBOM best practices behandelt de bredere praktijk om te vermelden wat een SBOM niet kon zien.

Volledigheidsstatussen in CRACI

CRACI geeft de SBOM van elke job een volledigheidsstatus, en caches krijgen er ook een. De statussen, zoals de documentatie van CRACI ze definieert:

• Complete: "CRACI heeft volledig bewijs voor de job waargenomen, en elke herstelde cache was volledig."
• Complete with connections: "Aan de eisen is voldaan, maar de job gebruikte een of meer aangepaste netwerkverbindingen."
• Incomplete: "CRACI heeft een situatie vastgesteld waardoor afhankelijkheden in de SBOM kunnen ontbreken."
• Unavailable: "CRACI kon de beoordeling van het bewijs niet afronden."
• Not recorded: "De job is ouder dan de volledigheidsrapportage."

CRACI kan dit vermelden omdat het het verkeer van elke job naar pakketbronnen ziet, en dus weet wanneer iets erlangs kan zijn gegaan: verkeer dat het niet monitorde, of een herstelde cache waarvan de eigen SBOM onvolledig was. Is een job onvolledig, dan toont de job de reden, bijvoorbeeld "Unmonitored traffic was allowed". Zie SBOM-generatie.

Deze statussen gelden voor builds die op CRACI-runners draaien. Voor een SBOM van een leverancier, of uit een pipeline die niet op CRACI draait, gebruikt u de vergelijkingen en regels hierboven.