Das SBOM-Qualitätsproblem: Existenz ≠ Nützlichkeit
Eine SBOM zu erzeugen ist inzwischen trivial. Ein einziger Befehl mit Syft, Trivy oder einem vergleichbaren Tool genügt, um eine JSON-Datei zu produzieren, die formal als Software Bill of Materials durchgeht. Genau das ist das Problem.
In der Praxis sehen viele dieser SBOMs erschreckend ähnlich aus: Hunderte von Komponenten ohne Versionsnummer, fehlende Lizenzfelder, keine Package URLs (PURLs), keine Angaben zu Abhängigkeitsbeziehungen. In einem realen Audit-Fall enthielt eine SBOM eines mittelgroßen Softwareanbieters 312 Komponenten – davon hatten 67 % keine gültige PURL, 41 % keine Lizenzangabe, und transitive Abhängigkeiten fehlten vollständig. Das Dokument existierte, war aber für Vulnerability Management, Legal Review oder Lieferkettenanalyse praktisch wertlos.
Dieses Muster ist kein Einzelfall. Solange SBOM-Erzeugung als Checkbox-Aktivität verstanden wird – erzeugt für Compliance, abgelegt im Repository, nie wieder angefasst – bleibt die eigentliche Nutzenstiftung aus. Der erste Schritt zur Verbesserung ist, Qualität messbar zu machen.
Qualitätsdimensionen: Was macht eine SBOM wirklich gut?
Als konzeptioneller Rahmen haben sich fünf Qualitätsdimensionen etabliert, die sich aus den NTIA-Mindestanforderungen, den CISA-Empfehlungen sowie der deutschen BSI-Technischen Richtlinie TR-03183-2 ableiten lassen:
Completeness beschreibt, ob alle relevanten Komponenten – inklusive transitiver Abhängigkeiten – erfasst sind. Eine SBOM, die nur direkte Dependencies enthält, bildet in modernen Software-Stacks oft weniger als 30 % der tatsächlich ausgelieferten Pakete ab.
Accuracy fragt, ob die enthaltenen Informationen korrekt sind: stimmen Versionen, Hashes, Identifier mit dem tatsächlich verwendeten Artefakt überein?
Depth betrifft die Reichhaltigkeit der Metadaten je Komponente – Lizenz, Copyright, Supplier, Hash-Werte, PURL, CPE.
Freshness adressiert das Alter der SBOM: Entspricht sie dem aktuellen Build-Stand, oder wurde sie zuletzt vor sechs Monaten generiert?
Machine-Readability schließlich beschreibt, ob das Dokument in einem standardisierten Format vorliegt und von Tools automatisch verarbeitbar ist – ohne manuelle Interpretation.
Diese fünf Dimensionen bilden die Grundlage für konkrete, prüfbare Metriken.
Konkrete Metriken und Schwellenwerte: SBOM-Qualität messbar machen
Für jede Dimension lassen sich Metriken definieren, die in Audits und automatisierten Pipelines operationalisierbar sind:
Completeness
- Transitive Dependency Coverage Ratio: Anteil der erfassten transitiven Abhängigkeiten gemessen an der tatsächlich installierten Paketmenge (z. B. via lock-file-Abgleich).
- ✅ Gut: > 90 % | ⚠️ Akzeptabel: 70–90 % | ❌ Ungenügend: < 70 %
Accuracy
- PURL Validity Rate: Anteil der Komponenten mit syntaktisch gültiger und auflösbarer Package URL.
- ✅ Gut: > 95 % | ⚠️ Akzeptabel: 80–95 % | ❌ Ungenügend: < 80 %
- Hash Presence Rate: Anteil der Komponenten mit mindestens einem kryptographischen Hash (SHA-256 oder stärker).
- ✅ Gut: > 90 % | ⚠️ Akzeptabel: 75–90 % | ❌ Ungenügend: < 75 %
Depth
- License Field Completeness: Anteil der Komponenten mit gültiger SPDX-konformer Lizenzangabe.
- ✅ Gut: > 95 % | ⚠️ Akzeptabel: 80–95 % | ❌ Ungenügend: < 80 %
- Supplier Completeness: Anteil der Komponenten mit Supplier- oder Author-Angabe.
- ✅ Gut: > 85 % | ⚠️ Akzeptabel: 60–85 % | ❌ Ungenügend: < 60 %
Freshness
- SBOM Age: Zeit seit dem letzten Build-Bezug der SBOM.
- ✅ Gut: < 7 Tage | ⚠️ Akzeptabel: 7–30 Tage | ❌ Ungenügend: > 30 Tage
Machine-Readability
- Format Compliance: Validiert gegen offizielle Schema (CycloneDX JSON Schema, SPDX 2.3 Spec).
- ✅ Gut: 0 Validierungsfehler | ❌ Ungenügend: ≥ 1 Fehler
Diese Schwellenwerte sind keine absoluten Wahrheiten, eignen sich aber als Ausgangspunkt für organisationsinterne SLAs und Lieferantenanforderungen. Dabei soll an dieser Stelle nicht unerwähnt bleiben, dass Compliance keine anteilige Bewertung kennt. Dort gilt das binäre 0 oder 1-Prinzip: Entweder compliant oder nicht. Und das mit Sicherheit nur, bei vollständiger Information
Format matters: CycloneDX vs. SPDX aus Qualitätsperspektive
Beide Standards – CycloneDX und SPDX – sind etabliert und in regulatorischen Anforderungen anerkannt. Für Qualitätssicherung sind jedoch strukturelle Unterschiede relevant.
SPDX ist ursprünglich aus dem Licensing-Use-Case entstanden und bietet hier eine sehr reife Semantik: SPDX-Lizenzausdrücke, Snippets, Copyright-Texte. Für Legal-Compliance-Workflows ist SPDX nach wie vor stark. Schwächer ist das Format bei Vulnerability-Metadaten, Build-Kontext und der nativen Abbildung komplexer Abhängigkeitsgraphen.
CycloneDX wurde von Grund auf als Security-SBOM konzipiert. Es unterstützt nativ Vulnerability Disclosure Reports (VEX), Services, Hardware-Komponenten, Cryptographic Assets und Formulas (Build-Reproduzierbarkeit). Das macht es zur besseren Grundlage für Qualitätsmetriken, die über Lizenz-Compliance hinausgehen.
Persönliche Einschätzung: Für die meisten modernen Use Cases – insbesondere Vulnerability Management, CRA-Compliance und Supply-Chain-Audits – ist CycloneDX das schlankere, ausdrucksstärkere Format. SPDX bleibt erste Wahl, wenn die primäre Anforderung Legal-Compliance und Lizenzklärung ist. Im Zweifelsfall: beide Formate parallel bereitstellen, was die meisten modernen Tools unterstützen.
Tooling für SBOM-Qualitätsbewertung: Automatisiertes Scoring in der Praxis
Ohne Tooling bleibt jede Qualitätsmetrik akademisch. Folgende Tools sind in der Praxis relevant:
sbom-scorecard (Adolfo García Veytia / Chainguard): Bewertet SBOMs nach NTIA-Mindestanforderungen und gibt einen numerischen Score zurück. Gut integrierbar in CI/CD, aber die Metriken sind relativ grob und nicht konfigurierbar.
SBOM Quality Score (Interlynk): Cloud-basiertes Tool mit differenzierteren Metriken und Dashboard-Funktionalität. Stärke liegt in der Visualisierung und im Trend-Tracking. Blinder Fleck: proprietäre Plattform, Datensensitivität bei kommerziellen SBOMs muss bewertet werden.
ts-sbom-checker (TrustSource, Open Source): Das unter github.com/trustsource/ts-sbom-checker verfügbare Tool prüft speziell die Konformität mit der BSI TR-03183-2 – damit direkt relevant für europäische Compliance-Anforderungen. Es ist CLI-basiert, leichtgewichtig und lässt sich ohne externe Abhängigkeiten in Build-Pipelines integrieren. Empfehlung für alle Teams, die sich auf den deutschen oder europäischen Markt ausrichten.
Für CI/CD-Integration gilt: Mindestens PURL Validity und Schema Compliance sollten als harte Gate-Kriterien umgesetzt sein. Freshness-Checks lassen sich über Build-Timestamps automatisieren. Eine Kombination aus ts-sbom-checker für regulatorische Konformität und sbom-scorecard für NTIA-Baseline deckt die meisten Anforderungen ab.
Audit-Ready SBOM: Eine schwellenwertbasierte Checkliste
Die folgenden Kriterien eignen sich als Pass/Fail-Framework für interne Audits, Lieferantenaudits sowie regulatorische Anforderungen (CRA, Executive Order 14028):
| Kriterium | Mindestanforderung | Empfohlen |
|---|---|---|
| Format-Validierung | 0 Schema-Fehler | CycloneDX 1.6+ oder SPDX 2.3+ |
| PURL Validity Rate | > 80 % | > 95 % |
| License Completeness | > 80 % | > 95 % |
| Hash Presence | > 75 % | > 90 % |
| Transitive Coverage | > 70 % | > 90 % |
| SBOM-Alter | < 30 Tage | < 7 Tage (pro Release) |
| TR-03183-2 Konformität | Pflicht (DE/EU) | ts-sbom-checker: 0 Fehler |
Über diese Basis hinaus eröffnet eine qualitativ hochwertige SBOM weitere Nutzungsdimensionen: Schwachstellenmanagement durch PURL-basiertes Matching gegen OSV, NVD, bzw. EUVD, Crypto Agility durch Erfassung kryptographischer Abhängigkeiten (CycloneDX unterstützt dies nativ), und Legal Compliance durch vollständige Lizenz-Metadaten für Open-Source-Obligations.
Von Compliance-Theater zu echter Nützlichkeit: Nächste Schritte
Der Übergang von formaler SBOM-Erzeugung zu echter Qualitätssicherung ist kein Tool-Problem – es ist ein Prozess- und Kulturproblem. Prozess und Denken sind in den Organisationen entsprechend zu etablieren. Neben der technischen Umsetzung ist auch die organisatorische Verankerung zu schaffen. Ein möglicher Pfad könnte so aussehen:
Kurzfristig (0–4 Wochen): Bestehende SBOMs mit sbom-scorecard oder ts-sbom-checker scannen, Baseline-Metriken erheben, die kritischsten Lücken identifizieren (typischerweise fehlende PURLs und Lizenzen).
Mittelfristig (1–3 Monate): SBOM-Generierung in CI/CD-Pipelines verankern, automatische Qualitätsgates einrichten, Verantwortlichkeit für SBOM-Qualität im Team klar benennen.
Langfristig: SBOM-Qualität als kontinuierlichen Prozess verstehen – mit regelmäßigem Review bei Abhängigkeitsänderungen, Einbindung in Lieferantenverträge und Verknüpfung mit dem Vulnerability-Management-Prozess. Qualitätsziele sukzessive erhöhen.
Organisatorisch braucht es zwei Dinge: eine Person, die Ownership für SBOM-Qualität übernimmt, und ein klares internes Qualitätsziel, das über „SBOM existiert” hinausgeht. Unserer Erfahrung nach bietet es sich auch an, im Falle unterschiedlicher Teams ein Incentive auszuloben, für das erste Team, das die gesteckten Qualitätsziele erreicht.
Drei Kernergebnisse:
- Eine SBOM ohne messbare Qualitätsmetriken ist kein Asset, sondern Compliance-Theater – PURL Validity Rate, License Completeness und Transitive Coverage sind die entscheidenden Indikatoren.
- CycloneDX ist für Security- und Supply-Chain-Use-Cases die strukturell überlegene Grundlage; für Legal-Compliance-Workflows bleibt SPDX stark.
- Tools wie ts-sbom-checker (TR-03183-2) und sbom-scorecard ermöglichen automatisiertes Scoring in CI/CD – der Engpass ist nicht Tooling, sondern organisatorisches Commitment zur kontinuierlichen Qualitätssicherung.