SPDX

SPDX ist ein offenes Austauschformat für Software-Stücklisten. Es entstand im Umfeld der Linux Foundation, zunächst mit dem Ziel, Lizenzangaben zu Softwarekomponenten maschinell austauschbar zu machen. Der Anspruch, eine vollständige Komponentenübersicht zu transportieren, kam später dazu.

Der Cyber Resilience Act (CRA) nennt SPDX an keiner Stelle. Wer eine Fundstelle sucht, findet keine. Anhang I Teil II Nummer 1 verlangt lediglich die „Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“. Welche Formate als gängig gelten, lässt die Verordnung offen.

Die Pflicht selbst gehört zur Software-Stückliste (SBOM). Hier geht es um die praktische Anschlussfrage: Taugt SPDX dafür, was deckt es ab, und wo hört es auf?

Warum SPDX die Anforderung erfüllt

Zwei Eigenschaften fordert die Vorschrift vom Format, und SPDX bringt beide mit. Maschinenlesbar ist es in jeder seiner Serialisierungen; JSON und YAML sind heute die üblichen. Als gängig gilt es nicht zuletzt deshalb, weil die Fassung 2.2.1 im Jahr 2021 als ISO/IEC 5962 genormt wurde.

Diese Normung ist für den CRA mehr als eine Fußnote. Nach Artikel 13 Absatz 24 kann die Kommission Format und Elemente der Software-Stückliste durch Durchführungsrechtsakt festlegen, und zwar ausdrücklich „unter Berücksichtigung europäischer oder internationaler Normen und bewährter Verfahren“. Ein solcher Rechtsakt liegt bislang nicht vor. Kommt er, ist ein bereits international genormtes Format ein naheliegender Anknüpfungspunkt.

Was ein SPDX-Dokument beschreibt

Ein SPDX-Dokument ist mehr als eine Aufzählung von Komponenten. Es besteht aus mehreren Abschnitten:

• Dokumentangaben: wer die Stückliste erzeugt hat, mit welchem Werkzeug und zu welchem Zeitpunkt. Ohne sie lässt sich später nicht mehr feststellen, welchen Stand ein Dokument beschreibt.
• Pakete mit Name, Version, Lieferant, Bezugsquelle und Prüfsummen. Auf dieser Ebene findet der größte Teil der Auswertung statt.
• Dateien und Ausschnitte bis hinunter zu einzelnen Zeilenbereichen. Das macht SPDX dort interessant, wo fremder Code in eigene Dateien kopiert wurde.
• Lizenzangaben, getrennt nach der vom Projekt erklärten und der bei der Prüfung festgestellten Lizenz.
• Beziehungen zwischen diesen Elementen. SPDX kennt mehrere Dutzend Beziehungstypen und unterscheidet damit, ob eine Komponente enthalten, statisch gebunden, dynamisch geladen oder nur zum Bauen nötig ist.
• externe Kennungen, vor allem Package URLs und CPE-Namen. Sie sind der Ansatzpunkt für den automatisierten Abgleich mit Schwachstellendatenbanken.

Die Lieferkettenbeziehungen, die die Legaldefinition der Software-Stückliste ausdrücklich nennt, bildet SPDX also von Haus aus ab. Wer nur eine flache Paketliste exportiert, nutzt einen Bruchteil des Formats.

Versionen und Serialisierungen

In der Praxis begegnen einem drei Stände. SPDX 2.2.1 ist die genormte Fassung, SPDX 2.3 die am häufigsten erzeugte, und SPDX 3.0 die 2024 veröffentlichte Neufassung. Version 3.0 ist keine Fortschreibung, sondern ein neues Datenmodell: Der Inhalt ist in Profile aufgeteilt, unter anderem für Software, Lizenzen, Sicherheit, Build und KI, und JSON-LD trägt die Serialisierung.

Werkzeuge und Abnehmer folgen diesem Wechsel langsam. Bevor Sie sich auf eine Version festlegen, lohnt deshalb die Frage, was die Gegenstelle tatsächlich einliest. Für Lieferketten, die nur einen kleinen Kern von Feldern austauschen wollen, gibt es zusätzlich das bewusst reduzierte Profil SPDX Lite.

Wo SPDX aufhört

Schwachstellen gehören nicht dazu. Die Fassungen 2.x haben kein eigenes Datenmodell für Schwachstellen und keine Felder für eine Aussage zur Ausnutzbarkeit. Erst das Sicherheitsprofil in Version 3.0 bringt beides mit. Wer heute festhalten will, dass eine Komponente zwar enthalten, die Schwachstelle darin aber nicht erreichbar ist, transportiert das über VEX in einem eigenen Dokument.

Formale Gültigkeit sagt nichts über Vollständigkeit. SPDX erlaubt an vielen Stellen den Wert NOASSERTION und die Angabe, dass Dateien gar nicht analysiert wurden. Ein Dokument kann jede Schemaprüfung bestehen und trotzdem kaum eine Aussage enthalten. Die Anforderung aus Anhang I bemisst sich am Inhalt, nicht am Schema.

Das Format erzeugt nichts. Ob transitive Abhängigkeiten überhaupt erfasst sind, entscheidet der Erzeugungsschritt im Build, nicht die Wahl zwischen zwei Formaten.

Verhältnis zu CycloneDX

Neben SPDX hat sich CycloneDX als zweites gängiges Format etabliert, mit anderer Herkunft und anderem Schwerpunkt. Beide erfüllen die Anforderung aus Anhang I Teil II Nummer 1. Die Wahl ist damit eine Frage der eingesetzten Werkzeuge und der Erwartungen Ihrer Abnehmer, keine Rechtsfrage.

Was für den CRA zählt

Anhang VII Nummer 8 zählt die Software-Stückliste zur technischen Dokumentation, und zwar gegebenenfalls auf begründetes Verlangen der Marktüberwachungsbehörde und nur, sofern das erforderlich ist, damit diese Behörde die Einhaltung der grundlegenden Cybersicherheitsanforderungen in Anhang I überprüfen kann. Eine Veröffentlichungspflicht besteht nicht. Entscheiden Sie sich dennoch dafür, die Stückliste Nutzern zugänglich zu machen, verlangt Anhang II Nummer 9, in den Nutzerinformationen anzugeben, wo sie zu finden ist.

Für die Behörde zählt dann, ob sich aus dem Dokument die verbauten Komponenten mit Version und Herkunft ergeben. Dass es dafür SPDX sein muss, steht in der Verordnung nicht.