Mit dem Cyber Resilience Act (CRA) der Europäischen Union tritt eine Regulierung in Kraft, die die Software- wie Hardwarebranche grundlegend verändern wird. Im Zentrum stehen Anforderungen, die bislang vor allem in sicherheitskritischen Bereichen bekannt waren. Eine davon trifft die Softwarebranche speziell: die Software Bill of Materials (SBOM). Was bisher eine freiwillige Best Practice war, wird künftig für Hersteller unter dem CRA zur Pflicht.
Was ist eine SBOM und warum ist sie so wichtig?
Eine SBOM ist im Kern eine strukturierte Liste aller Komponenten, die in einem Softwareprodukt enthalten sind, d.h. aller Bibliotheken, Frameworks etc. Dazu gehören Open-Source-Bibliotheken, (proprietäre) Drittanbieter-Module, Abhängigkeiten (dependencies) und deren Versionen. Die SBOM soll damit Transparenz über den genauen Aufbau einer Software schaffen.
Moderne Softwareprodukte bestehen zu großen Teilen aus fremdem Code. Studien zeigen, dass in typischen Anwendungen bis zu 80 % des Codes aus Open-Source-Komponenten stammt. Jede dieser Komponenten kann Schwachstellen enthalten, wie der berühmte Log4Shell-Vorfall 2021 als pars pro toto eindrücklich gezeigt hat. Hersteller sollen es durch die SBOM ermöglichen, Schwachstellen in den Softwareprodukten schnell zu erkennen und beheben zu können.
Was der CRA konkret fordert
Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen (darunter kann auch reine Software fallen) dazu, eine SBOM zu erstellen und aktuell zu halten. Konkret bedeutet das:
- Vollständige Auflistung aller Software-Komponenten inklusive Versionsangaben
- Maschinenlesbare Formate (z. B. laut BSI TR-03183 SPDX oder CycloneDX)
- Kontinuierliche Aktualisierung über den gesamten Produktlebenszyklus
- Bereitstellung gegenüber Marktaufsichtsbehörden auf Anfrage (aber keine allgemeine Veröffentlichungspflicht)
Der CRA gilt für nahezu alle Produkte mit Netzwerkanbindung, seien es IoT-Geräte oder Unternehmenssoftware bis hin zu eingebetteten Systemen. Die Übergangsfrist läuft bis Ende 2027. Viele Unternehmen sind daher bereits mit der Anpassung ihrer Update- und Release-Zyklen hinsichtlich des CRA beschäftigt.
Herausforderungen in der Praxis
Die Umsetzung klingt technisch simpel. Operativ kämpfen viele Unternehmen aber mit gewachsenen Codebases, fehlenden Prozessen und einer Vielzahl indirekter Abhängigkeiten, also Abhängigkeiten von Abhängigkeiten. Besonders herausfordernd ist die Pflege: Eine SBOM ist kein einmaliges Dokument, sondern muss mit jeder Code-Änderung synchronisiert werden. Ein Einbinden in das vorhandene Tooling, insb. CI/CD-Pipelines ist daher nahezu unerlässlich.
Unsere Empfehlung: Jetzt beginnen
Die SBOM-Pflicht ist kein isoliertes Thema. Sie ist vielmehr Teil eines umfassenderen Paradigmenwechsels hin zu mehr Softwaretransparenz und -verantwortung im Rahmen des CRA. Unternehmen sollten zunächst eine Bestandsaufnahme ihrer Softwareprodukte durchführen, geeignete SBOM-Tools evaluieren und die Erstellung in ihre Entwicklungsprozesse integrieren. Gleichzeitig sollte eine umfassende CRA-Compliance in den Blick genommen werden.
Häufig gestellte Fragen (FAQ)
KI-Systeme fallen unter den CRA, wenn sie als Produkte mit digitalen Elementen in Verkehr gebracht werden. Eine klassische SBOM greift hier zu kurz: Sie erfasst Code-Abhängigkeiten, nicht aber KI-Modelle oder Trainingsdaten als eigenständige Risikokomponenten. Die G7-Cybersicherheitsbehörden (darunter das BSI) haben im Mai 2026 Mindestanforderungen für eine „SBOM for AI“ veröffentlicht, die u.a. Angaben zu Modellherkunft, Trainingsdaten, Lizenzen und KI-spezifischen Sicherheitskontrollen umfassen. Auch wenn diese Empfehlungen noch nicht rechtsverbindlich sind, sollten Hersteller von KI-Produkten die erweiterten Anforderungen jetzt in ihre SBOM-Prozesse einplanen.
Grundsätzlich ja. Der CRA gilt für alle Hersteller, die Produkte mit digitalen Elementen in der EU in Verkehr bringen – unabhängig von der Unternehmensgröße. Für Kleinstunternehmen sind prozedurale Erleichterungen vorgesehen, etwa ein vereinfachtes Format für die technische Dokumentation, Leitlinien und Regulatory Sandboxes. Die SBOM selbst muss aber denselben inhaltlichen Anforderungen genügen wie bei größeren Herstellern.
Der CRA schreibt kein spezifisches Format vor, verweist aber auf maschinenlesbare Industriestandards. In der Praxis haben sich SPDX (von der Linux Foundation) und CycloneDX (von OWASP) als führende Formate etabliert und werden von den gängigen Tools unterstützt (und auch in der BSI TR-03183 genannt).
Nein, eine generelle Veröffentlichungspflicht besteht nicht. Die SBOM muss jedoch Marktaufsichtsbehörden auf Anfrage vorgelegt werden können. Unternehmen können selbst entscheiden, ob und in welchem Umfang sie ihre SBOM gegenüber Kunden oder der Öffentlichkeit offenlegen. Zunehmend dürften Kunden in Vertragsverhandlungen danach fragen, da deren Existenz kaum bestritten werden kann.
Ja. Bei schwerwiegenden Verstößen gegen den CRA können Bußgelder von bis zu EUR 15 Millionen oder 2,5 % des weltweiten (Konzern-)Jahresumsatzes verhängt werden. Zudem riskieren Unternehmen den Ausschluss vom EU-Markt.
Das hängt stark von der Reife der bestehenden Entwicklungsprozesse ab. Mit modernen Tools lässt sich die SBOM-Generierung in wenigen Wochen in CI/CD-Pipelines integrieren. Der größere Aufwand liegt in der initialen Bestandsaufnahme und der organisatorischen Verankerung des Prozesses.