SBOM-Qualitäts-Checkliste: So validieren Sie die SBOMs Ihrer Lieferanten

Die drei Ebenen der SBOM-Qualität

Ebene	Frage	Was sie prüft	Was sie nicht beantworten kann
Gültig	Lässt sich die Datei parsen, und folgt sie dem Schema des Formats und der Version, die sie angibt?	Schema-Validatoren	Ob irgendein Feld mit etwas Brauchbarem gefüllt ist
Nutzbar	Sind die Felder da, die Sie brauchen, und kann ein Tool sie verwenden: Kennungen, die zu Advisories passen, Lizenzen, Hashes, Beziehungen?	Feldprüfungen, Compliance-Profile und Qualitäts-Scores	Was in der Datei fehlt
Vollständig	Listet sie alles auf, was in der erhaltenen Software steckt?	Abgleich mit dem Build oder mit einer Analyse des gelieferten Binärcodes	Nichts, was nur die SBOM liest, kann das beantworten

Die meisten empfangenden Teams hören nach der ersten Ebene auf. „Die Datei validiert“ ist der Anfang der Prüfung, nicht ihr Ergebnis. Die dritte Ebene ist die SBOM-Vollständigkeit.

Die Frameworks in einer Minute

Nennen Sie das Framework in jeder Anforderung und jeder Rückmeldung, damit die Messlatte eine veröffentlichte ist und nicht Ihre Meinung.

• NTIA, The Minimum Elements for a Software Bill of Materials (12. Juli 2021). Sieben Datenfelder (Name des Lieferanten, Name der Komponente, Version, weitere eindeutige Kennungen, Abhängigkeitsbeziehung, Autor der SBOM-Daten, Zeitstempel), Unterstützung der Automatisierung in SPDX, CycloneDX oder SWID-Tags sowie Praktiken: Häufigkeit, Tiefe, bekannte Unbekannte, Verteilung und Bereitstellung, Zugriffskontrolle, Umgang mit Fehlern. Hashes, Lizenzen, Lebenszyklusphase und Signaturen sind als empfohlen aufgeführt, über das Minimum hinaus.
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29. Juli 2026, nach einem Entwurf vom 22. August 2025). Ersetzt die NTIA-Elemente. Verfasst von 18 Organisationen aus 14 Ländern, darunter die CISA, die NSA, das FBI, das deutsche BSI sowie METI und NCO aus Japan. Es hat 17 Datenfelder, zehn davon neu: Signatur des SBOM-Autors, Name des Datenformats, Version des Datenformats, Erzeugungskontext, Tool-Name, Tool-Version, SBOM-Version, Hashwert der Komponente, Hash-Algorithmus der Komponente und Lizenz der Komponente. Aus „Supplier Name“ wird „Component Producer“. Die Praktiken sind Abdeckung, ausdrückliche Kennzeichnung unbekannter Informationen, maschinenlesbare Daten, Umgang mit Aktualisierungen, Häufigkeit sowie Verteilung und Bereitstellung. Das Dokument formuliert jedes Element mit „should“ und sagt, dass es keine neuen Anforderungen schafft; verbindlich wird es, wenn Käufer es in Verträge schreiben.
• BSI, TR-03183-2 Version 2.1.0 (20. August 2025), Deutschland. Die strengste der drei, formuliert mit MUSS: JSON oder XML, CycloneDX 1.6 oder neuer oder SPDX 3.0.1 oder neuer, eine SBOM pro Softwareversion, rekursive Auflösung der Abhängigkeiten mit Angabe der Vollständigkeit jeder Abhängigkeitsliste, ein SHA-512-Hash jeder auslieferbaren Komponente, der Dateiname der Komponente, Vertriebslizenzen als SPDX-Kennungen sowie Package URL oder CPE, „sofern vorhanden“. Außerdem darf eine SBOM laut der Richtlinie keine Schwachstelleninformationen enthalten; die gehören in ein VEX-Dokument oder ein Advisory.
• Internationale Abstimmung. A Shared Vision of SBOM for Cybersecurity (3. September 2025) ist von 18 Organisationen aus 15 Ländern unterzeichnet. Die G7-Arbeit zu SBOMs betrifft KI-Systeme („A shared G7 vision on SBOM for AI“, 2025, und „SBOM for AI – Minimum Elements“, Mai 2026) und stellt keine Anforderungen an Embedded-SBOMs von Lieferanten.
• Automotive. Auto-ISAC hat am 11. Februar 2025 einen SBOM Informational Report veröffentlicht.

Die Checkliste

So lesen Sie die Zellen: Pflicht heißt, das Dokument sagt „muss“. Mindestelement heißt, es steht in der Mindestliste dieses Dokuments (der NTIA-Basis oder den „should“-Elementen der CISA). Empfohlen heißt, das Dokument führt es über das Minimum hinaus auf. Nicht erwähnt heißt, das Dokument verlangt es nicht. Wie Sie jede Prüfung testen und welchen Rückmeldungssatz Sie senden, folgt im nächsten Abschnitt.

Prüfungen auf SBOM-Ebene

Prüfung	Warum sie wichtig ist	NTIA 2021	CISA 2026	BSI TR-03183-2
1. Lässt sich parsen und validiert gegen das angegebene Schema	Eine Datei, die Ihre Tools nicht lesen können, ist keine SBOM	Pflicht: SPDX, CycloneDX oder SWID-Tags	Praktik: maschinenlesbares SPDX oder CycloneDX	Pflicht: JSON oder XML
2. Spezifikationsversion erreicht Ihre Untergrenze	Alte Versionen können Felder, die Sie brauchen, nicht abbilden	Nicht erwähnt	Mindestelement: Name und Version des Datenformats; veraltete Versionen vermeiden	Pflicht: CycloneDX 1.6+ oder SPDX 3.0.1+
3. SBOM-Autor	Jemand steht für den Inhalt ein	Mindestelement: „Author of SBOM Data“	Mindestelement: „SBOM Author“, die Organisation, nicht das Tool	Pflicht: „Creator of the SBOM“, E-Mail oder URL
4. Zeitstempel	Zeigt, welche SBOM aktuell ist	Mindestelement	Mindestelement	Pflicht; UTC empfohlen
5. Tool-Name und -Version	Zeigt, was die SBOM verlässlich abdecken kann	Nicht erwähnt	Mindestelement	Nicht erwähnt
6. Erzeugungskontext	Ein Quellcode-Scan und eine Build-Aufzeichnung desselben Release unterscheiden sich	Empfohlen: Lebenszyklusphase („source“, „build“, „post-build“)	Mindestelement: „before build“, „build“ oder „after build“	Kein Feld; der Inhalt muss dem entsprechen, was beim Build verfügbar war
7. SBOM-Version oder Seriennummer	Unterscheidet eine Korrektur vom Original	Nicht erwähnt	Mindestelement: „SBOM Version“	Pflicht, wenn das Format eine hat: „SBOM-URI“
8. Signatur des Autors	Zeigt, dass die Datei unverändert vom Lieferanten stammt	Empfohlen: Signieren wird angeraten	Mindestelement: „SBOM Author Signature“	Nur informativ: „idealerweise“ signiert
9. Die Komponente der obersten Ebene entspricht dem, was Sie erhalten haben	Die SBOM des falschen Release ist schlimmer als keine	Mindestelement: primäre Komponenten	Mindestelement: die Zielkomponente	Pflicht: die primäre Komponente, die Wurzel des Baums

Prüfungen auf Komponentenebene

Prüfung	Warum sie wichtig ist	NTIA 2021	CISA 2026	BSI TR-03183-2
10. Name der Komponente	Das Erste, was jeder Abgleich verwendet	Mindestelement	Mindestelement	Pflicht; der Dateiname, wenn es keinen Namen gibt
11. Version: keine Werte latest, unknown oder leer	Advisories gelten für Versionsbereiche	Mindestelement	Mindestelement; angeben, wenn unbekannt	Pflicht; das Dateidatum, wenn es keine Version gibt
12. Hersteller oder Lieferant	Unterscheidet zwei gleichnamige Komponenten und sagt, wer sie behebt	Mindestelement: „Supplier Name“	Mindestelement: „Component Producer“	Pflicht: „Component creator“, E-Mail oder URL
13. Package URL überall, wo das Ökosystem eine hat, sonst CPE; beide wohlgeformt	Ohne Kennung (Package URL, CPE) lässt sich nichts mit einer Schwachstellendatenbank abgleichen	Mindestelement: „Other Unique Identifiers“, etwa CPE, SWID oder PURL, sofern vorhanden	Mindestelement: mindestens eine Kennung, etwa CPE oder PURL; alle angeben	Pflicht, sofern vorhanden: CPE oder purl
14. Hashwert und Algorithmus, passend zur erhaltenen Datei	Beweist, dass diese SBOM dieses Binary beschreibt	Empfohlen	Mindestelement: Hash des ausführbaren Artefakts, mit einem Algorithmus, den eine Stelle wie das NIST anerkennt	Pflicht: SHA-512 der auslieferbaren Komponente
15. Lizenz als SPDX-Kennungen oder -Ausdrücke, kein pauschales NOASSERTION	Ihre Lizenzfachleute beurteilen daran Copyleft und andere Pflichten	Empfohlen	Mindestelement; nach Möglichkeit SPDX-Kennungen	Pflicht: Vertriebslizenzen, vorrangig SPDX-Kennungen
16. Abhängigkeitsbeziehungen und ob die Liste vollständig ist	Zeigt, was ein verwundbares Paket nachgezogen hat und ob Sie den Lücken trauen können	Mindestelement; angeben, wenn direkte Abhängigkeiten vollständig aufgeführt sind	Mindestelement	Pflicht, mit Angabe der Vollständigkeit jeder Liste
17. Dateiname	Verknüpft den Eintrag mit einer Datei auf dem Gerät	Nicht erwähnt	Nicht erwähnt	Pflicht
18. Eigenschaften ausführbar, Archiv und strukturiert	Sagt, welche Art von Datei jede Komponente ist	Nicht erwähnt	Nicht erwähnt	Pflicht

Prüfungen der Abdeckung

Prüfung	Warum sie wichtig ist	NTIA 2021	CISA 2026	BSI TR-03183-2
19. Transitive Tiefe, nicht nur die oberste Ebene	Der meiste verwundbare Code kommt indirekt hinein	Oberste Ebene Pflicht; transitive empfohlen	Praktik Abdeckung: transitive Abhängigkeiten aufnehmen; keine Mindesttiefe	Pflicht: rekursive Auflösung
20. Bekannte Unbekannte angegeben	Einer SBOM, die ihre Lücken nennt, kann man bei dem trauen, was sie auflistet	Pflicht-Praktik	Praktik: unbekannte und zurückgehaltene Informationen gekennzeichnet	Pflicht über die Vollständigkeitsangabe
21. Eine SBOM pro gelieferter Softwareversion	Es zählt die Version, die Sie einsetzen	Pflicht: eine neue SBOM für jeden Build oder jedes Release	Praktik: Häufigkeit	Pflicht
22. Korrekturen als neue SBOM gesendet	Ein stillschweigend behobener Fehler lässt sich nicht nachvollziehen	Praktik: Umgang mit Fehlern	Praktik: Umgang mit Aktualisierungen	Pflicht: eine aktualisierte SBOM, wenn Fehler korrigiert werden
23. Plausibilität: keine Duplikate, eine zum Produkt passende Komponentenzahl, Betriebssystempakete bei einem Linux-basierten Gerät vorhanden	Die günstigste Stichprobe der Vollständigkeit	Nicht erwähnt	Praktik Abdeckung: mehrere Instanzen getrennt aufgeführt	Mehrere Instanzen müssen getrennt aufgeführt werden

So testen Sie jede Prüfung und was Sie dem Lieferanten sagen

Prüfung	Wie Sie sie automatisch testen	Rückmeldungssatz für den Lieferanten
1, 2. Schema und Spezifikationsversion	Ein Schema-Validator für das angegebene Format und die Version; dann specVersion (CycloneDX) oder die SPDX-Version mit Ihrer Untergrenze vergleichen	„Die Datei besteht die Schema-Validierung für CycloneDX 1.6 an den aufgeführten Pfaden nicht. Bitte erzeugen Sie sie mit einem Generator neu und validieren Sie sie vor dem Versand.“
3 bis 7. Autor, Zeitstempel, Tool, Kontext, Version	Erforderliche Metadaten vorhanden: in CycloneDX metadata.authors, metadata.timestamp, metadata.tools, metadata.lifecycles, serialNumber und version; in SPDX die Creation Information	„Die SBOM nennt weder das Tool, das sie erzeugt hat, noch den Erzeugungskontext. Beides sind Minimum Elements der CISA 2026.“
8. Signatur	Eine Signatur ist vorhanden und lässt sich mit dem vom Lieferanten veröffentlichten Schlüssel verifizieren	„Bitte signieren Sie die SBOM oder senden Sie eine separate Signatur, wie es das CISA-2026-Element SBOM Author Signature beschreibt.“
9. Komponente der obersten Ebene	Name und Version von metadata.component (CycloneDX) oder dem beschriebenen Wurzelelement (SPDX) entsprechen der Teilenummer und Softwareversion, die Sie erhalten haben	„Diese SBOM beschreibt Version 5.2.0; wir haben 5.3.0 erhalten. Bitte senden Sie die SBOM für 5.3.0.“
10, 11. Name und Version	Keine leeren Namen; keine leeren Versionen und keine mit latest oder unknown, außer als unbekannt deklariert	„14 Komponenten haben keine Version. Bitte geben Sie die genaue Version an oder kennzeichnen Sie sie als unbekannt.“
12. Hersteller	Ein Lieferant, Hersteller oder Autor bei jeder Komponente	„Die Komponenten haben keinen Hersteller, den das CISA-2026-Element Component Producer verlangt.“
13. Kennungen	Jede purl lässt sich mit einer Package-URL-Bibliothek nach ECMA-427 parsen; jede CPE hat gültige CPE-2.3-Syntax und steht im CPE-Wörterbuch der NVD	„Keine Komponente hat eine Package URL oder CPE, daher lässt sich keine mit Schwachstellendatenbanken abgleichen. Bitte ergänzen Sie eine purl für jedes Paket aus einem Paketmanager.“
14. Hashes	Ein SHA-512-Eintrag bei jeder auslieferbaren Komponente; sha512sum der erhaltenen Datei berechnen und vergleichen	„Die SBOM enthält keine Hashes. BSI TR-03183-2 verlangt den SHA-512 jeder auslieferbaren Komponente.“
15. Lizenzen	Lizenz-IDs oder -Ausdrücke, die sich gegen die SPDX-Lizenzliste auflösen lassen; NOASSERTION und leere Werte zählen	„92 % der Komponenten tragen NOASSERTION als Lizenz. Bitte geben Sie SPDX-Lizenzkennungen an.“
16. Abhängigkeiten	Ein dependencies-Graph (CycloneDX) oder Abhängigkeitsbeziehungen (SPDX); eine Vollständigkeitsangabe, etwa CycloneDX compositions mit einem aggregate-Wert	„Die SBOM ist eine flache Liste. Bitte nehmen Sie die Abhängigkeitsbeziehungen auf und geben Sie an, ob jede Liste vollständig ist.“
17, 18. Dateiname und Dateieigenschaften	Die Eigenschaften, die BSI TR-03183-2 für jedes Format definiert, sind vorhanden	„Bitte ergänzen Sie den Dateinamen und die Eigenschaften ausführbar, Archiv und strukturiert, wie es BSI TR-03183-2 v2.1.0 verlangt.“
19 bis 23. Abdeckung	Tiefe des Abhängigkeitsgraphen, Erkennung von Duplikaten, Komponentenzahl im Vergleich mit ähnlichen Produkten, erwartete Komponenten nach Produkttyp	„Die SBOM listet für ein Linux-basiertes Display weder Kernel noch Bootloader noch Basissystempakete. Bitte senden Sie die SBOM des vollständigen Images.“

Die Prozentwerte und Zahlen in den Rückmeldungssätzen sind Beispiele. Setzen Sie die echten Zahlen ein und nennen Sie jedes Mal Framework und Version.

Was auch ein guter Score übersieht

Eine Datei kann validieren, 9 von 10 Punkten erreichen und trotzdem das halbe Produkt auslassen. Qualitäts-Scores lesen die Felder, die vorhanden sind; die Komponenten, die fehlen, sehen sie nicht.

Beispiel aus der Praxis. Ein Lieferant sendet die SBOM eines Linux-basierten Displays. Sie ist gültiges CycloneDX 1.6, jede Komponente hat eine Version, eine Package URL, eine Lizenz und einen SHA-512-Hash, und der Abhängigkeitsgraph ist wohlgeformt. Sie listet die Display-Anwendung und 40 Bibliotheken. Den Linux-Kernel, den Bootloader und alle Basissystempakete listet sie nicht. Jede Feldprüfung besteht. Für Kernel-CVEs, auf die ein Linux-Gerät überwacht werden muss, ist die SBOM nutzlos, weil der Kernel nicht darin steht.

So kann ein empfangendes Team die Vollständigkeit prüfen:

• Mit einer Binäranalyse der gelieferten Firmware vergleichen. Manche OEMs nutzen sie als Ersatz-SBOM, bis die SBOM des Lieferanten gut genug ist, und danach als Gegenprobe.
• Nach erwarteten Komponenten je Produkttyp suchen. Ein Linux-Image hat einen Kernel, eine C-Bibliothek und ein Init-System; eine Industriesteuerung hat ihre Protokollstacks.
• Nach Erzeugungskontext und Tool fragen. Ein Quellcode-Scan sieht nicht, was der Build geladen hat.
• Fragen, ob die SBOM aus dem Build stammt, der die erhaltene Software erzeugt hat. Diese Frage entscheidet über die dritte Ebene.

Kleine SBOMs können berechtigt sein. Ein Bare-Metal-Steuergerät mit proprietärer Firmware und einer Kalibrierung des Herstellers hat vielleicht tatsächlich nur zwei Komponenten. Akzeptieren Sie das, wenn die SBOM es sagt und ihre bekannten Unbekannten nennt, statt sie für ihre Größe abzustrafen.

Tools, die die Prüfungen automatisieren

Auf GitHub geprüft am 11. November 2026. Keines dieser Repositories ist archiviert.

Tool	Was es prüft	Was es nicht prüft	Stand
CycloneDX CLI	Schema-Validierung von CycloneDX 1.0 bis 1.7, JSON oder XML; --fail-on-errors für CI	SPDX, Feldqualität, Framework-Profile	v0.33.1, Juli 2026
sbom-utility	Schema-Validierung von CycloneDX 1.2 bis 1.7 und SPDX 2.1 bis 2.3 JSON, mit eigenen Schema-Varianten	SPDX 3, XML, Framework-Profile	v0.19.2, Juni 2026
SPDX tools-java	Verify für SPDX 2.0 bis 2.3 und 3.0.1	CycloneDX, Framework-Profile	v2.0.7, Juni 2026
SPDX tools-python	pyspdxtools -i: vollständige Validierung von SPDX 2.2 und 2.3	Das Lesen von SPDX 3, dessen Unterstützung experimentell ist	v0.8.5, März 2026
SPDX NTIA Conformance Checker	SPDX 2.2, 2.3 und 3.0 gegen NTIA 2021, CISA FSCT3 und BSI TR-03183-2 v2.1.0; auch als Webversion	CycloneDX; CISA 2026 ist eine offene Anfrage	v6.0.0, Oktober 2026
sbomqs	Ein score von 0 bis 10 über Identifikation, Provenienz, Integrität, Vollständigkeit, Lizenzierung, Schwachstellen und Struktur; compliance-Profile für CISA 2026, NTIA 2021, BSI TR-03183-2 v1.1 bis v2.1.0, FSCT v3 und OpenChain Telco	Fehlende Komponenten erkennen	v2.1.3, Oktober 2026; CISA-2026-Profil seit v2.1.0, korrigiert in v2.1.2
sbom-scorecard	Ein gewichteter Score aus Spezifikationskonformität, Erzeugungsinformationen sowie Paketkennungen, Versionen und Lizenzen	Framework-Profile	0.0.7, April 2023, das letzte Release

Bisher prüft nur sbomqs die Minimum Elements der CISA 2026. Lesen Sie die Release Notes jedes Tools, bevor Sie sich auf ein Profil verlassen: In sbomqs 2.1.1 lief mit dem CISA-2026-Flag versehentlich die Prüfung von 2021. Für BSI TR-03183-2 v2.1.0 in sbomqs verwenden Sie --bsi-v21 oder --bsi; --bsi-v2 prüft v2.0.0.

Ein minimaler Eingangsschritt für die CycloneDX-SBOM eines Lieferanten:

# 1. Valid: fail the intake on schema errors
cyclonedx-cli validate --input-file supplier-sbom.json --input-format json --fail-on-errors

# 2. Usable: run the profile your requirement names
sbomqs compliance --bsi-v21 supplier-sbom.json
sbomqs compliance --ntia supplier-sbom.json   # CISA 2026 Minimum Elements

# 3. Track field quality over time
sbomqs score supplier-sbom.json

# 4. The hash in the SBOM matches the file you received
sha512sum firmware-5.3.0.bin

Für SPDX verwenden Sie sbomcheck -s spdx3 -c bsi supplier-sbom.json aus dem NTIA Conformance Checker. Lesen Sie den Compliance-Bericht und weisen Sie die Datei bei den Prüfungen zurück, die Ihre Anforderung verbindlich macht; senden Sie sie mit den Rückmeldungssätzen oben an den Lieferanten zurück.

In die Lieferantenanforderungen schreiben

Eine Checkliste, die der Lieferant nie gesehen hat, ist keine Anforderung. Nehmen Sie sie in den Vertragsanhang auf:

• Framework und Version: zum Beispiel „BSI TR-03183-2 v2.1.0“ oder „CISA 2026 Minimum Elements“. Nennen Sie eines; schreiben Sie nicht „Industriestandard“.
• Format und Mindestversion der Spezifikation: zum Beispiel CycloneDX 1.6 oder neuer oder SPDX 3.0.1 oder neuer, JSON.
• Die Felder, die Sie zusätzlich verlangen, etwa SHA-512-Hashes oder Package URLs für jedes Paket.
• Lieferung: eine SBOM pro gelieferter Softwareversion, vor oder mit der Software.
• Die Validierung, die der Lieferant vor dem Versand ausführt, benannt nach Tool und Profil.
• Der Rückmeldungsweg: wer die Rückmeldung erhält und wie schnell eine korrigierte SBOM fällig ist.

Die Seite des Lieferanten in derselben Vereinbarung steht im SBOM-Leitfaden für Lieferanten. Für einen Softwareanbieter, der eine einmalige Anfrage beantwortet, siehe SBOM-Anfragen von Kunden.

Eine fehlerhafte SBOM korrigieren (für Lieferanten)

• Handgeschriebene Dateien. Verwenden Sie einen Generator oder eine SBOM-Bibliothek, nie einen Texteditor.
• Fehlende Package URLs. Erzeugen Sie sie aus dem Paketmanager oder dem Build, nicht von Hand. Eine abgetippte purl ist eine geratene purl.
• Fehlende Lizenzen. Übernehmen Sie die deklarierte Lizenz aus den Paketmetadaten, als SPDX-Kennung.
• Keine Hashes. Berechnen Sie sie am Ende des Builds über die Dateien, die Sie tatsächlich ausliefern.
• Das falsche Release. Erzeugen Sie die SBOM im Release-Build und benennen Sie sie nach der Version.
• Nur die oberste Ebene. Verwenden Sie eine Methode, die transitive Abhängigkeiten auflöst.

Am zuverlässigsten beheben Sie Vollständigkeit und Kennungen zusammen, indem Sie die SBOM aus dem Build erzeugen, der die gelieferte Software hergestellt hat. Siehe SBOMs zur Build-Zeit und SBOM Best Practices.

Woher gute SBOMs kommen und wo CRACI passt

Für Lieferanten, die auf GitHub Actions bauen, ersetzt CRACI die GitHub-gehosteten Runner und zeichnet die SBOM während des Builds auf. Sie listet also, was der Build tatsächlich geladen hat.

• Jedes Paket mit einer Package URL und jede Komponente mit ihrer deklarierten Lizenz.
• Transitive Abhängigkeiten, auf jeder Ebene, die der Build erreicht hat.
• Ein Vollständigkeitsstatus für jeden Job, der die Frage nach den bekannten Unbekannten pro Build beantwortet: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded.
• Export als CycloneDX oder SPDX; die SBOM-API liefert CycloneDX 1.7 JSON.

Für eine ganze Engineering-Organisation siehe SBOM-Generierung standardisieren, und für Embedded Linux warum Scanner übersehen, was in Yocto-Builds steckt.

Für OEMs: SBOMs von Drittanbietern lassen sich zu CRACI hinzufügen, sodass zugekaufte Komponenten zusammen mit Ihren eigenen Builds auf neue Schwachstellen überwacht werden. Wie das im Vergleich abschneidet, zeigt SBOM-Management-Tools.

Wann CRACI nicht die Antwort ist

• Die SBOMs, die Sie erhalten, validieren und bewerten. CRACI bietet keinen SBOM-Validator und keinen Qualitäts-Score. Verwenden Sie die Tools oben.
• Lieferanten ohne CI oder solche, deren Code von modellbasierten Tools ohne Paketabrufe erzeugt wird. Ein Build-Recorder bringt dort wenig; eine validierte SBOM aus einer Generator-Bibliothek ist die realistische Antwort.
• Firmware, die Sie nur als Binary erhalten. Das beantwortet eine Binäranalyse.
• Signierte SBOMs, die Autorensignatur der CISA 2026. CRACI signiert keine SBOMs.

SBOM-Qualität und -Validierung: häufig gestellte Fragen

Wie prüfe ich die Qualität einer SBOM, die ein Lieferant geschickt hat?

Prüfen Sie drei Ebenen. Validieren Sie die Datei gegen ihr Schema, prüfen Sie die Felder gegen ein benanntes Framework wie BSI TR-03183-2 oder die CISA 2026 Minimum Elements und prüfen Sie dann die Vollständigkeit: Vergleichen Sie sie mit einer Binäranalyse dessen, was Sie erhalten haben, und suchen Sie nach den Komponenten, die der Produkttyp enthalten muss.

Welche Felder muss eine SBOM enthalten?

Das hängt vom Framework ab, das Sie nennen. Die CISA 2026 Minimum Elements führen 17 Felder auf, darunter Autor, Zeitstempel, Tool, Erzeugungskontext und pro Komponente Name, Version, Hersteller, Kennungen, Hash und Lizenz. BSI TR-03183-2 ergänzt einen SHA-512-Hash, den Dateinamen und Dateieigenschaften und macht sie verbindlich.

Was hat sich zwischen den NTIA-Mindestelementen und den CISA 2026 Minimum Elements geändert?

Die CISA-Liste von 2026 ersetzt die sieben NTIA-Felder durch 17. Neu sind die Autorensignatur, Name und Version des Datenformats, der Erzeugungskontext, Tool-Name und -Version, die SBOM-Version, Hashwert und Algorithmus der Komponente sowie die Lizenz der Komponente. Aus Supplier Name wurde Component Producer, aus Tiefe wurde Abdeckung.

Was verlangt BSI TR-03183-2 in einer SBOM?

Version 2.1.0 verlangt CycloneDX 1.6+ oder SPDX 3.0.1+ in JSON oder XML, eine SBOM pro Softwareversion, rekursive Abhängigkeiten mit Angabe ihrer Vollständigkeit und pro Komponente Ersteller, Name, Version, Dateiname, Lizenzen, SHA-512-Hash und Dateieigenschaften, dazu eine Package URL oder CPE, sofern vorhanden.

Braucht eine SBOM Hashes? Mit welchem Algorithmus?

Die NTIA hat sie empfohlen; CISA 2026 macht den Hash zum Mindestelement, mit einem Algorithmus, den eine Stelle wie das NIST anerkennt; BSI TR-03183-2 verlangt SHA-512 jeder auslieferbaren Komponente. Fordern Sie SHA-512 an und vergleichen Sie ihn mit der Datei, die Sie erhalten haben.

Brauche ich sowohl eine CPE als auch eine PURL?

Nicht immer. Fordern Sie eine Package URL überall an, wo das Ökosystem eine hat, und eine CPE dort, wo nicht, wie bei vielen kommerziellen oder Embedded-Komponenten. CISA 2026 verlangt mindestens eine Kennung und alle, die bekannt sind; das BSI verlangt jede, sofern vorhanden.

Wie validiere ich eine CycloneDX- oder SPDX-Datei?

Für CycloneDX mit cyclonedx-cli validate und --fail-on-errors oder mit sbom-utility. Für SPDX mit dem Verify-Befehl von SPDX tools-java oder mit pyspdxtools für SPDX 2.2 und 2.3. Danach führen Sie ein Framework-Profil mit sbomqs oder dem SPDX NTIA Conformance Checker aus.

Was ist ein guter SBOM-Qualitäts-Score?

Es gibt keinen Standard-Schwellenwert und keinen Benchmark, den wir zitieren würden. Ein Score misst die vorhandenen Felder, nicht die Vollständigkeit: Eine Datei kann 9 von 10 Punkten erreichen und das halbe Produkt auslassen. Legen Sie stattdessen in Ihrer Lieferantenanforderung Bestehenskriterien pro Prüfung fest und verfolgen Sie den Score als Trend.