Cyber Resilience Act
CycloneDX
Praxisbegriff
CycloneDX ist ein offenes Austauschformat für Software-Stücklisten. Es entstand im Umfeld der OWASP, wird seit 2017 entwickelt und ist seit 2024 als ECMA-424 standardisiert. Erzeugen kann es praktisch jedes verbreitete Stücklisten-Werkzeug, lesen können es Schwachstellenplattformen, Paketmanager und Lieferantenportale.
Im Cyber Resilience Act (CRA) taucht der Name an keiner Stelle auf. Anhang I Teil II Nummer 1 verlangt, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, „u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“, und nennt bewusst kein Format. Die Frage nach dem CRA-konformen Format geht deshalb ins Leere. Die Pflicht selbst steht bei der Software-Stückliste (SBOM); hier geht es darum, ob und wie CycloneDX sie trägt.
Artikel 13 Absatz 24 hält die Tür offen: Die Kommission kann das Format und die Elemente der Software-Stückliste im Wege von Durchführungsrechtsakten festlegen, unter Berücksichtigung europäischer oder internationaler Normen und bewährter Verfahren. Solange eine solche Festlegung nicht vorliegt, entscheidet der Hersteller selbst, und ECMA-424 ist genau die Art von Norm, auf die sich eine spätere Festlegung stützen könnte. Eine Konformitätsvermutung entsteht daraus nicht: Artikel 27 Absatz 1 knüpft sie an harmonisierte Normen oder Teile davon, deren Fundstellen im Amtsblatt der Europäischen Union veröffentlicht worden sind.
Was das Format zur Anforderung beiträgt
Vier Eigenschaften treffen den Wortlaut aus Anhang I unmittelbar:
- Maschinenlesbar mit Schema. Geschrieben wird CycloneDX als JSON, XML oder Protocol Buffers, jeweils gegen ein veröffentlichtes Schema. Eine Datei lässt sich damit maschinell prüfen, nicht nur lesen.
- Abhängigkeiten als Graph. Ein eigener Abschnitt hält fest, welche Komponente welche andere nach sich zieht. Direkte und transitive Abhängigkeiten unterscheiden sich durch die Stellung im Graphen, nicht durch ein Kennzeichen.
- Eindeutige Kennungen. Neben purl kann jede Komponente CPE- oder SWID-Kennungen tragen. Erst darüber lässt sich ein Eintrag automatisiert gegen eine CVE-Kennung und die einschlägigen Schwachstellendatenbanken abgleichen.
- Erklärte Vollständigkeit. Ein Abschnitt für Zusammensetzungen erlaubt die Angabe, ob der erfasste Umfang vollständig, unvollständig oder unbekannt ist, getrennt nach eigenen und fremden Anteilen. Genau dort wird die Formulierung „zumindest die obersten Abhängigkeiten“ zu einer prüfbaren Aussage.
Ein Punkt wird dabei regelmäßig übersehen. Eine gültige CycloneDX-Datei kann allein aus einer Komponentenliste bestehen, ganz ohne Abhängigkeitsangaben. Die Legaldefinition in Artikel 3 Nummer 39 verlangt aber ausdrücklich auch die Lieferkettenbeziehungen. Eine schemakonforme Datei ohne Abhängigkeitsgraphen erfüllt das Format, nicht die Definition.
Mehr als Softwarekomponenten
CycloneDX beschreibt nicht nur Bibliotheken und Frameworks. Der Komponententyp unterscheidet unter anderem Anwendung, Bibliothek, Container, Betriebssystem, Gerät, Firmware, Datei und Datensatz; jüngere Fassungen ergänzen Modelle für maschinelles Lernen und kryptografische Bestandteile. Ein eigener Abschnitt für Dienste kann außerdem die Gegenstellen erfassen, mit denen ein Produkt spricht.
Für den CRA ist das mehr als eine Randnotiz. Die Legaldefinition der Software-Stückliste erfasst nur die Komponenten in den Softwareelementen eines Produkts, die Pflicht aus Anhang I Teil II Nummer 1 dagegen die Komponenten des Produkts insgesamt. Was ohnehin zu dokumentieren ist, Firmware und Gerätebestandteile eingeschlossen, kann damit im selben Dokument stehen. Ob es das sollte, hängt vom Empfänger ab: Ein Werkzeug, das nur Softwarekomponenten auswertet, übergeht die übrigen Einträge stillschweigend.
Auch Schwachstellenangaben sind Teil des Formats. CycloneDX kann Aussagen zur Betroffenheit im Sinne von VEX im selben Dokument führen oder in einem getrennten, das auf die Stückliste verweist.
Grenzen
Das Format sagt nichts darüber, wie die Daten zustande kommen. Zwei Werkzeuge über demselben Projekt liefern regelmäßig unterschiedliche Ergebnisse, je nachdem, ob sie den Bauvorgang beobachten, das Repository auswerten oder das fertige Artefakt zerlegen. Die Pflicht des CRA richtet sich auf das Ermitteln und Dokumentieren der Komponenten; das Format hält nur das Ergebnis fest. Eine sauber validierende Datei über einer unvollständigen Erhebung ist wertlos.
Bei Lizenzangaben liegt der Schwerpunkt anderswo: CycloneDX übernimmt zwar die SPDX-Lizenzkennungen, ist im Kern aber auf Sicherheitskontext ausgelegt, während SPDX aus dem Lizenz-Compliance-Umfeld stammt.
Die Datei selbst trägt zudem keinen Nachweis ihrer Herkunft. CycloneDX sieht Signaturen vor, verlangt sie aber nicht. Wer Stücklisten an Behörden oder Abnehmer weitergibt, sollte klären, woran der Empfänger erkennen soll, dass die Datei von ihm stammt und zu genau diesem Build gehört.
Wann die Datei nach außen geht
Veröffentlichen muss niemand eine Software-Stückliste. Nach außen sichtbar wird sie in drei Situationen, und in allen dreien zählt, dass die Datei ohne Ihre Werkzeuge lesbar ist:
- Anhang VII Nummer 8: Auf begründetes Verlangen einer Marktüberwachungsbehörde ist die Stückliste vorzulegen, soweit die Behörde sie zur Prüfung der Anforderungen aus Anhang I benötigt.
- Artikel 13 Absatz 25: Die Gruppe für administrative Zusammenarbeit (ADCO) kann eine unionsweite Bewertung von Softwareabhängigkeiten beschließen. Marktüberwachungsbehörden können Hersteller der betroffenen Produktkategorien dann zur Vorlage ihrer Stücklisten auffordern.
- Anhang II Nummer 9: Stellt ein Hersteller Nutzern die Stückliste zur Verfügung, muss die Nutzerinformation angeben, wo sie abrufbar ist. Freiwillig ist die Herausgabe, der Hinweis darauf dann nicht mehr.
Für die Formatwahl folgt daraus eine schlichte Anforderung: Der Empfänger darf nichts installieren müssen, um die Datei zu verstehen. Eine schemavalidierte JSON-Datei erfüllt das. Ein Export, den nur die eigene Werkzeugkette interpretiert, erfüllt es nicht.
Fragen aus der Praxis
-
Ja, die meisten Werkzeuge erzeugen CycloneDX und SPDX aus demselben Lauf. Erzeugen Sie beide nativ nebeneinander, statt eine Datei in die andere umzuwandeln; jede Umwandlung verliert Angaben. Bestimmen Sie trotzdem eine Fassung als die maßgebliche für die Technische Dokumentation, denn Anhang VII Nummer 8 spricht von der Software-Stückliste, nicht von mehreren. Zwei Fassungen, die sich im Detail widersprechen, sind bei einer Nachfrage schwerer zu erklären als eine.
-
Beide Wege sind vorgesehen, und die Entscheidung hängt am Änderungstakt. Eine Stückliste beschreibt einen Build und ändert sich mit ihm; eine VEX-Aussage ändert sich, sobald eine weitere Schwachstelle bewertet wird, also sehr viel häufiger. Eingebettet müssten Sie für jede neue Bewertung das gesamte Dokument neu ausgeben und beim Empfänger ersetzen. Ein getrenntes Dokument, das über einen Verweis auf die Stückliste zeigt, bleibt in der Praxis mit weniger Aufwand aktuell.
-
Der CRA schreibt keine vor. Maßgeblich ist, was Ihre Abnehmer und Ihre eigenen Analysewerkzeuge einlesen können; ältere Plattformen bleiben oft mehrere Nebenversionen zurück. Beim Ausgeben einer älteren Fassung entfallen später hinzugekommene Felder ohne Warnung, etwa Angaben zur erklärten Vollständigkeit. Halten Sie deshalb fest, welche Fassung erzeugt wurde, und nicht nur, dass eine Stückliste existiert.
Dieses Glossar dient der Orientierung und ersetzt keine Rechtsberatung. Maßgeblich ist der Wortlaut der Verordnung (EU) 2024/2847.