SBOM: Warum die Software-Stückliste zur Pflicht wird

Eine SBOM listet auf, welche Komponenten in einer Software stecken. Der Cyber Resilience Act verlangt sie ab Dezember 2027, doch Hersteller brauchen diesen Überblick schon heute.

Wie schnell er fehlen kann, zeigte sich im Dezember 2021. Als die Log4j-Sicherheitslücke bekannt wurde, mussten zahlreiche Hersteller erst mühsam herausfinden, wo die Protokollbibliothek überall verbaut war. Mit einer aktuellen Software-Stückliste, der Software Bill of Materials, lässt sich eine solche Frage durch eine einfache Suche klären.

Inzwischen drängt bei dieser Frage die Zeit, denn für aktiv ausgenutzte Schwachstellen gilt seit September 2026 eine Meldefrist von 24 Stunden. Wer nicht weiß, was in seinen Produkten verbaut ist, kann sie kaum einhalten. Drei Punkte verdienen deshalb einen genaueren Blick: was in eine solche Stückliste gehört, was die Verordnung tatsächlich vorschreibt und wie der Nachweis der Bestandteile mit der Signatur einer Software zusammenhängt.

Was ist eine SBOM?

SBOM steht für Software Bill of Materials, auf Deutsch Software-Stückliste. Eine SBOM ist ein maschinenlesbares Verzeichnis aller Komponenten, aus denen eine Software besteht. Sie nennt zu jedem Bestandteil mindestens Name, Version und Herkunft und zeigt, welche Komponenten voneinander abhängen. So wird nachvollziehbar, was in einem Produkt tatsächlich enthalten ist.

Das Prinzip kennen Sie von Lebensmitteln: Die Zutatenliste auf der Verpackung verrät nicht, wie ein Produkt hergestellt wird, aber sie sagt, was darin steckt. Bei Software ist diese Auskunft wichtiger, als es zunächst scheint. Kaum eine Anwendung besteht nur aus eigenem Code. Bibliotheken, Frameworks und Open-Source-Bausteine machen oft den größeren Teil aus, und jede dieser Komponenten bringt wiederum eigene Abhängigkeiten mit.

Der Begriff stammt aus der Fertigung, wo die Stückliste alle Teile aufführt, aus denen ein Produkt zusammengesetzt wird. Die SBOM überträgt dieses Prinzip auf Software. Der Cyber Resilience Act definiert sie als „eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind“ (Art. 3 Nr. 39).

Was in einer Software-Stückliste steht

Welche Angaben eine Stückliste enthält, hängt vom Format und vom Anspruch ab. Die Technische Richtlinie des BSI nennt für jede Komponente unter anderem diese Angaben:

• den Namen der Komponente und ihre Version,
• den Ersteller, also den Hersteller oder das Projekt hinter der Komponente,
• die Lizenz, unter der sie vertrieben wird,
• eine Prüfsumme (Hashwert) der ausgelieferten Datei,
• die Abhängigkeiten zu anderen Komponenten.

Hinzu kommen Angaben zur Stückliste selbst, nämlich wer sie erstellt hat und wann.

Entscheidend ist die Tiefe. Eine Stückliste kann nur die direkten Abhängigkeiten eines Produkts erfassen, die sogenannten Top-Level-Abhängigkeiten, oder auch deren Abhängigkeiten bis in die unterste Ebene. Ein Beispiel: Eine Webanwendung bindet ein Framework ein, das Framework nutzt eine Bibliothek zur Bildverarbeitung, und diese greift wiederum auf eine Komprimierungsbibliothek zurück. In einer Stückliste, die nur die oberste Ebene erfasst, taucht allein das Framework auf. Log4j war in vielen Fällen gerade nicht direkt eingebunden, sondern steckte in einer Bibliothek, die ihrerseits von einer anderen Bibliothek genutzt wurde. Je vollständiger die Stückliste ist, desto verlässlicher ist die Auskunft.

Schwachstellen gehören dagegen nicht hinein. Eine SBOM beschreibt eine bestimmte Version einer Software und ändert sich nicht mehr, sobald diese Version ausgeliefert ist. Die Schwachstellenlage ändert sich dagegen laufend. Informationen dazu stehen deshalb in eigenen Dokumenten, etwa in Sicherheitshinweisen im Format CSAF oder in VEX-Dokumenten, die angeben, ob ein Produkt von einer bekannten Schwachstelle tatsächlich betroffen ist.

SBOM-Formate: CycloneDX und SPDX

Damit Werkzeuge eine Stückliste automatisch erzeugen, austauschen und auswerten können, braucht sie ein einheitliches Format. Zwei Standards haben sich durchgesetzt:

• CycloneDX ist ein Projekt der OWASP Foundation und von Beginn an auf Sicherheitsfragen ausgerichtet. Das Format ist als ECMA-424 international standardisiert.
• SPDX (Software Package Data Exchange) stammt von der Linux Foundation und wurde ursprünglich für Lizenzinformationen entwickelt. Das Format ist als ISO/IEC 5962 genormt.

Das BSI lässt in seiner Technischen Richtlinie beide zu: Neu erzeugte Stücklisten sollen CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 entsprechen. In einer Erhebung der EU-Cybersicherheitsagentur ENISA gaben 44 Prozent der befragten Organisationen an, CycloneDX zu nutzen, 29 Prozent nannten SPDX.

Welches SBOM-Format das richtige ist, entscheidet sich in der Praxis an den eingesetzten Werkzeugen und an den Anforderungen der Kunden. Wichtiger als die Wahl ist, dass die Stückliste automatisch entsteht und zu jeder ausgelieferten Version passt.

Ab wann die Software-Stückliste zur Pflicht wird

Die SBOM wird am 11. Dezember 2027 zur Pflicht. An diesem Tag gilt der Cyber Resilience Act (CRA) vollständig, und Hersteller müssen für jedes Produkt mit digitalen Elementen, das sie von da an in der EU in Verkehr bringen, eine Software-Stückliste führen.

Die Vorgabe steht in Anhang I der Verordnung (EU) 2024/2847. Hersteller müssen die Komponenten ihrer Produkte ermitteln und dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene erfasst. Vier Punkte zur SBOM im CRA werden häufig missverstanden:

• Die Stückliste muss nicht veröffentlicht werden. Erwägungsgrund 77 der Verordnung stellt das ausdrücklich klar. Die SBOM ist Teil der technischen Dokumentation, und die Marktüberwachungsbehörde kann sie auf begründetes Verlangen anfordern. Wer sie seinen Kunden bereitstellen möchte, darf das tun und gibt dann an, wo sie abrufbar ist.
• Die Mindesttiefe ist gering. Verlangt sind nur die Abhängigkeiten der obersten Ebene. Für eine belastbare Schwachstellenanalyse reicht das oft nicht aus, wie das Beispiel Log4j zeigt.
• Bestandsprodukte sind zunächst ausgenommen. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, fallen nur dann unter die Anforderungen, wenn sie danach wesentlich geändert werden.
• Ein verbindliches Format gibt es noch nicht. Die EU-Kommission kann Format und Elemente der Stückliste per Durchführungsrechtsakt festlegen. Bisher hat sie davon keinen Gebrauch gemacht (Stand: Oktober 2026).

Die technische Dokumentation, zu der die Stückliste gehört, müssen Hersteller mindestens zehn Jahre lang aufbewahren oder für die Dauer des Unterstützungszeitraums, wenn dieser länger ist.

Was die SBOM-Richtlinie des BSI regelt

Die SBOM-Richtlinie des BSI ist die Technische Richtlinie TR-03183 „Cyber-Resilienz-Anforderungen“. Ihr zweiter Teil beschreibt, wie eine Software-Stückliste aufgebaut sein soll: welche Datenfelder sie enthält, in welchen Formaten sie vorliegt und wie tief die Abhängigkeiten aufgelöst werden. Aktuell ist die Version 2.1.0 vom August 2025.

Nach Angaben des BSI ist die Richtlinie eine Hilfestellung ohne verbindlichen Charakter, die Hersteller auf die Anforderungen des Cyber Resilience Act vorbereiten soll. An mehreren Stellen geht sie über die Mindestanforderung der Verordnung hinaus. Sie verlangt unter anderem eine Prüfsumme für jede ausgelieferte Komponente, Lizenzangaben und eine neue Stückliste für jede neue Softwareversion. Solange die EU-Kommission keine eigenen Vorgaben macht, ist sie für Hersteller in Deutschland die genaueste Orientierung.

Warum Hersteller die Stückliste schon vor 2027 brauchen

Das die Pflicht erst Ende 2027 greift, bedeutet nicht, dass bis dahin Zeit bleibt. Seit dem 11. September 2026 gilt bereits die Meldepflicht des Cyber Resilience Act: Wird eine Schwachstelle in einem Produkt aktiv ausgenutzt, muss der Hersteller innerhalb von 24 Stunden eine Frühwarnung abgeben. Diese Pflicht erfasst auch Produkte, die längst auf dem Markt sind.

Die Frist lässt sich nur halten, wenn ein Hersteller sofort beurteilen kann, ob eine neu bekannt gewordene Schwachstelle seine Produkte betrifft. Ohne ein Verzeichnis der verbauten Komponenten beginnt in diesem Moment die Suche. Mit einer Stückliste genügt eine Abfrage. Beide Vorgaben gehören deshalb zusammen: Die Meldepflicht verlangt eine schnelle Antwort, und die Stückliste macht sie möglich.

Auch unabhängig von Fristen ist der Überblick nötig, denn Angriffe auf die Software-Lieferkette setzen genau dort an, wo Hersteller ihre zugekauften und quelloffenen Bausteine nicht im Blick haben. Wer Software an Unternehmen liefert, die selbst unter den CRA fallen, muss außerdem damit rechnen, von seinen Kunden nach einer Stückliste gefragt zu werden. Sie benötigen diese Angaben für ihre eigene Dokumentation.

Viele Unternehmen haben bereits begonnen. In der ENISA-Erhebung „SBOM Adoption State of Play – 2026“ mit 334 Antworten gaben 78 Prozent der Organisationen an, mit der Einführung begonnen zu haben. 79 Prozent erwarten, die nötige Reife zu erreichen, bis der CRA vollständig gilt. Als häufigste technische Hürde nannten die Befragten die Vollständigkeit der Stücklisten.

SBOM und Code Signing: Inhalt nachweisen, Herkunft belegen

Eine Stückliste sagt, was in einer Software steckt. Sie sagt nicht, ob die Datei, die beim Kunden ankommt, tatsächlich diejenige ist, die der Hersteller gebaut hat. Diese zweite Frage beantwortet die digitale Signatur. Code-Signing-Zertifikate binden eine Software an die geprüfte Identität ihres Herstellers, und jede nachträgliche Veränderung macht die Signatur ungültig.

Beide Nachweise greifen ineinander:

• Die Prüfsumme verbindet Stückliste und Datei. Nach der Richtlinie des BSI enthält die SBOM zu jeder ausgelieferten Komponente einen Hashwert. Er ordnet die Stückliste genau der Datei zu, die ausgeliefert wird.
• Die Signatur belegt Herkunft und Unversehrtheit. Der Empfänger kann prüfen, dass die Software vom genannten Hersteller stammt und seit der Signatur nicht verändert wurde.
• Auch die Stückliste lässt sich signieren. Das ist sinnvoll, weil eine SBOM ein Nachweisdokument ist. Wer sie unbemerkt verändern könnte, könnte eine verwundbare Komponente aus der Liste verschwinden lassen.

Der Cyber Resilience Act schreibt weder Code Signing noch eine signierte Stückliste ausdrücklich vor. Er verlangt aber, dass Programme und Daten vor unbefugter Manipulation geschützt sind und dass Sicherheitsupdates über sichere Mechanismen verteilt werden (Anhang I). Die Signatur ist das etablierte Mittel, um diese Integrität nachprüfbar zu machen.

In der Praxis gehören beide Schritte in denselben automatisierten Ablauf: Die Software wird gebaut, die SBOM wird erzeugt, das Ergebnis wird signiert, und beides wird zur jeweiligen Version abgelegt. Wer Code Signing in der Softwareentwicklung bereits fest verankert hat, muss dafür keinen neuen Prozess erfinden, sondern den bestehenden um einen Schritt erweitern. Je häufiger neue Versionen erscheinen, desto mehr lohnt es sich, auch das Code Signing zu automatisieren und die Schlüssel dabei geschützt zu verwahren.

Was Softwarehersteller jetzt vorbereiten

Bis Dezember 2027 bleibt etwas mehr als ein Jahr. Das Erzeugen einer Stückliste übernehmen Werkzeuge, der eigentliche Aufwand liegt in der Vollständigkeit und in den Abläufen dahinter. Am Anfang steht eine Bestandsaufnahme: Welche Produkte und Versionen sind im Markt, und welche werden nach dem Stichtag neu in Verkehr gebracht?

Darauf folgt die Entscheidung für ein Format und die Einbindung in den Build-Prozess, damit zu jeder Version automatisch eine passende Stückliste entsteht. Die Richtlinie des BSI bietet dafür eine konkrete Vorlage. Ebenso wichtig ist die Frage, wer neue Schwachstellenmeldungen mit den Stücklisten abgleicht, wer über eine Meldung entscheidet und wer dafür sorgt, dass Sicherheitslücken geschlossen werden.

Für zugekaufte Komponenten lohnt es sich, die Stücklisten frühzeitig bei den Zulieferern anzufordern, denn die Sicherheit der Lieferkette lässt sich nur beurteilen, wenn auch deren Bestandteile bekannt sind. Schließlich sollte geklärt sein, wie Software und Stückliste signiert werden und wo beides zusammen mit der technischen Dokumentation aufbewahrt wird.

Ab Dezember 2027 gehört die Software-Stückliste zu den Pflichten jedes Herstellers, der Produkte mit digitalen Elementen in der EU anbietet. Wer bis dahin weiß, was in seiner Software steckt, und belegen kann, dass sie unverändert beim Kunden ankommt, hat beide Nachweise beisammen: den Inhalt über die SBOM und die Herkunft über die Signatur. Bei der Auswahl des passenden Code-Signing-Zertifikats unterstützt Sie unser Team gern.