SBOM nach dem Cyber Resilience Act: Was die Verordnung wirklich verlangt

Die Software-Stückliste, die SBOM, ist die eine Pflicht des Cyber Resilience Act, die in einem einzigen Satz steht, und zugleich die, die am häufigsten falsch wiedergegeben wird. Drei Behauptungen kursieren in fast jeder Zusammenfassung: Die SBOM müsse veröffentlicht werden, sie müsse alle Abhängigkeiten bis in die letzte Ebene erfassen, und der CRA schreibe ein bestimmtes Format vor. Keine der drei steht in der Verordnung.

Dieser Text nimmt den Satz auseinander, in dem die Pflicht steht, und zeigt, was daraus für die Praxis folgt: wie tief, in welchem Format, wo abgelegt, wer sie sehen darf, und warum ein Hersteller sie schon vor dem 11. September 2026 braucht, obwohl Anhang I erst ab dem 11. Dezember 2027 gilt. Wer den CRA insgesamt noch nicht einordnen kann, beginnt besser mit Was ist der Cyber Resilience Act?

Der Satz, in dem die Pflicht steht

Die SBOM-Pflicht steht in Anhang I Teil II Nummer 1 der Verordnung (EU) 2024/2847. Hersteller müssen Schwachstellen und Komponenten, die in ihren Produkten mit digitalen Elementen enthalten sind, identifizieren und dokumentieren, unter anderem durch das Erstellen einer Software-Stückliste in einem gängigen und maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene der Produkte erfasst. Der Wortlaut im Amtsblatt: Anhang I Teil II, Behandlung von Schwachstellen.

Fünf Dinge stehen in diesem Satz, und jedes davon trägt.

1. Die SBOM ist ein Mittel, kein Zweck. Die Pflicht lautet, Schwachstellen und Komponenten zu identifizieren und zu dokumentieren. Die SBOM ist das Werkzeug dafür, „unter anderem". Wer eine SBOM erzeugt und danach nichts mit ihr tut, hat das Werkzeug, aber nicht die Pflicht erfüllt. Erfüllt ist sie, wenn die SBOM benutzt wird, um Schwachstellen in den Komponenten zu finden.

2. Mindestens die oberste Ebene. „Mindestens" ist eine Untergrenze, keine Obergrenze. Ein Produkt, das direkt fünfzig Bibliotheken einbindet, hat eine SBOM mit mindestens fünfzig Einträgen. Ob die transitiven Abhängigkeiten dieser Bibliotheken auch hineingehören, sagt die Verordnung nicht. In der Praxis entscheidet das die Frage, ob ein Schwachstellenabgleich mit nur der obersten Ebene noch aussagekräftig ist. Bei den meisten Software-Ökosystemen ist er es nicht, weil die bekannten Schwachstellen tief in transitiven Abhängigkeiten sitzen.

3. Gängig und maschinenlesbar. Kein Format wird genannt. Gängig und maschinenlesbar sind heute zwei: SPDX und CycloneDX. Eine Tabelle in einem Textdokument ist maschinenlesbar im Wortsinn, aber nicht gängig. Die Kommission kann Format und Elemente der SBOM per Durchführungsrechtsakt festlegen (Artikel 13 Absatz 24). Bis dahin ist die Technische Richtlinie TR-03183 Teil 2 des BSI die genaueste Beschreibung dessen, was eine SBOM mindestens enthalten sollte, und die deutsche Marktüberwachung wird sich an ihr orientieren.

4. Pro Produkt, und damit pro Version. Die SBOM beschreibt „die Produkte". Ein Produkt mit digitalen Elementen ist eine bestimmte Software in einer bestimmten Version; die nächste Version hat andere Komponenten. Eine SBOM, die nicht zu einer Version gehört, beschreibt nichts.

5. Schwachstellen und Komponenten. Die Pflicht nennt beides. Die SBOM allein liefert die Komponenten. Die Schwachstellen kommen aus dem Abgleich der SBOM mit Schwachstellendatenbanken und Herstellerhinweisen. Beides zusammen ist die Dokumentation, die Anhang I verlangt.

Wo die SBOM hingehört, und wer sie sehen darf

Die Verordnung nennt die SBOM an drei weiteren Stellen, und die drei beantworten die Frage nach der Veröffentlichung.

Die Antwort lautet also: Die SBOM muss nicht veröffentlicht werden. Sie muss existieren, sie muss in der technischen Dokumentation liegen, und sie muss der Marktüberwachung auf begründetes Verlangen vorgelegt werden. Ob Kunden sie bekommen, entscheidet der Hersteller. Wer sie herausgibt, sagt in der Nutzerinformation, wo. Die Texte: Inhalt der technischen Dokumentation und Informationen und Anleitungen für den Nutzer.

In der Praxis verlangen Geschäftskunden die SBOM zunehmend vertraglich, unabhängig vom CRA. Das ist dann eine Vertragsfrage, keine Frage der Verordnung.

Die SBOM unter den acht Pflichten zur Schwachstellenbehandlung

Anhang I Teil II hat acht Nummern, und die SBOM ist die erste, weil die anderen sieben ohne sie nicht funktionieren.

Wer die SBOM als Dokument für den Ordner betrachtet, verfehlt Nummer 2 bis 8. Wer sie als Datenquelle für den laufenden Abgleich betrachtet, erfüllt alle acht mit demselben Prozess.

Warum die SBOM schon vor dem 11. September 2026 nötig ist

Anhang I gilt für neue Produkte ab dem 11. Dezember 2027. Die Meldepflichten aus Artikel 14 gelten ab dem 11. September 2026, und zwar auch für Produkte, die dann bereits auf dem Markt sind (Artikel 69 Absatz 3). Artikel 14 verlangt, dass ein Hersteller eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden nach Kenntnisnahme meldet.

Kenntnisnahme setzt voraus, dass der Hersteller überhaupt erkennen kann, dass eine bekannt gewordene Schwachstelle sein Produkt betrifft. Bei Schwachstellen im eigenen Code ist das der eigene Befund. Bei Schwachstellen in einer Drittkomponente, und das sind die meisten, ist es der Abgleich einer veröffentlichten Schwachstelle mit der Liste der eigenen Komponenten. Ohne diese Liste erfährt der Hersteller von der Betroffenheit, wenn ein Kunde oder ein Angreifer sie ihm mitteilt, und die 24 Stunden laufen dann bereits. Was die beiden Meldepflichten im Einzelnen verlangen: Artikel 14 enthält zwei Meldepflichten, nicht eine.

Die SBOM ist deshalb keine Dezember-2027-Aufgabe. Sie ist die Voraussetzung dafür, im September 2026 melden zu können.

Drittkomponenten und Zulieferer

Artikel 13 Absatz 5 verpflichtet Hersteller zur Sorgfalt bei der Integration von Komponenten Dritter, einschließlich Open-Source-Komponenten: Sie dürfen die Sicherheit des Produkts nicht beeinträchtigen. Die SBOM ist das Instrument, mit dem diese Sorgfalt nachweisbar wird. Für zugekaufte Komponenten mit eigener Software bedeutet das in der Praxis, die SBOM des Zulieferers anzufordern und in die eigene einzubinden. Ein Zulieferer, der ab Dezember 2027 selbst unter den CRA fällt, muss eine haben. Bis dahin ist die Anforderung eine Vertragsfrage, und wer sie heute in die Lieferverträge schreibt, hat 2027 die Kette vollständig.

Für Open-Source-Komponenten gibt es keinen Zulieferer, den man fragen kann. Die SBOM kommt aus dem Build, und die Schwachstelleninformation aus den öffentlichen Datenbanken. Das ist der Fall, für den maschinenlesbare Formate gemacht sind.

Was jetzt zu tun ist

1. Die SBOM aus dem Build erzeugen, nicht von Hand. Paketmanager kennen die Abhängigkeiten; ein Generator für SPDX oder CycloneDX läuft in der Build-Pipeline und erzeugt pro Release eine Datei.
2. Pro Version ablegen, mit Prüfsumme. Die SBOM gehört neben das Release-Artefakt, mit einem Hash, damit später nachweisbar ist, welche SBOM zu welcher Auslieferung gehört.
3. Tiefe festlegen und begründen. Mindestens die oberste Ebene. Wenn transitive Abhängigkeiten aufgenommen werden, sagen, bis wohin und warum. Die Begründung gehört in die technische Dokumentation.
4. Den Abgleich einrichten. SBOM gegen Schwachstellendatenbanken und Herstellerhinweise, laufend, mit einer Person, die die Treffer beurteilt. Das ist der Prozess, der Artikel 14 möglich macht.
5. Zulieferer-SBOMs anfordern. In die Lieferverträge aufnehmen, in die eigene SBOM einbinden.
6. Entscheiden, ob Nutzer die SBOM bekommen. Wenn ja, in der Nutzerinformation sagen, wo (Anhang II Nummer 9). Wenn nein, ist das erlaubt.

Für die Ablage gibt es auch einen Weg ohne eigenes Werkzeug: Der Legalithm-Befehl cra ingest nimmt eine SBOM oder eine signierte Erklärung in den Nachweis auf, als Hypothese, und cra watch verbindet die Komponenten mit veröffentlichten Hinweisen. Beides ist quelloffen und läuft ohne Konto: Entwicklerwerkzeuge.

Häufig gestellte Fragen

Muss ich die SBOM veröffentlichen? Nein. Sie gehört in die technische Dokumentation und wird der Marktüberwachung auf begründetes Verlangen vorgelegt. Die Weitergabe an Nutzer ist eine Entscheidung des Herstellers; wer sie trifft, nennt in der Nutzerinformation den Ort.

Welches Format ist vorgeschrieben? Keines. Verlangt ist ein gängiges, maschinenlesbares Format. SPDX und CycloneDX erfüllen das. Die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen; in Deutschland beschreibt die BSI TR-03183 Teil 2 die erwarteten Inhalte.

Wie tief muss die SBOM sein? Mindestens die Abhängigkeiten der obersten Ebene. Tiefer ist nicht vorgeschrieben, aber für einen aussagekräftigen Schwachstellenabgleich meist nötig. Die gewählte Tiefe sollte in der technischen Dokumentation begründet sein.

Brauche ich eine SBOM pro Version? Ja. Die SBOM beschreibt ein Produkt in einer Version. Jedes Release, das Komponenten ändert, hat eine eigene.

Gilt die Pflicht auch für SaaS? Nur, soweit der Dienst eine Fernverarbeitungslösung eines Produkts mit digitalen Elementen ist. Für reine Dienste gilt der CRA nicht; NIS2 kann gelten.

Reicht die SBOM als Nachweis für die Schwachstellenbehandlung? Nein. Sie ist die Komponentenliste. Der Nachweis für Anhang I Teil II ist der Prozess, der mit ihr arbeitet: Abgleich, Behebung, Update, Veröffentlichung.

Quellen

• Verordnung (EU) 2024/2847, Anhang I Teil II, Anhang II, Anhang VII, Artikel 13, deutsche Fassung: eur-lex.europa.eu/eli/reg/2024/2847/oj/deu
• BSI, Technische Richtlinie TR-03183 Teil 2, Software Bill of Materials: bsi.bund.de
• Alle Pflichten des CRA mit Wortlaut: Pflichten aus dem Cyber Resilience Act

Dieser Text ist eine zitierte Einordnung, keine Rechtsberatung. Maßgeblich ist der Text der Verordnung.