SBOM-Vollständigkeit
SBOM-Vollständigkeit bedeutet, dass eine SBOM jede Komponente auf jeder Ebene aufführt, die in die beschriebene Software eingeflossen ist, nicht nur, dass die Datei gültig ist.
Zuletzt aktualisiert: 11. November 2026
Eine SBOM ist vollständig, wenn sie jede Komponente aufführt, die in die beschriebene Software eingeflossen ist, auf jeder Ebene des Abhängigkeitsbaums, auch Komponenten, die in keinem Lockfile oder Manifest stehen. SBOM-Vollständigkeit ist genau diese Eigenschaft. Die 2026 Minimum Elements der CISA verlangen von SBOM-Autoren, ausdrücklich anzugeben, wenn Informationen unbekannt sind, und halten fest, dass Empfänger eine SBOM als unvollständig betrachten können, wenn wesentliche Komponentendaten zurückgehalten werden.
Vollständigkeit, Gültigkeit und Qualität sind verschiedene Dinge
| Frage | Was sie bedeutet | Was sie prüft | Was sie nicht sagen kann |
|---|---|---|---|
| Gültig | Die Datei entspricht dem Schema von CycloneDX oder SPDX | Ein Schema-Validator | Ob Komponenten fehlen |
| Feldqualität | Jede Komponente hat Name, Version, Lieferant, Kennung, Lizenz und Hash | Ein Qualitätsscorer | Ob Komponenten fehlen |
| Vollständig | Nichts, was in die Software eingeflossen ist, fehlt | Ein Abgleich mit dem, was der Build tatsächlich aufgenommen hat | Eingaben, die der Abgleich nicht gesehen hat |
Die Kennung in der zweiten Zeile ist meist eine Package URL oder eine CPE. Eine Datei kann die ersten beiden Prüfungen tadellos bestehen und trotzdem die halbe Software auslassen.
Warum sich Vollständigkeit hinterher schwer messen lässt
Ein Scanner arbeitet mit Lockfiles, Manifesten oder dem fertigen Ergebnis. Er kann nichts wissen von einem Paket, das ein Post-Install-Skript heruntergeladen hat, von einem in ein Binary kompilierten Crate oder von einem Layer des Basis-Images, den er nie zu sehen bekam. Jedes davon ist eine versteckte Abhängigkeit.
Nehmen Sie einen Node.js-Dienst, dessen Lockfile 400 Pakete aufführt. Eines davon hat ein postinstall-Skript, das während npm ci ein vorkompiliertes Binary herunterlädt. Eine aus package-lock.json erzeugte SBOM ist gültig, jede Komponente hat eine Version und eine Package URL, und das Binary fehlt. Kein Qualitätsscore meldet das, weil nichts in der Datei auf das Fehlende hinweist.
Ein späterer Neubau klärt die Frage auch nicht: Solange der Build kein reproduzierbarer Build ist, kann ein zweiter Build etwas anderes aufnehmen als der erste.
Wie man Vollständigkeit ehrlich angibt
- Nennen Sie den Entstehungskontext: ob die SBOM vor dem Build aus dem Quellcode erstellt, während des Builds aufgezeichnet oder danach durch Analyse des Ergebnisses erzeugt wurde.
- Führen Sie bekannte Lücken auf: Teile der Software, die das Tool nicht sehen konnte, etwa vendorten Code, vorkompilierte Binaries oder außerhalb eines Paketmanagers installierte Komponenten.
- Bevorzugen Sie einen Status mit Gründen gegenüber einem Score. Ein Vollständigkeitsprozentsatz braucht eine Gesamtzahl, und genau die kennt niemand. Eine Angabe wie „unvollständig: Der Job ließ nicht überwachten Verkehr zu“ ist umsetzbar.
SBOM Best Practices behandelt die übergreifende Praxis, anzugeben, was eine SBOM nicht sehen konnte.
Vollständigkeitsstatus in CRACI
CRACI gibt der SBOM jedes Jobs einen Vollständigkeitsstatus, und auch Caches erhalten einen. Die Status, wie sie die Dokumentation von CRACI definiert:
- Complete: „CRACI hat vollständige Nachweise für den Job beobachtet, und jeder wiederhergestellte Cache war vollständig.“
- Complete with connections: „Die Anforderungen sind erfüllt, aber der Job hat eine oder mehrere benutzerdefinierte Netzwerkverbindungen genutzt.“
- Incomplete: „CRACI hat eine Bedingung festgestellt, durch die Abhängigkeiten in der SBOM fehlen könnten.“
- Unavailable: „CRACI konnte die Auswertung der Nachweise nicht abschließen.“
- Not recorded: „Der Job stammt aus der Zeit vor der Vollständigkeitsangabe.“
CRACI kann das angeben, weil es den Verkehr jedes Jobs zu Paketquellen sieht und deshalb weiß, wann etwas an ihm vorbeigegangen sein könnte: Verkehr, den es nicht überwacht hat, oder ein wiederhergestellter Cache, dessen eigene SBOM unvollständig war. Ist ein Job unvollständig, zeigt er den Grund an, zum Beispiel „Unmonitored traffic was allowed“. Siehe SBOM-Erzeugung.
Diese Status gelten für Builds, die auf CRACI-Runnern laufen. Für eine SBOM von einem Zulieferer oder aus einer Pipeline, die nicht auf CRACI läuft, nutzen Sie die oben beschriebenen Abgleiche und Regeln.