CRA SBOM-Pflicht — Software Bill of Materials erklärt

CRA SBOM-Pflicht — Software Bill of Materials erklärt

Die SBOM-Pflicht (Software Bill of Materials) nach dem CRA verlangt von Herstellern eine maschinenlesbare Dokumentation aller Software-Komponenten — als Voraussetzung für Schwachstellenmanagement nach CRA und NIS2. Rechtsgrundlage ist die EU-Verordnung 2024/2847: Nach Anhang I Teil II Nr. 1 müssen Hersteller Komponenten und Schwachstellen dokumentieren, einschließlich einer SBOM in einem gebräuchlichen maschinenlesbaren Format, die mindestens die Top-Level-Dependencies des Produkts abdeckt.

Für die Praxis bedeutet das: Eine SBOM ist kein optionales Entwickler-Artefakt mehr, sondern ein Compliance-Baustein für Produkte mit digitalen Elementen. Wenn Sie den regulatorischen Rahmen zuerst einordnen wollen, lesen Sie ergänzend unseren Überblick zum Cyber Resilience Act, die Detailseite zu CRA-Anforderungen und die branchennahen Folgen für vernetzte Geräte in CRA und IoT-Sicherheit.

Was ist eine SBOM (Software Bill of Materials)?

Eine SBOM ist ein formaler Datensatz über die in einem Produkt enthaltenen Software-Bausteine und deren Lieferkettenbeziehungen. Der CRA definiert die Software Bill of Materials in Art. 3 Nr. 39 als formalen Nachweis mit Details und Supply-Chain-Beziehungen der in den Software-Elementen eines Produkts enthaltenen Komponenten. Gemeint ist also nicht nur eine lose Paketliste, sondern eine strukturierte Sicht auf Abhängigkeiten, Versionen und Herkunft.

Für Nicht-Entwickler lässt sich die SBOM am besten als Zutatenliste einer Software beschreiben. Sie zeigt, welche Bibliotheken, Frameworks, Module und gegebenenfalls eingebetteten Komponenten in einem Produkt stecken. Genau diese Transparenz wird wichtig, wenn eine neue Schwachstelle in einer verbreiteten Bibliothek auftaucht und Hersteller schnell prüfen müssen, welche Produkte betroffen sind.

Die SBOM ist deshalb vor allem ein Werkzeug für drei Fragen. Erstens: Welche Drittkomponenten stecken im Produkt? Zweitens: Welche Version wurde konkret verwendet? Drittens: Welche Sicherheits- und Update-Folgen ergeben sich daraus? Ohne diese Transparenz bleibt Schwachstellenmanagement oft reaktiv, manuell und fehleranfällig.

Für Hersteller von Software, IoT-Geräten und eingebetteten Systemen ist die SBOM zudem ein Bindeglied zwischen Entwicklung, Produktsicherheit und Compliance. Sie hilft dem Security-Team bei der Analyse, dem Produktmanagement bei der Lieferantensteuerung und der Rechts- oder Compliance-Funktion bei der technischen Dokumentation. Gerade kleine und mittlere Unternehmen gewinnen dadurch keine Bürokratie um der Bürokratie willen, sondern einen belastbaren Überblick über ihre tatsächliche Software-Lieferkette.

SBOM-Pflicht nach dem Cyber Resilience Act

Die rechtliche Pflicht folgt unmittelbar aus dem CRA, nicht erst aus einer künftigen Marktgewohnheit. Maßgeblich ist Anhang I Teil II Nr. 1 der EU-VO 2024/2847: Hersteller müssen Schwachstellen und Komponenten in Produkten mit digitalen Elementen identifizieren und dokumentieren, unter anderem durch eine SBOM in einem gebräuchlichen maschinenlesbaren Format, die mindestens die Top-Level-Dependencies abdeckt.

Wichtig ist die Einordnung: Der CRA verlangt nicht zwingend, dass jede SBOM öffentlich ins Internet gestellt wird. Die Verordnung macht aber zwei Dinge klar. Erstens gehört die SBOM in den Pflichtenkreis des Herstellers für Vulnerability Handling. Zweitens kann die Europäische Kommission nach Art. 13 Abs. 24 das Format und die Elemente der SBOM per Durchführungsrechtsakt weiter präzisieren. Wer heute sauber mit SPDX oder CycloneDX arbeitet, bereitet sich deshalb auf die spätere Konkretisierung vor, statt auf ein neues Sonderformat zu warten.

Ebenso relevant ist der Zeitplan. Der CRA ist seit dem 10. Dezember 2024 in Kraft. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle beginnen am 11. September 2026. Die übrigen Anforderungen des CRA, also auch die breite Pflicht zu Security-by-Design, Schwachstellenbehandlung und technischer Dokumentation, werden am 11. Dezember 2027 voll anwendbar. Für Hersteller ist die SBOM daher kein Thema für Ende 2027, sondern ein Vorbereitungsprojekt für 2026.

Die SBOM hängt zudem direkt mit dem Rest des CRA zusammen. Wenn Sie verstehen wollen, wie Produktklassifizierung, Dokumentation und Lifecycle-Pflichten zusammenspielen, ist unser Leitfaden zu CRA-Anforderungen der passende nächste Schritt. Für Hersteller vernetzter Geräte ergänzt die Seite CRA und IoT-Sicherheit die operative Perspektive auf Embedded-Software, Komponenten und Updates.

Welche Informationen muss eine SBOM enthalten?

Die wichtigste Antwort zuerst: Der CRA schreibt keinen vollständig ausbuchstabierten Feldkatalog in der Verordnung selbst vor, aber er verlangt einen maschinenlesbaren Nachweis der Komponenten mindestens auf Ebene der Top-Level-Dependencies. Für die Praxis sollten Hersteller daher mehr dokumentieren als nur Paketnamen, weil eine reine Minimal-Liste im Incident-Fall oft nicht genügt.

Mindestens sinnvoll sind folgende Inhalte:

Je komplexer das Produkt, desto wichtiger wird die Trennung zwischen direkter und transitiver Abhängigkeit. Der CRA nennt ausdrücklich mindestens die Top-Level-Dependencies. Praktisch reicht das bei sicherheitskritischen Produkten häufig nicht aus. Wenn eine indirekte Open-Source-Bibliothek über mehrere Ebenen eingebunden ist, kann gerade dort die entscheidende Schwachstelle liegen. Viele Hersteller dokumentieren deshalb nach Möglichkeit auch transitive Abhängigkeiten.

Zusätzlich sollte die SBOM mit anderen Sicherheitsartefakten verzahnt werden. Dazu gehören Vulnerability-Scanner, Release-Notizen, Patch-Prozesse und die technische Dokumentation. Anhang VII des CRA verweist darauf, dass die technischen Unterlagen Informationen zu den Vulnerability-Handling-Prozessen enthalten müssen, einschließlich der SBOM. Das heißt: Die SBOM ist kein isoliertes PDF für Auditoren, sondern Teil einer belastbaren Produktdokumentation.

SBOM-Formate — SPDX, CycloneDX, SWID

Für den CRA gibt es derzeit kein exklusiv vorgeschriebenes SBOM-Format. Relevant ist, dass das Format gebräuchlich und maschinenlesbar ist. In der Praxis dominieren drei Namen: SPDX, CycloneDX und SWID. Sie sind nicht identisch, sondern setzen unterschiedliche Schwerpunkte.

SPDX ist ein offener Standard der SPDX-Community und als ISO/IEC 5962 standardisiert. Er ist besonders stark, wenn Unternehmen Open-Source-Transparenz, Lizenzthemen und Komponentenherkunft sauber dokumentieren wollen. Für Organisationen mit vielen juristischen oder beschaffungsbezogenen Anforderungen ist SPDX oft attraktiv, weil es über reine Sicherheitsdaten hinaus eine breite Compliance-Perspektive unterstützt.

CycloneDX ist stärker aus dem Application-Security- und Supply-Chain-Kontext heraus gewachsen. Das Format ist besonders nützlich, wenn Teams Komponenten, Services, Abhängigkeitsgraphen und Sicherheitsinformationen eng mit DevSecOps-Prozessen verbinden wollen. Für viele CRA-Umsetzungen ist CycloneDX deshalb praktisch, weil es sich gut in Scanner, CI/CD-Pipelines und Schwachstellen-Workflows integrieren lässt.

SWID steht für Software Identification Tags und ist vor allem als Identifikationsstandard bekannt. Für klassische Software-Asset-Management- und Inventarszenarien kann das relevant sein. Im operativen CRA-Alltag sehen viele Hersteller SPDX oder CycloneDX jedoch als naheliegender, weil diese Formate heute stärker im SBOM-Ökosystem der Software-Lieferkette verankert sind.

Die pragmatische Auswahlregel lautet daher: Wenn Lizenz- und Open-Source-Transparenz im Vordergrund stehen, ist SPDX oft sinnvoll. Wenn Security-Automatisierung, Abhängigkeiten und Schwachstellenbezug dominieren, ist CycloneDX meist die bessere Erstwahl. SWID ist eher ein Spezialfall für Identifikation und bestehende Asset-Prozesse.

Wie KMU eine SBOM erstellen — Tools und Prozesse

KMU sollten eine SBOM nicht manuell in Excel aufbauen, sondern automatisiert aus dem Build- und Release-Prozess erzeugen. Der wirtschaftlich sinnvolle Weg ist fast immer: vorhandene Paketmanager, Container-Scanner oder Build-Tools nutzen, SBOM automatisch generieren, dann prüfen, versionieren und mit jedem Release aktualisieren.

Ein einfacher Prozess für kleine Teams sieht so aus:

1. Quellen festlegen. Bestimmen Sie, aus welchen Repositories, Builds, Images oder Firmware-Paketen die SBOM generiert werden soll.
2. Format wählen. Entscheiden Sie sich konsistent für SPDX oder CycloneDX als Primärformat.
3. Generator anbinden. Nutzen Sie automatisierte Tools in CI/CD, damit jede Version eine neue SBOM erhält.
4. Qualität prüfen. Kontrollieren Sie stichprobenartig, ob Komponenten, Versionen und Abhängigkeiten plausibel sind.
5. Freigabe dokumentieren. Hinterlegen Sie SBOM, Release-Version, Erstellungsdatum und verantwortliche Rolle.
6. Schwachstellen koppeln. Verknüpfen Sie die SBOM mit Scannern und einem Prozess für Nachverfolgung, Priorisierung und Patching.

Für viele KMU sind folgende Werkzeuge praxistauglich:

• Syft für die schnelle Generierung von SBOMs aus Dateien, Containern und Images.
• Trivy für die Verbindung von Schwachstellenscan und SBOM-Erzeugung.
• OWASP Dependency-Track für Verwaltung, Anreicherung und Auswertung von SBOM-Daten.
• CycloneDX-Plugins für Maven, Gradle, npm, Yarn, Python oder .NET.
• SPDX-Tools für Validierung und standardnahe Weiterverarbeitung.

Entscheidend ist aber nicht das Tool allein, sondern die Prozessreife. Eine technisch erzeugte, aber nie aktualisierte SBOM ist für Compliance fast wertlos. Sie brauchen Zuständigkeiten, eine Release-Logik und einen sauberen Abgleich mit Ihren Support- und Patch-Prozessen. Gerade im Mittelstand scheitern SBOM-Projekte weniger am Scanner als an fehlender Verantwortung zwischen Entwicklung, IT-Sicherheit und Produktmanagement.

Wenn Ihr Unternehmen bereits mit offenen Komponenten oder selbst gehosteten KI-Stacks arbeitet, hilft außerdem unser Überblick zu Open-Source-KI und EU AI Act. Dort sehen Sie, warum Komponenten-Transparenz nicht nur ein CRA-Thema ist, sondern auch für Governance, Dokumentation und Anbietersteuerung wichtig wird.

SBOM und Open-Source-Komponenten — Besondere Herausforderungen

Open Source macht die SBOM nicht schwieriger, sondern unverzichtbar. Gerade weil moderne Produkte auf vielen Open-Source-Bibliotheken, Frameworks und Images aufbauen, steigt ohne SBOM das Risiko, kritische Abhängigkeiten zu übersehen. Der CRA behandelt Open Source dabei differenziert: Frei geteilte Open-Source-Software ohne kommerzielle Tätigkeit kann ausgenommen sein, aber sobald Komponenten in ein kommerzielles Produkt eingebunden werden, bleibt der Hersteller für das Gesamtprodukt verantwortlich.

Die erste Herausforderung ist die Tiefe der Abhängigkeiten. Viele Produkte nutzen nur wenige direkte Libraries, ziehen darüber aber Hunderte transitive Abhängigkeiten nach. Ohne automatisierte Analyse bleibt diese Tiefe unsichtbar. Die zweite Herausforderung ist die Namens- und Versionsqualität. Unterschiedliche Paketquellen, Forks oder unklare Komponentenkennungen erschweren später die Schwachstellenzuordnung.

Die dritte Herausforderung ist organisatorisch. Open Source wird in KMU oft dezentral beschafft: ein Entwickler fügt schnell ein Paket hinzu, ein anderes Team übernimmt ein Container-Image, ein Lieferant liefert eingebettete Komponenten mit. Wenn diese Entscheidungen nicht in einem gemeinsamen Freigabe- und Dokumentationsprozess landen, ist die SBOM am Ende lückenhaft. Genau deshalb ist die SBOM auch ein Governance-Thema der Lieferkette und nicht nur ein Artefakt für Security Engineers.

Hier gibt es eine enge Verbindung zu NIS2-naher Supply-Chain-Sicherheit. NIS2 verlangt kein identisches Produktdokument wie der CRA, legt aber starken Wert auf organisatorisches Risikomanagement in der Lieferkette. Eine aktuelle SBOM macht diese Transparenz technisch greifbar. Für Hersteller, die beide Regime im Blick behalten, ist die SBOM deshalb ein Übersetzungspunkt zwischen Produktsicherheit und Lieferkettensteuerung.

Vorteile einer SBOM über die Compliance hinaus

Eine gute SBOM reduziert nicht nur Rechtsrisiken, sondern beschleunigt operative Sicherheitsarbeit. Wenn eine neue kritische Schwachstelle bekannt wird, ist die wichtigste Frage immer dieselbe: Sind wir betroffen? Mit aktueller SBOM lässt sich diese Frage in Stunden oder Minuten beantworten. Ohne SBOM beginnt oft erst dann die mühsame Suche nach Komponenten, Versionen und betroffenen Produktlinien.

Zweitens verbessert die SBOM die Zusammenarbeit mit Kunden, Integratoren und Aufsichtsstellen. Sie dokumentiert, dass Ihr Unternehmen seine Software-Lieferkette kontrolliert und Schwachstellen nicht erst im Ernstfall improvisiert. Gerade im B2B-Geschäft wird das zunehmend ein Vertrauens- und Ausschreibungsthema.

Drittens schafft die SBOM bessere Entscheidungsgrundlagen für Produktentwicklung und Einkauf. Teams erkennen schneller, wo veraltete Komponenten Risiken bündeln, welche Bibliotheken kritisch von einzelnen Maintainern abhängen oder wo Alternativen mit besserem Support sinnvoll wären. Damit wird die SBOM zu einem Instrument für technische Schulden, Lifecycle-Management und Lieferantenstrategie.

Viertens stärkt die SBOM die Schnittstelle zu anderen Regulierungen und Standards. Sie unterstützt Supply-Chain-Sicherheit im NIS2-Kontext und passt gut zu dokumentierten Governance-Strukturen, wie sie größere Organisationen in einem AI- oder IT-Managementsystem abbilden. Eine SBOM ersetzt solche Rahmenwerke nicht, erleichtert aber deren Nachweislogik erheblich.

Häufig gestellte Fragen (FAQ)

Ist eine SBOM für jedes Produkt Pflicht?

Eine pauschale Pflicht für jedes beliebige digitale Artefakt lässt sich zu grob formuliert nicht aus dem CRA ableiten. Maßgeblich ist, ob Ihr Produkt als Produkt mit digitalen Elementen in den Anwendungsbereich der EU-VO 2024/2847 fällt. Wenn das der Fall ist, gehört die Dokumentation von Komponenten und Schwachstellen einschließlich SBOM in den Pflichtenkreis des Vulnerability Handling.

Welches Format soll ich verwenden?

Für die meisten Hersteller ist SPDX oder CycloneDX die richtige Wahl. SPDX ist stark für Lizenz- und Open-Source-Transparenz, CycloneDX für Security- und Automatisierungsprozesse. Eine inferenzbasierte Empfehlung aus den aktuellen Ökosystemen lautet: KMU mit DevSecOps-Fokus starten meist besser mit CycloneDX, Unternehmen mit starkem Lizenz- und Beschaffungsfokus häufig mit SPDX.

Wie oft muss die SBOM aktualisiert werden?

Die SBOM sollte bei jeder produktrelevanten Änderung aktualisiert werden, spätestens also bei jedem Release mit geänderten Komponenten oder Versionen. Rechtlich nennt der CRA keinen pauschalen Monatsrhythmus, sondern verlangt wirksames Vulnerability Handling über den Produktlebenszyklus. Praktisch heißt das: neue Version, neue Komponenten, neue SBOM.

Gibt es Tools für die automatische SBOM-Erstellung?

Ja. Gängige Build- und Security-Werkzeuge erzeugen heute automatisch SPDX- oder CycloneDX-Dateien. Entscheidend ist, dass diese Generierung in Ihre Pipeline eingebettet wird und nicht als gelegentlicher Einmal-Export endet.

Muss die SBOM öffentlich sein?

Nein, nicht zwingend. Der CRA verlangt nicht generell eine öffentliche Veröffentlichung. Behörden können sie aber im Rahmen ihrer Kontrollaufgaben anfordern, und wenn Hersteller sie Nutzern zur Verfügung stellen, muss dokumentiert sein, wo sie zugänglich ist.

Der nächste sinnvolle Schritt für Hersteller

Die operative Priorität ist klar: Warten Sie nicht auf den letzten Durchführungsrechtsakt, sondern bauen Sie jetzt einen einfachen SBOM-Prozess auf. Starten Sie mit einem Produkt, wählen Sie ein Format, erzeugen Sie SBOMs automatisiert pro Release und verknüpfen Sie sie mit Schwachstellenmanagement, Supportdauer und technischer Dokumentation. So wird aus einer abstrakten CRA-Pflicht ein beherrschbarer Standardprozess.

Wenn Sie regulatorische Pflichten im Unternehmen nicht nur technisch, sondern nachvollziehbar kommunizieren wollen, nutzen Sie unseren Kurs zur KI-Governance und EU-Compliance als kompakten Einstieg in dokumentierte Governance- und Nachweisprozesse. Für den fachlichen Unterbau helfen außerdem unser Überblick zum Cyber Resilience Act, die Seite CRA-Anforderungen und der Hub zu Open-Source-KI und EU AI Act.