CycloneDX vs. SPDX: Das richtige SBOM-Format für regulatorische Anforderungen (Ausgabe 2026)
| Interlynk
Ein Leitfaden für Engineering- und Compliance-Teams zu den beiden SBOM-Formaten CycloneDX und SPDX: aktuelle Versionen, ISO- und ECMA-Zertifizierung, Reife der Tools und wie Sie das passende auswählen.
Für wen ist dies bestimmt?
Eine Behörde, ein Kunde oder Ihr eigenes Sicherheitsteam fordert eine Software Bill of Materials an. Bevor Sie ein Tool wählen, müssen Sie sich für ein Format entscheiden. Es kommen zwei in Frage: CycloneDX und SPDX. Nahezu jeder Rahmen, der eine SBOM verlangt, akzeptiert beide. Genau deshalb liegt die Entscheidung bei Ihnen: Sie hängt von Ihren Tools ab und von den Menschen, die die Datei am Ende lesen.
Dieser Leitfaden vergleicht beide Formate auf dem Stand von 2026. Aktuelle Versionen, der jeweilige ursprüngliche Zweck, der Zertifizierungsstatus, die Reife der umgebenden Tools, wer den Standard pflegt und wie Sie ihn mitgestalten können. Er kürt keinen Sieger. Für die meisten regulierten Teams sind beide Formate praktikabel, und viele Organisationen erzeugen inzwischen beide. Es folgt die Detailtiefe, um zu entscheiden, was zu Ihrer Situation passt – mit den Fakten dieses Jahres statt mit Versionsnummern, die vor zwei Jahren stimmten.
Die Kurzfassung
CycloneDX ist ein OWASP-Flagship-Projekt und inzwischen ein Standard von Ecma International, ausgerichtet auf Anwendungssicherheit und Lieferkettenrisiken. SPDX ist ein Projekt der Linux Foundation und ein ISO/IEC-Standard, ausgerichtet auf Lizenz-Compliance und umfassende Transparenz der Lieferkette. Beide bilden dasselbe Kerninventar ab, beide tragen purl- und CPE-Kennungen, und die meisten Funktionsunterschiede, an die man sich erinnert, sind geschlossen. Was sie noch trennt, sind Schwerpunkt, Governance-Herkunft und die umgebenden Tools.
Hier die gesamte Gegenüberstellung auf einen Blick, vor dem Detail:
CycloneDX | SPDX | |
|---|---|---|
Trägerschaft | OWASP + Ecma TC54 | Linux Foundation (+ OMG) |
Standard | ECMA-424 (1. & 2. Ausgabe) | ISO/IEC 5962:2021 |
Aktuelle Version | 1.7 (Dez. 2025) | 3.0.1 (3.1 als RC) |
Ursprung / Fokus | 2017, Security zuerst | 2010, Lizenzen zuerst |
Datenmodell | Flach, komponentenzentriert | Element- und Beziehungsgraph |
VEX-Unterstützung | Nativ, ausgereifte Tools | Security-Profil, neuer |
Lizenzdetail | Gut | Tiefgehend, auf Dateiebene |
Kennungen | purl, CPE | purl, CPE |
Bekanntester Abnehmer | Dependency-Track, SCA-/VEX-Tools | Rechtsprüfung, GitHub, OSPO |
Betrachten Sie den Rest dieses Leitfadens als die Fußnoten zu dieser Tabelle.
Versionen und Funktionen
Versionen sind hier entscheidend. Die regulatorischen und sicherheitsbezogenen Fähigkeiten, über die diskutiert wird, kamen mit bestimmten Releases. Die falsche Version zu nennen ist der schnellste Weg, auf veralteter Grundlage zu entscheiden.
CycloneDX steht bei 1.7, veröffentlicht im Oktober 2025 und im Dezember als ECMA-424, 2. Ausgabe angenommen. Es ist das letzte Release der 1.x-Reihe und bleibt abwärtskompatibel zu 1.4 bis 1.6. Im Laufe dieser Reihe wuchs CycloneDX von einem reinen Software-SBOM-Format zu einem allgemeinen Bill-of-Materials-Standard: Hardware (HBOM), Dienste (SaaSBOM), Machine-Learning-Modelle (ML-BOM), Kryptografie (CBOM) und formale Attestierungen (CDXA). Version 1.6 brachte die Cryptographic Bill of Materials und CycloneDX Attestations. Version 1.7 ergänzte Citations für eine überprüfbare Herkunft, Metadaten zu Patenten und Patentfamilien, Weitergabebeschränkungen über Traffic-Light-Protocol-Markierungen sowie eine erweiterte Kryptografie-Registry. Als nächsten großen Schritt hat das Projekt ein API-first ausgerichtetes 2.0 signalisiert.
SPDX steht bei 3.0.1, Teil der 3.0-Reihe vom April 2024, mit einem laufenden 3.1-Release-Candidate. SPDX 3.0 hat das Fundament neu aufgebaut. Es wechselte zu einem elementbasierten Modell, in dem Pakete, Dateien, Snippets und andere Elemente eigenständig existieren und über Beziehungen verknüpft werden. Das bildet komplexe Systeme besser ab als das dokumentzentrierte 2.x-Design. Außerdem wurden Profile eingeführt, sodass ein Erzeuger nur die für einen Anwendungsfall relevanten Teile des Standards aufnehmen kann. Die Profile decken Kernkonzepte, Software, Lizenzierung, Sicherheit, Build, KI, Datensätze und Erweiterungsdaten ab; der 3.1-Kandidat reicht weiter in Sicherheit (Safety), Hardware und Dienste hinein. Für die regulatorische Arbeit ist das Security-Profil das entscheidende, denn dort erhielt SPDX die native Schwachstellen- und VEX-Unterstützung, die der 2.x-Reihe fehlte.
Eine Feinheit, über die viele stolpern: SPDX 2.3 ist nach wie vor überall im Einsatz, weil viele Tools, darunter mehrere Maven- und Build-System-Plug-ins, es weiterhin ausgeben. In der Praxis begegnen Ihnen 2.2.1, 2.3 und 3.0.1, und sie verfügen nicht über dieselben Fähigkeiten. CycloneDX zeigt weniger von dieser Streuung, dank seiner Zusage zur Abwärtskompatibilität über die gesamte 1.x-Reihe.
Hier die Versionslandschaft, der Sie tatsächlich begegnen, und was sie jeweils bedeutet:
Version | Veröffentlicht | Standardstatus | Warum sie noch zählt |
|---|---|---|---|
SPDX 2.2.1 | 2021 | ISO/IEC 5962:2021 | Die Version, die die ISO-Norm tatsächlich festschreibt |
SPDX 2.3 | 2023 | Vor 3.0 | Wird von Build-Tools weiterhin breit ausgegeben |
SPDX 3.0.1 | 2024 | Aktuell; ISO-Aktualisierung geplant | Elementmodell + Profile, natives VEX |
CycloneDX 1.6 | Juni 2024 | ECMA-424, 1. Ausgabe | Einführung von CBOM und Attestations |
CycloneDX 1.7 | Dez. 2025 | ECMA-424, 2. Ausgabe | Aktuelles 1.x; Citations, Patente, Krypto |
Zertifizierungs- und Standardisierungsstatus
Für ein regulatorisches Publikum ist dies oft der wichtigste Teil. Ein formal anerkannter Standard lässt sich in einem Audit oder einer Einreichung leichter vertreten.
SPDX war zuerst da. Es wurde als ISO/IEC 5962:2021 von ISO/IEC JTC 1 veröffentlicht, dem gemeinsamen technischen Komitee der beiden internationalen Normungsgremien. Ein Detail hinter dieser Überschrift wiegt schwerer als jede andere Aussage in diesem Leitfaden:
Die ISO-Norm schreibt SPDX 2.2.1 fest, nicht die aktuelle Spezifikation. SPDX 3.0.1 und der 3.1-Kandidat werden offen unter der Linux Foundation entwickelt, mit der Object Management Group in der Prüfschleife, und sollen als Aktualisierung bei der ISO eingereicht werden. Bis das geschieht, ist mit „ISO/IEC 5962:2021“ die Version 2.2.1 gemeint, nicht 3.0.
CycloneDX ging stattdessen über Ecma International. Version 1.6 wurde im Juni 2024 als ECMA-424, 1. Ausgabe ratifiziert; Version 1.7 wurde im Dezember 2025 zur 2. Ausgabe. Die Arbeit findet im Ecma Technical Committee 54 statt, gemeinsam mit der OWASP-Community, und der Standard erscheint unter einer lizenzgebührenfreien Patentrichtlinie. CycloneDX ist zudem ein OWASP-Flagship-Projekt, die Auszeichnung, die OWASP seiner ausgereiftesten und am breitesten verbreiteten Arbeit vorbehält.
Beide Wege führen zu einem echten, anerkannten offenen Standard. Der Unterschied ist das Gremium dahinter: SPDX trägt den ISO/IEC-Namen, auf den viele Beschaffungsprozesse in Unternehmen und Behörden direkt verweisen, während CycloneDX die Ecma-Anerkennung plus den OWASP-Flagship-Status trägt, dem Sicherheitsteams vertrauen. Bei den Regulierungen selbst schreibt derzeit keine ein Format gegenüber dem anderen vor:
Rahmenwerk | Formatanforderung | Was das für Sie bedeutet |
|---|---|---|
USA (CISA / EO 14028) | Beide als akzeptabel genannt | Beides ist vertretbar; den Abnehmer prüfen |
EU Cyber Resilience Act | SBOM erforderlich, Format offen | Nach Tools und Kunden auswählen |
FDA (Medizinprodukte) | Maschinenlesbar; auf beide verwiesen | Erwartete Version und Kodierung bestätigen |
Der Haken zeigt sich in jeder Zeile: Version und Serialisierung. Behörden und ihre Tools achten darauf, welche Version und welche Kodierung Sie übermitteln, und Einreichungen wurden schon wegen einer Format- oder Kodierungs-Diskrepanz abgewiesen, obwohl die Formatfamilie passte.
Wofür die einzelnen Formate gebaut wurden
Gehen Sie von der Person aus, die die Datei liest. Das entscheidet das Meiste.
SPDX begann 2010 als Möglichkeit, Informationen zu Open-Source-Lizenzen organisationsübergreifend einheitlich zu kommunizieren, und diese Herkunft ist bis heute spürbar. Seine eigentliche Stärke ist die präzise Dokumentation von Lizenzen und Urheberrechten auf Dateiebene – jene Nachweiskette, von der Rechtsprüfung, Beschaffung, M&A-Due-Diligence und Open Source Program Offices leben. SPDX pflegt außerdem die SPDX License List, den Standardsatz an Kennungen wie MIT und Apache-2.0, den die gesamte Branche verwendet, CycloneDX eingeschlossen. Wenn Recht und Compliance die Hauptleser sind, ist SPDX die natürliche Ausgangsbasis.
CycloneDX begann 2017 innerhalb von OWASP, mit Security an erster Stelle. Seine Stärke ist es, Sicherheitskontext gemeinsam mit dem Inventar zu transportieren: eine eigene Schwachstellenstruktur, natives VEX, Abhängigkeitsbeziehungen und die breitere xBOM-Familie für Kryptografie, Dienste und ML-Systeme. Wenn Produktsicherheit, Schwachstellenmanagement oder Incident Response die Hauptleser sind und VEX der Weg ist, wie Sie nicht erreichbares CVE-Rauschen reduzieren, fügt sich CycloneDX direkt in diesen Arbeitsablauf ein.
Das für 2026 wichtige Update: Die alte Faustregel „CycloneDX für Sicherheit, SPDX für Lizenzen“ stimmt nur noch zur Hälfte. Beide haben sich beim Kerninventar angenähert, auch wenn ihre Schwerpunkte unterschiedlich bleiben:
SPDX 3.0 ergänzte ein Security-Profil mit nativer Schwachstellen- und VEX-Unterstützung und verkürzte damit den langjährigen Sicherheitsvorsprung von CycloneDX.
CycloneDX ergänzte über 1.5 bis 1.7 reichhaltigere Lizenz- und Patentmetadaten und verkürzte damit den Lizenzvorsprung von SPDX.
Beide reichen heute weit über Software hinaus, in Hardware, Dienste, KI/ML und kryptografische Inventare.
Die Faustregel weist weiterhin in die richtige Richtung, ist aber keine harte Grenze.
Reife der Tools
Ein Format ist nur so viel wert wie die Tools, die es lesen und schreiben, und hier wird das Bild gemischt. Das ist ein wesentlicher Grund, warum sich die Ausgabe beider Formate durchgesetzt hat.
Die Erzeugung ist kaum noch ausschlaggebend, da die gängigsten Open-Source-Generatoren beide nativ ausgeben. Der Unterschied liegt nachgelagert. CycloneDX ist in Security-Tools tiefer verankert: OWASP Dependency-Track baut darauf auf, und die meisten Schwachstellenmanagement- und VEX-fähigen Triage-Systeme lesen es anstandslos. SPDX ist in Tools für Lizenz-Compliance tiefer verankert: etablierte Workflows für Rechtsprüfung und Open-Source-Compliance behandeln es als primäres Format, und GitHub erzeugt SPDX direkt aus dem Abhängigkeitsgraphen eines Repositorys.
Hinzu kommt der zeitliche Verzug bei der Versionsunterstützung. Die Unterstützung für SPDX 3.0 holt noch auf, weil 3.0 eine große Modelländerung war und ein Großteil der installierten Basis weiterhin 2.3 erzeugt. Die 1.x-Abwärtskompatibilität von CycloneDX bedeutet, dass ein 1.7-Erzeuger und ein 1.6-Abnehmer in der Regel einfach zusammenarbeiten. Eine wissenschaftliche Analyse der Open-Source-SBOM-Tool-Ökosysteme aus dem Jahr 2025 fand messbare Unterschiede darin, wie die beiden Communities mit Tool-Problemen umgehen, mit schnelleren durchschnittlichen Bearbeitungszeiten auf der CycloneDX-Seite. Lesen Sie das als Signal für die Reaktionsfreude des Ökosystems, nicht als Urteil über die Formate.
Die meisten ausgereiften Teams landen am selben Punkt: beide erzeugen. Die doppelte Ausgabe ist mit modernen Tools günstig, Konverter laufen in beide Richtungen, und beide zu erzeugen heißt, dass niemand nachgelagert nach dem fragen kann, das Sie ausgelassen haben. Eine Warnung jedoch: Die Konvertierung zwischen den Formaten kann Daten verlieren. Wenn Sie also beide brauchen, erzeugen Sie jedes aus echten Build-Metadaten, statt nachträglich das eine in das andere umzuwandeln.
Communities und Governance
If you are going to lean on a format for years, who maintains it, and how, is not a side note. It tells you how the standard will move and whether you get a say.
SPDX is an open source project under the Linux Foundation, built by a grass-roots mix of software, systems, and tool vendors alongside foundations and integrators. The work splits across technical, legal, and outreach teams, with a monthly general call and a published governance model. The 3.0 effort tightened that governance and brought the Object Management Group into the review of the model and spec, which is part of how SPDX keeps its ISO alignment.
CycloneDX is governed jointly by the OWASP Foundation and Ecma International's Technical Committee 54. OWASP joined Ecma to give CycloneDX a formal international home without giving up its open development model. The spec lives on GitHub, the schemas are the official reading of the standard, and the JSON Schema is the reference implementation. The royalty-free patent policy comes with the Ecma arrangement.
Neither standard is controlled by a single company, and neither is a closed spec you receive from a vendor and cannot touch. For something you are betting compliance on, that independence is the point.
Wie Sie sich einbringen können
Ein offener Standard bedeutet, dass Sie nicht nur Konsument sind. Wenn keines der Formate Ihren regulatorischen Bedarf ganz abdeckt, ist der Weg zur Änderung offen, und die Einstiegspunkte sind konkret:
CycloneDX | SPDX | |
|---|---|---|
Zuhause | OWASP + Ecma TC54 | Projekt der Linux Foundation |
Wo die Arbeit stattfindet | GitHub-Repositories von Ecma-TC54 und CycloneDX | SPDX-GitHub-Repos + Mailinglisten |
Wie Sie beitragen | Issues/PRs zur Spezifikation, Mitarbeit in der Core- oder Domänen-Arbeitsgruppe, Teilnahme am TC54 | Mitarbeit im technischen, rechtlichen oder Outreach-Team; Teilnahme am monatlichen allgemeinen Call |
Einstieg | cyclonedx.org | spdx.dev/participate |
Gut zu wissen | Vorschläge müssen die Abwärtskompatibilität wahren | Das Rechtsteam entscheidet über die Lizenzpräzision |
So oder so kann eine regulierte Organisation eine konkrete Anforderung direkt an die Menschen richten, die den Standard pflegen, statt darauf zu warten, dass ein Anbieter sie für unterstützenswert hält.
Die Entscheidung: Welches SBOM-Format wählen?
Entscheiden Sie danach, wer die Datei liest und warum. Drei Situationen decken die meisten Teams ab:
Beginnen Sie mit SPDX, wenn Ihr Treiber Lizenz-Compliance, rechtliche Nachweisketten, Beschaffung oder eine Anforderung ist, die ausdrücklich ISO/IEC 5962 nennt. Bestätigen Sie dann, welche Version tatsächlich erwartet wird, denn die ISO-Nummer verweist weiterhin auf 2.2.1, während die aktuelle Spezifikation 3.0.1 ist.
Beginnen Sie mit CycloneDX 1.7, wenn Ihr Treiber Security-Operations, Schwachstellenmanagement, VEX-basierte Triage ist oder Sie die breiteren xBOM-Typen wie eine Cryptographic Bill of Materials für die Post-Quanten-Bereitschaft benötigen.
Erzeugen Sie beide, wenn Sie in mehrere regulierte Märkte verkaufen und nicht steuern können, welches Format ein bestimmter Kunde oder eine Behörde verlangt. Erzeugen Sie jedes aus echten Build-Daten statt durch Konvertierung, und versionieren Sie jede Ausgabe bewusst.
Was auch immer Sie wählen, das Format ist der beständige Teil der Entscheidung. CycloneDX und SPDX sind beide offene, international anerkannte Standards mit vielfältigen Communities, denen Sie beitreten können. Für Ihre Prüfer zählen die Version und Serialisierung, die Sie ausliefern, und der Workflow, der die Datei verarbeitet, mehr als das Logo auf dem Schema.
Weiterführende Artikel
Von SCA zu SBOM: Ein praktischer Leitfaden zur Migration – warum ein SBOM-first-Workflow einen eigenständigen Scanner ersetzen kann und wie der Wechsel ohne Abdeckungslücke gelingt.
SBOM-Strategie & Attestierung für OSS-Projekte: Leitfaden mit Best Practices 2026 – ein kanonisches Format wählen, die Erzeugung automatisieren und das Ergebnis signieren.
Der Stand der SBOM-Erzeugung für C/C++: Ausgabe 2026 – warum es gerade im Embedded-Bereich am meisten zählt, die SBOM aus dem Build und nicht aus dem Manifest abzuleiten.
SBOM, SOUP, COTS und OTS in Medizinprodukte-Software – wie sich Format- und Versionsentscheidungen unter FDA 524B und QMSR auswirken.
Kontinuierliches SBOM-Monitoring – was nach der Erzeugung der Datei passiert und warum eine statische SBOM veraltet.
Ihre SBOM richtig gemacht
Interlynk automatisiert SBOMs, verwaltet Open-Source-Risiken, überwacht Lieferanten und bereitet Sie auf die Post-Quanten-Ära vor – alles auf einer vertrauenswürdigen Plattform. Erzeugen Sie CycloneDX oder SPDX, validieren Sie gegen den Standard, den Ihre Kunden und Behörden erwarten, und halten Sie jede Ausgabe aktuell, während sich Ihre Abhängigkeiten und die Spezifikationen weiterentwickeln.
Vertrauen von Sicherheits- und Compliance-Teams in über 100 regulierten Unternehmen.
Demo buchen · Kostenlos starten
Quellen und weiterführende Informationen: SPDX (spdx.dev) und ISO/IEC 5962:2021; CycloneDX (cyclonedx.org) und ECMA-424; SBOM-Ressourcen der CISA (cisa.gov); die FDA-Leitlinie zur Cybersicherheit vor dem Inverkehrbringen; sowie die Projektseiten von OWASP und der Linux Foundation für Details zur Mitwirkung.