Leitfaden

Software-Stückliste (SBOM) nach der Cyberresilienz-Verordnung

Geprüft im September 2026 anhand der Verordnung (EU) 2024/2847, ABl. L, 20.11.2024.

Kurz gesagt: Die Verordnung macht die Software-Stückliste zu einer Rechtspflicht für Hersteller. Sie muss maschinenlesbar sein, in einem gängigen Format vorliegen und zumindest die obersten Abhängigkeiten ausweisen. Sie gehört in die technische Dokumentation. Veröffentlichen müssen Sie sie nicht, und eine Marktüberwachungsbehörde kann sie auf begründetes Verlangen anfordern.

Definition: was im Wortlaut steht

Die Verordnung bestimmt den Begriff selbst, die Bedeutung ist hier also nicht die lose der Branche. Eine Software-Stückliste ist eine formale Aufzeichnung von Komponenten und ihren Lieferkettenbeziehungen.

„eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind“

Zwei Wörter dieser Bestimmung tragen die Last. Formale Aufzeichnung schließt eine Aufzählung im Fließtext einer Infodatei aus. Lieferkettenbeziehungen schließen eine flache Liste von Paketnamen aus: Die Datei muss ausweisen, wie die Komponenten zueinander stehen, und genau das ist ein Abhängigkeitsgraph.

Die Pflicht und ihr Ort im Regelwerk

Die Pflicht steht in Anhang I Teil II Nummer 1, bei den Anforderungen an die Behandlung von Schwachstellen. Sie ist als ein Weg formuliert, eine weiter gefasste Pflicht zu erfüllen, nämlich die enthaltenen Komponenten zu ermitteln und zu dokumentieren.

„Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“

Aus diesem einen Satz folgen drei Vorgaben.

• Gängiges Format. Die Verordnung nennt keines. Sie schreibt eine Eigenschaft vor, keine Norm.
• Maschinenlesbar. Eine Tabelle als PDF ist in keinem nützlichen Sinne maschinenlesbar.
• Zumindest die obersten Abhängigkeiten. Das ist eine Untergrenze, keine Obergrenze. Weitergereichte Abhängigkeiten verlangt dieser Satz nicht, auch wenn die umgebende Pflicht, Schwachstellen in Komponenten zu ermitteln, in der Praxis oft weiter führt.

Die Pflicht hängt an den Anforderungen zur Behandlung von Schwachstellen und läuft damit über den Unterstützungszeitraum, nicht nur bis zum Inverkehrbringen. Ein Produkt, dessen Komponenten sich ändern, braucht eine Stückliste, die sich mitändert.

Formate: SPDX, CycloneDX und der Durchführungsrechtsakt

Die Verordnung nennt weder SPDX noch CycloneDX. Sie lässt das Format offen und gibt der Kommission die Befugnis, es später festzulegen, und zwar im Wege eines Durchführungsrechtsakts, nicht eines delegierten Rechtsakts.

„Die Kommission kann im Wege von Durchführungsrechtsakten unter Berücksichtigung europäischer oder internationaler Normen und bewährter Verfahren das Format und die Elemente der Software-Stückliste gemäß Anhang I Teil II Nummer 1 festlegen.“

Der Wortlaut ist zu beachten: Die Kommission kann, und ein solcher Rechtsakt hätte europäische oder internationale Normen und bewährte Verfahren zu berücksichtigen. Ihre Durchführungsbefugnisse hat die Kommission an anderer Stelle bereits genutzt, nämlich für die technischen Beschreibungen der Anhänge III und IV in der Durchführungsverordnung (EU) 2025/2392. Zum Zeitpunkt der Prüfung dieser Seite im September 2026 war jedoch kein Durchführungsrechtsakt zum Format der Software-Stückliste erlassen. Bis dahin erfüllen in der Praxis zwei Formate die Vorgabe „gängig und maschinenlesbar“:

• SPDX, herausgegeben von der Linux Foundation und als ISO/IEC 5962:2021 genormt. Serialisierbar als JSON, YAML, RDF und als Tag-Wert-Format.
• CycloneDX, herausgegeben von OWASP und über Ecma International als ECMA-424 genormt, gepflegt mit dem Technischen Komitee 54 von Ecma. Serialisierbar als JSON, XML und Protocol Buffers, mit einem reicheren Modell für Abhängigkeiten und Schwachstellen.

Beide erfüllen die zwei Eigenschaften, die der Wortlaut tatsächlich nennt. Die Wahl zwischen ihnen ist eine technische Entscheidung, keine rechtliche, und nichts im Regelwerk bevorzugt eines von beiden. Kommt ein Durchführungsrechtsakt, so kommt er mit einer Übergangsfrist, und wer bereits eines dieser Formate erzeugt, hat einen Umstellungsweg statt eines Neubaus.

Werkzeuge und Erzeugung

Eine Software-Stückliste wird erzeugt und nicht geschrieben. Die praktische Frage ist, an welcher Stelle Ihrer Erstellungskette sie entsteht, denn das entscheidet, was sie überhaupt sehen kann.

• Beim Erstellen lesen die Werkzeuge die Auflösung der Abhängigkeiten, die der Erstellungslauf ohnehin vorgenommen hat, und sehen damit die tatsächlich eingebundenen Versionen. Für die obersten Abhängigkeiten, die die Verordnung nennt, ist das die treueste Quelle.
• Aus dem Quelltext lesen die Werkzeuge Manifest- und Sperrdateien. Billiger im Betrieb, aber blind für alles, was mitgeliefert oder erst beim Erstellen aufgelöst wird.
• Aus dem fertigen Artefakt lesen Prüfwerkzeuge für Binärdateien und Container. Nützlich für ein Produkt, das Sie nicht selbst erstellt haben, und die einzige Möglichkeit bei einer zugelieferten Komponente ohne eigene Stückliste.

Verbreitete quelloffene Erzeuger sind Syft, die Werkzeugketten von CycloneDX und SPDX für einzelne Sprachökosysteme sowie das sbom-tool von Microsoft, das SPDX erzeugt. Ein Betrachter für Stücklisten, ob als Programm oder im Browser, erleichtert das Lesen der Datei. Ein Nachweis für die Einhaltung ist er nicht, und die Verordnung sagt zu ihm nichts.

Cybiq verkauft keinen Erzeuger für Stücklisten und empfiehlt keinen bestimmten Anbieter. Was das Regelwerk von der Datei verlangt, lässt sich kurz sagen, und genau das tut diese Seite.

Inhalt und ein Beispiel

Die Verordnung nennt ein Pflichtelement, die obersten Abhängigkeiten, und eine Pflichteigenschaft, ein gängiges maschinenlesbares Format. Alles Weitere ergibt sich aus dem gewählten Format und daraus, was Ihre eigene Behandlung von Schwachstellen braucht, um zu funktionieren.

In der Praxis trägt ein brauchbarer Eintrag den Namen der Komponente, ihre Version, eine eindeutige Kennung wie eine Paket-URL, ihren Lieferanten, ihre Lizenz und ihre Beziehung zu der Komponente, die von ihr abhängt. Am wichtigsten ist die Kennung: Name und Version ohne Koordinate lassen sich gegen keine Schwachstellenquelle abgleichen, was den Zweck zunichtemacht, den die Stückliste in Anhang I Teil II erfüllt.

Ein kleinstmögliches Beispiel ist deshalb keine kurze Datei. Es ist eine vollständige Datei für ein kleines Produkt: jede direkte Abhängigkeit, jeweils mit auflösbarer Kennung, erzeugt beim Erstellen statt von Hand gepflegt, und bei jeder Auslieferung neu erzeugt.

Wer sie erstellen muss und wer sie zu sehen bekommt

Die Pflicht trifft den Hersteller. Einführer und Händler haben keine eigene Pflicht zur Stückliste, doch wer als Einführer oder Händler den eigenen Namen auf ein Produkt setzt, gilt als Hersteller und übernimmt sie. Verwalter quelloffener Software unterliegen einer leichteren Regelung.

Die Datei gehört in die technische Dokumentation, neben das Konzept für die koordinierte Offenlegung von Schwachstellen und die übrigen Nachweise zur Behandlung von Schwachstellen.

„erforderlicher Informationen und Spezifikationen bezüglich der vom Hersteller festgelegten Verfahren zur Behandlung von Schwachstellen, einschließlich der Software-Stückliste“

Nutzer haben keinen Anspruch darauf. Anhang II, die Informationen und Anleitungen für den Nutzer, verlangt nur eine Angabe dazu, wo die Datei zu finden ist, und das auch nur, wenn der Hersteller sie überhaupt bereitstellt.

„für den Fall, dass der Hersteller dem Nutzer die Software-Stückliste zur Verfügung stellt, wo auf die Software-Stückliste zugegriffen werden kann.“

Dieser Vorbehalt klärt einen Punkt, bei dem das Regelwerk oft falsch gelesen wird: Die Stückliste ist eine Pflicht zur Dokumentation, keine Pflicht zur Veröffentlichung. Sie zu veröffentlichen ist eine freie Entscheidung.

Wie sie geprüft wird

Die Prüfung ist kein Regelfall. Anhang VII führt die Stückliste als etwas auf, das einer Marktüberwachungsbehörde auf begründetes Verlangen vorgelegt wird, und auch nur dort, wo die Behörde sie zur Prüfung der grundlegenden Anforderungen braucht.

„gegebenenfalls auf begründetes Verlangen der Marktüberwachungsbehörde die Software-Stückliste, sofern dies erforderlich ist, damit diese Behörde die Einhaltung der grundlegenden Cybersicherheitsanforderungen in Anhang I überprüfen kann.“

Daraus folgen zwei Dinge. Die Datei muss vorhanden und aktuell sein, bevor jemand fragt, denn ein begründetes Verlangen kommt mit einer Frist und nicht mit Zeit für den Aufbau einer Erstellungskette. Und die technische Dokumentation insgesamt ist über den Unterstützungszeitraum aktuell zu halten.

„Die technische Dokumentation wird vor dem Inverkehrbringen des Produkts mit digitalen Elementen erstellt und gegebenenfalls, zumindest während des Unterstützungszeitraums, laufend aktualisiert.“

Eine fehlende oder unzureichende Behandlung von Schwachstellen, und dort sitzt die Pflicht zur Stückliste, fällt in den höchsten Rahmen der Geldbußen und nicht in den verwaltungsrechtlichen.

„werden Geldbußen von bis zu 15 000 000 EUR oder — im Falle von Unternehmen — von bis zu 2,5 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres verhängt, je nachdem, welcher Betrag höher ist.“

Ab wann die Pflicht greift

Die Stückliste steht in Anhang I und kommt damit mit der vollen Geltung am 11. Dezember 2027, nicht mit der Meldepflicht, die seit dem 11. September 2026 gilt. Für die meisten Teams ist sie dennoch die knappere der beiden Vorlaufzeiten, denn eine Meldepflicht braucht ein Verfahren, eine Stückliste dagegen eine Erstellungskette, die sie für jede Auslieferung verlässlich ausgibt.

„Diese Verordnung gilt ab dem 11. Dezember 2027. Artikel 14 gilt jedoch ab dem 11. September 2026, und Kapitel IV (Artikel 35 bis 51) gilt ab dem 11. Juni 2026.“

Die vollständige Abfolge der Daten steht auf der Seite zu den Fristen der Verordnung.