SBOM für KMU: CycloneDX und SPDX in der Praxis

Inhalt in Kürze

• Eine Software-Stückliste ist nach Anhang I Teil II Nr. 1 in einem gängigen maschinenlesbaren Format zu erstellen und muss mindestens die obersten Abhängigkeiten ausweisen.
• Veröffentlichen müssen Sie sie nicht. Sie gehört in die technische Dokumentation und geht auf begründetes Verlangen an die Marktüberwachungsbehörde.
• CycloneDX und SPDX stehen nicht in der Verordnung. Sie verlangt „ein gängiges maschinenlesbares Format”; das konkrete Format kann die Kommission später per Durchführungsrechtsakt festlegen.
• Der eigentliche Nutzen liegt woanders: Ohne Komponentenliste lässt sich eine Meldung nach Art. 14 nicht sauber befüllen — und die Upstream-Meldepflicht nach Art. 13 Abs. 6 nicht erfüllen.

„SBOM” gehört zu den Begriffen, die in CRA-Vorträgen groß auf der Folie stehen und danach niemandem klar sind. Dieser Beitrag klärt, was die Verordnung tatsächlich verlangt, was sie nicht verlangt, und wie eine Stückliste im Mittelstand entsteht, ohne dass daraus ein Projekt wird. Den Rahmen dazu liefert der Überblick zu den CRA-Pflichten für Hersteller.

Was der CRA wörtlich verlangt

Zwei Stellen, mehr nicht.

Artikel 3 Nummer 39 definiert die Software-Stückliste als „eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind”.

Anhang I Teil II Nummer 1 macht daraus eine Pflicht. Hersteller müssen

„Schwachstellen und Komponenten der Produkte mit digitalen Elementen ermitteln und 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”.

Drei Anforderungen stecken darin: maschinenlesbar, gängiges Format, mindestens oberste Abhängigkeiten. Mehr steht nicht dort.

Die Frage, die immer zuerst kommt: Müssen wir sie veröffentlichen?

Nein. Die Software-Stückliste ist Teil der technischen Dokumentation:

• Anhang VII Nummer 2 Buchstabe b zählt sie zu den Informationen über die Verfahren zur Behandlung von Schwachstellen — neben dem Konzept für die koordinierte Offenlegung, dem Nachweis der Kontaktadresse und der Beschreibung der Verbreitungswege für Aktualisierungen.
• Anhang VII Nummer 8 verlangt sie gegebenenfalls auf begründetes Verlangen der Marktüberwachungsbehörde, soweit sie zur Prüfung der Einhaltung erforderlich ist.
• Erwägungsgrund 22 geht in die andere Richtung: Um die Vertraulichkeit der Software-Stücklisten zu schützen, sollen die Marktüberwachungsbehörden relevante Informationen über Abhängigkeiten nur anonymisiert und aggregiert weitergeben.

Der einzige Ort, an dem die Verordnung von einer Bereitstellung an Nutzer spricht, ist Anhang II Nummer 9 — und der regelt ausdrücklich nur den Fall, dass der Hersteller sie dem Nutzer zur Verfügung stellt: Dann ist anzugeben, wo darauf zugegriffen werden kann. Eine Pflicht dazu begründet das nicht.

CycloneDX oder SPDX?

Beide sind maschinenlesbar, beide sind gängig, beide erfüllen den Wortlaut. Sie kommen aus unterschiedlichen Ecken:

Für den CRA-Zweck — Schwachstellen und Komponenten ermitteln und dokumentieren — liegt CycloneDX näher am Anwendungsfall. Wer ohnehin eine Lizenz-Compliance-Kette betreibt, hat SPDX meist schon. Beides parallel zu führen lohnt sich selten; ein Format sauber schlägt zwei Formate halb.

Praktisch entsteht die Stückliste ohnehin nicht von Hand, sondern aus dem Build: Die gängigen Paketmanager und Build-Werkzeuge können beide Formate erzeugen, und die Erzeugung gehört in die Pipeline, nicht in eine jährliche Fleißaufgabe. Eine Stückliste, die zum Release-Zeitpunkt entsteht, ist zum Release-Zeitpunkt richtig — eine, die im Dezember gepflegt wird, ist es nie.

Wie tief muss sie gehen?

„Zumindest die obersten Abhängigkeiten” heißt: die Komponenten, die Ihr Produkt direkt einbindet. Transitive Abhängigkeiten — die Bibliotheken Ihrer Bibliotheken — verlangt der Wortlaut nicht.

Trotzdem ist die Tiefe eine Abwägung und keine Formalie. Die praktisch relevanten Schwachstellen der letzten Jahre saßen regelmäßig zwei Ebenen tiefer. Wer nur die oberste Ebene führt, erfüllt die Pflicht — und beantwortet die Frage „sind wir betroffen?” trotzdem nicht. Die meisten Werkzeuge lösen den vollständigen Baum ohnehin auf; ihn abzuschneiden wäre zusätzlicher Aufwand.

Der Teil, den fast niemand mitliest: die Upstream-Pflicht

Artikel 13 Absatz 6 hängt unmittelbar an der Komponentenliste:

„Sobald der Hersteller eine Schwachstelle in einer … integrierten Komponente, einschließlich einer quelloffenen Komponente, feststellt, meldet er die Schwachstelle der Person oder Einrichtung, die diese Komponente herstellt oder wartet, und behandelt und behebt die Schwachstelle …”

Und weiter: Hat der Hersteller eine Änderung entwickelt, die die Schwachstelle in dieser Komponente behebt, teilt er den betreffenden Code oder die einschlägigen Unterlagen dem Betreuer mit — gegebenenfalls in einem maschinenlesbaren Format.

Aus einem Fund im Abhängigkeitsbaum wird also nicht nur ein internes Ticket, sondern eine Meldung nach außen — und im besten Fall ein Beitrag zurück ins Projekt. Wer das nachweisen können will, braucht dafür eine Ablage.

Was eine SBOM im Alltag wirklich bringt

Vier Dinge, unabhängig von der Verordnung:

• Betroffenheitsfrage in Minuten. Wenn die nächste weitverbreitete Bibliothek eine kritische Lücke hat, ist die Frage „welche unserer Produktversionen enthalten sie?" eine Abfrage und keine Recherche.
• Meldung befüllen. Die Frühwarnung nach Artikel 14 verlangt Produktname, Version und die Mitgliedstaaten der Bereitstellung. Wer die Stückliste je Produktversion führt, hat den ersten Teil davon schon.
• Kundenanfragen abkürzen. Auftraggeber unter NIS2 fragen ihre Lieferanten inzwischen regelmäßig nach Komponenten. Eine vorbereitete Liste ist schneller als ein Fragebogen.
• Support-Ende planen. Wenn eine eingebundene Komponente ihr Lebensende erreicht, betrifft das Ihren eigenen Unterstützungszeitraum. Ohne Liste merkt man es zu spät.

In vier Schritten zur ersten Stückliste

1. Produktversionen festlegen. Eine Stückliste gehört zu einer Version, nicht zu einem Produkt. Klären Sie zuerst, welche Versionen Sie überhaupt im Markt haben und unterstützen.
2. Erzeugung in den Build hängen. Ein Schritt in der Pipeline, ein Format, ein Ablageort. Alles, was manuell passiert, verfällt.
3. Ablage und Aufbewahrung klären. Die technische Dokumentation ist mindestens zehn Jahre oder für die Dauer des Unterstützungszeitraums aufzubewahren, je nachdem, welcher Zeitraum länger ist (Artikel 13 Absatz 13). Die Stückliste teilt dieses Schicksal.
4. Upstream-Weg festlegen. Wer meldet einen Fund an den Komponentenbetreuer, und wo wird das dokumentiert? Ohne Zuständigkeit passiert es nicht.

Ob der CRA für Sie gilt und in welche Produktklasse Ihr Produkt fällt, klärt der kostenlose Hersteller-Check. Wie die Meldung selbst abläuft, steht im Beitrag zur CRA-Meldepflicht in 24 und 72 Stunden.

Häufige Fragen (FAQ)

Was ist eine SBOM?

Eine Software-Stückliste ist nach Artikel 3 Nummer 39 der Verordnung (EU) 2024/2847 eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind. Anhang I Teil II Nummer 1 verlangt sie in einem gängigen maschinenlesbaren Format, aus dem zumindest die obersten Abhängigkeiten hervorgehen.

Muss die SBOM veröffentlicht werden?

Nein. Sie gehört in die technische Dokumentation und geht auf begründetes Verlangen an die Marktüberwachungsbehörde (Anhang VII Nummer 2 Buchstabe b und Nummer 8). Erwägungsgrund 22 betont sogar den Schutz ihrer Vertraulichkeit. Anhang II Nummer 9 regelt nur den Fall, dass der Hersteller sie dem Nutzer freiwillig zur Verfügung stellt — dann ist anzugeben, wo sie zugänglich ist.

Schreibt der CRA CycloneDX oder SPDX vor?

Nein. Die Verordnung verlangt ein gängiges maschinenlesbares Format; die Begriffe CycloneDX und SPDX kommen im Verordnungstext nicht vor. Format und Elemente der Software-Stückliste kann die Kommission per Durchführungsrechtsakt festlegen (Artikel 13 Absatz 24). CycloneDX und SPDX sind die beiden Formate, die sich in der Praxis durchgesetzt haben.

Wie tief muss eine SBOM gehen?

Anhang I Teil II Nummer 1 verlangt, dass zumindest die obersten Abhängigkeiten des Produkts hervorgehen. Tiefer zu gehen ist erlaubt und für das eigene Schwachstellenmanagement meist sinnvoll — verpflichtend ist es nach dem Wortlaut nicht.

Was mache ich, wenn ich eine Schwachstelle in einer Fremdkomponente finde?

Artikel 13 Absatz 6 verlangt zweierlei: Sie melden die Schwachstelle der Person oder Einrichtung, die die Komponente herstellt oder wartet — auch bei quelloffenen Komponenten —, und Sie behandeln und beheben sie im eigenen Produkt. Haben Sie eine Änderung entwickelt, die die Schwachstelle behebt, teilen Sie den Code oder die einschlägigen Unterlagen dem Betreuer mit, gegebenenfalls in maschinenlesbarer Form.