CycloneDX oder SPDX? Das richtige SBOM-Format wählen
Auf dieser Seite
Zwei offene Standards teilen sich fast alle Software-Stücklisten: CycloneDX und SPDX. Beide sind international anerkannt, beide werden von jedem ernsthaften Werkzeug gelesen, und beide werden für den Cyber Resilience Act akzeptiert, der nur ein gängiges, maschinenlesbares Format verlangt. Die Wahl ist weniger wichtig, als für jede Version eine vollständige SBOM zu erstellen. Trotzdem kommen sie aus verschiedenen Richtungen, und die Unterschiede sind für manche Zwecke wichtig.
Wenn SBOMs neu für Sie sind, beginnen Sie mit Was ist eine SBOM?.
Auf einen Blick
| CycloneDX | SPDX | |
|---|---|---|
| Träger | OWASP und Ecma International (TC54) | Linux Foundation |
| Beginn | 2017, für Anwendungssicherheit | 2010, für Open-Source-Lizenz-Compliance |
| Formaler Standard | ECMA-424 (1. Ausgabe: Version 1.6, 2. Ausgabe: Version 1.7) | ISO/IEC 5962:2021 (Version 2.2.1) |
| Aktuelle Version | 1.7 (Oktober 2025) | 3.0.1 (Dezember 2024) |
| Serialisierungen | JSON, XML, Protocol Buffers | 3.x: JSON-LD; 2.x: JSON, YAML, XML, Tag-Value, RDF/XML, Tabelle |
| Über Software hinaus | Dienste (SaaS), Hardware, Firmware, ML-Modelle, Kryptografie, Fertigung | Profile für Sicherheit, KI, Datensätze, Builds, Lizenzen |
| Schwachstellen und VEX | Eingebaut | Sicherheitsprofil (3.x); meist ein separates VEX-Dokument |
| Lizenzen | SPDX-Lizenzkennungen und -Ausdrücke | Nativ, die Referenz für Lizenzdaten |
CycloneDX: für Sicherheit gebaut
CycloneDX wurde von der OWASP-Community entworfen, um eine Frage schnell zu beantworten: Welche bekannten Schwachstellen betreffen, was ich ausliefere? Sein Modell ist eine Liste von Komponenten mit ihren Kennungen (Package URL, CPE, Hashwerte), ein Abhängigkeitsgraph und optionale Abschnitte für Schwachstellen, deren Analyse und die Dienste, die ein Produkt aufruft.
Das macht es praktisch, wenn die SBOM einen Schwachstellenprozess speist. Ein CycloneDX-Dokument kann VEX-Informationen direkt enthalten: für jede Schwachstelle, ob das Produkt betroffen ist und warum. Es deckt auch mehr als Bibliotheken ab: Hardware-Stücklisten, SaaS-Dienste, Modelle für maschinelles Lernen und die kryptografischen Bestandteile eines Produkts.
SPDX: für Lizenzen gebaut, heute breiter
SPDX (Software Package Data Exchange) begann als Weg, Lizenzinformationen über Open-Source-Pakete auszutauschen, und ist dort die Referenz geblieben: Die SPDX-Lizenzkennungen (MIT, Apache-2.0, GPL-3.0-only) werden überall verwendet, auch in CycloneDX. Seine Versionen 2.x beschreiben Pakete, Dateien und Ausschnitte mit ihren Lizenzen, Urheberrechten und Beziehungen.
SPDX 3.0, 2024 veröffentlicht, hat das Modell um Elemente und Beziehungen neu aufgebaut, mit Profilen: Sicherheit (Schwachstellen und VEX-Beziehungen), KI und Datensätze, Build sowie ein „Lite“-Profil für das Minimum. Die Werkzeuge für 3.x holen gegenüber 2.3 noch auf, das viele Generatoren standardmäßig erzeugen.
Was der CRA und die Behörden akzeptieren
Der CRA nennt kein Format. Das BSI, dessen Technische Richtlinie TR-03183-2 (Version 2.1, August 2025) die bisher ausführlichste Auslegung ist, akzeptiert CycloneDX ab 1.6 und SPDX ab 3.0.1, in JSON oder XML. Die US-Mindestelemente (NTIA, heute CISA) nennen ebenfalls beide. Egal was Sie wählen: Eine Behörde schaut auf den Inhalt, also jede Komponente mit Version, Lieferant und eindeutiger Kennung, die Abhängigkeiten und eine SBOM für jede Version.
Welches wählen
- Sie wollen vor allem Schwachstellenmanagement und den CRA: CycloneDX. VEX passt in dieselbe Datei, die Sicherheitswerkzeuge sind am ausgereiftesten, und 1.6 erfüllt heute die Mindestanforderung des BSI.
- Ihre Rechtsabteilung arbeitet für Lizenzen bereits mit SPDX, oder ein Kunde verlangt es: SPDX, idealerweise 3.0.1, sobald Ihre Werkzeuge es unterstützen (2.3, noch das häufigste, erfüllt die Richtlinie des BSI nicht).
- Sie verkaufen an viele Kunden: Erstellen Sie eines und exportieren Sie das andere. Eine Umwandlung ist möglich, mit etwas Detailverlust, weil sich die beiden Modelle nicht Feld für Feld entsprechen.
Wichtiger als das Format ist:
- Die SBOM im Build zu erzeugen, für jede Version, nie von Hand.
- Jeder Komponente eine Package URL zu geben, damit sie mit Schwachstellendatenbanken abgeglichen werden kann.
- Transitive Abhängigkeiten aufzuführen, nicht nur direkte.
- Die Datei vor dem Veröffentlichen oder Archivieren gegen das offizielle Schema zu validieren.
Sie können eine CycloneDX- oder SPDX-Datei in unserem kostenlosen SBOM-Viewer und -Prüfer öffnen, um ihre Komponenten zu sehen und was fehlt.
Werkzeuge zum Erzeugen und Umwandeln
Die meisten Generatoren schreiben beides: Syft, Trivy und cdxgen erzeugen CycloneDX und SPDX (cdxgen schreibt SPDX 3.0.1); das sbom-tool von Microsoft konzentriert sich auf SPDX; die CycloneDX-Build-Plugins für Maven, Gradle, npm, .NET und Python schreiben CycloneDX. GitHub kann den Abhängigkeitsgraphen eines Repositorys als SPDX exportieren. Für Umwandlung und Validierung sind die CycloneDX CLI und die SPDX-Werkzeuge die Referenzen, und das OpenSSF-Projekt protobom wandelt über ein neutrales Modell zwischen beiden um.
Wie Provetry hilft
Provetry schreibt die SBOM jeder Version in CycloneDX 1.6 in allen Tarifen sowie in SPDX 2.3 und SPDX 3.0.1 in den kostenpflichtigen Tarifen, aus Ihrer CI oder aus den hochgeladenen Lock-Dateien, und bewahrt jede bei ihrer Version auf.