Was die Cyberresilienz-Verordnung von einer SBOM verlangt

Zuletzt aktualisiert: 2026-09-30

Die Cyberresilienz-Verordnung (Cyber Resilience Act, Verordnung (EU) 2024/2847) verlangt von Herstellern, im Rahmen der Behandlung von Schwachstellen eine Software-Stückliste (SBOM) zu erstellen. Der Text verlangt ein gängiges maschinenlesbares Format, aus dem zumindest die obersten Abhängigkeiten hervorgehen, und ordnet die SBOM der technischen Dokumentation zu. Die Anforderung gilt ab dem 11. Dezember 2027, zusammen mit den Hauptpflichten der Verordnung.

Was der Text sagt

Die Begriffsbestimmung, Artikel 3 Nummer 39:

"„Software-Stückliste“ eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind;"

Die Anforderung, Anhang I Teil II Nummer 1. Die Hersteller von Produkten mit digitalen Elementen 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;"

Wo sie abgelegt wird, Anhang VII Nummer 2 Buchstabe b (Fortsetzung von „einschließlich“ in Nummer 2):

"erforderlicher Informationen und Spezifikationen bezüglich der vom Hersteller festgelegten Verfahren zur Behandlung von Schwachstellen, einschließlich der Software-Stückliste, des Konzepts für die koordinierte Offenlegung von Schwachstellen, des Nachweises der Bereitstellung einer Kontaktadresse für die Meldung der Schwachstellen und einer Beschreibung der gewählten technischen Lösungen für die sichere Verbreitung von Aktualisierungen;"

Wer sie verlangen kann, Anhang VII Nummer 8:

"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."

Das Format, Artikel 13 Absatz 24:

"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."

Veröffentlichung, Erwägungsgrund 77:

"Die Hersteller sollten nicht verpflichtet sein, die Software-Stückliste zu veröffentlichen."

Was das in der Praxis bedeutet

Der Text nennt kein Format. Er spricht von einem „gängigen maschinenlesbaren Format“; weder CycloneDX noch SPDX kommen in der Verordnung vor. Stand 29. September 2026 hat die Kommission keinen Durchführungsrechtsakt nach Artikel 13 Absatz 24 zu Format und Elementen der SBOM erlassen.
Nach dem Wortlaut sind die obersten Abhängigkeiten die Mindesttiefe. Das Wort „zumindest“ setzt eine Untergrenze, keine Obergrenze.
Die SBOM gehört zur Behandlung von Schwachstellen. Artikel 13 Absatz 8 verlangt, dass Schwachstellen beim Inverkehrbringen des Produkts und während des Unterstützungszeitraums behandelt werden.
Der Text verlangt nicht ausdrücklich eine SBOM pro Release. Bei einfacher Lesart ist eine Aufzeichnung der Komponenten jeder in Verkehr gebrachten Version das, was es einem Hersteller erlaubt zu sagen, welche Versionen eine bestimmte Komponente enthalten.
Die SBOM ist Teil der technischen Dokumentation, die die Hersteller nach Artikel 13 Absatz 13 „nach dem Inverkehrbringen des Produkts mit digitalen Elementen mindestens zehn Jahre lang oder für die Dauer des Unterstützungszeitraums, je nachdem, welcher Zeitraum länger ist“ aufbewahren müssen.
Ob die SBOM veröffentlicht wird, entscheidet der Hersteller. Stellt der Hersteller den Nutzern die SBOM zur Verfügung, verlangt Anhang II Nummer 9 die Angabe, wo auf sie zugegriffen werden kann.
Behörden können sie verlangen: auf begründetes Verlangen (Anhang VII Nummer 8) und für eine unionsweite Bewertung der Abhängigkeit (Artikel 13 Absatz 25).

Was Sie als Nachweis aufbewahren sollten

Die SBOM jeder in Verkehr gebrachten Version, als die Datei, die Ihr Build erzeugt hat.
Einen Hash und einen Zeitstempel für jede Datei, um zu zeigen, dass sie sich nicht verändert hat.
Name und Version des Werkzeugs, das sie erzeugt hat, und das Format.
Die in jeder Version gefundenen Schwachstellen, wann Sie davon Kenntnis erlangt haben und was getan wurde. Artikel 13 Absatz 7 verlangt, dass der Hersteller relevante Cybersicherheitsaspekte „systematisch“ dokumentiert.
Wo auf die SBOM zugegriffen werden kann, wenn Sie sie den Nutzern zur Verfügung stellen.

Wo DevKit Dossier ansetzt

DevKit Dossier führt ein SBOM-Archiv pro Release. Ihre CI erzeugt mit Syft oder Trivy eine CycloneDX- oder SPDX-JSON-Datei und lädt sie hoch; DevKit Dossier ist kein Scanner und speichert die Datei Byte für Byte, mit Hash und Upload-Zeitstempel. Täglich gleicht es die aktuelle SBOM jedes Releases mit OSV und den GitHub-Advisories, CISA KEV, EPSS und NVD-Werten ab; außerdem erstellt es ein Lizenzinventar und ein Nachweispaket (eine ZIP-Datei mit pack.json, pack.pdf, den SBOMs Byte für Byte und einer README.txt) als Beilage zur technischen Dokumentation nach Anhang VII. Es unterstützt Ihre Nachweise: Es leistet keine Rechtsberatung, nimmt keine Zertifizierung vor und übermittelt nichts an die einheitliche Meldeplattform der ENISA. Es wird in der EU gehostet, funktioniert im Self-Service und kostet pauschal 49, 99 oder 249 EUR pro Monat und Organisation, mit einer 14-tägigen Testphase.

Auf die Warteliste

Quellen

Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung)

Dieser Leitfaden enthält allgemeine Informationen und ist keine Rechtsberatung.