SBOM-Anforderungen im Cyber Resilience Act: Formate, Inhalte und Archivierung

Die Software Bill of Materials - kurz SBOM - ist im Cyber Resilience Act (Verordnung (EU) 2024/2847) Pflichtbestandteil der technischen Dokumentation, die Hersteller von Produkten mit digitalen Elementen vorhalten müssen. Ab dem 11. Dezember 2027 greift die volle Anwendbarkeit der Produktanforderungen; wer die SBOM-Pflicht erst dann angeht, hat die Vorarbeit zu spät begonnen - denn eine verlässliche Stückliste setzt funktionierende Entwicklungs- und Lieferkettenprozesse voraus, die sich nicht über Nacht einrichten lassen.

Wer mit der SBOM-Einführung gerade begonnen hat, steckt noch in einer Pilot- oder Teststufe. Die Lücke zwischen „wir haben angefangen“ und „wir sind CRA-ready“ ist real. Dieser Artikel erklärt, was eine CRA-konforme SBOM konkret enthalten muss, welches Format Sie wählen sollten und warum die Archivierungspflicht nicht unterschätzt werden darf.

Was ist eine SBOM - und warum verlangt der CRA sie?

Eine SBOM ist eine maschinenlesbare Stückliste aller Softwarekomponenten eines Produkts: Bibliotheken, Frameworks, Abhängigkeiten, Lizenzen, Versionen und ihre Beziehungen untereinander. Der CRA fordert sie als Werkzeug für zwei Kernpflichten:

• Schwachstellen-Handling über den gesamten Supportzeitraum: Ohne vollständige Komponentenkenntnis können Hersteller nicht zuverlässig prüfen, ob eine neu bekannt gewordene Schwachstelle (CVE) ihr Produkt betrifft, und eine aktiv ausgenutzte Schwachstelle nicht rechtzeitig melden: Art. 14 verlangt seit dem 11. September 2026 eine Frühwarnung unverzüglich, in jedem Fall innerhalb von 24 Stunden nach Kenntnisnahme, und unverzüglich, spätestens 72 Stunden nach Kenntnisnahme, die Meldung der Schwachstelle.
• Sorgfaltspflicht bei Drittkomponenten (Security-by-Design): Hersteller müssen bei Drittkomponenten die gebotene Sorgfalt walten lassen (Art. 13 Abs. 5) und dafür den Ursprung und den Sicherheitszustand der von ihnen eingesetzten Open-Source- und Drittanbieter-Komponenten kennen und überwachen.

Kurz gesagt: Ohne SBOM ist eine schnelle Schwachstellenmeldung strukturell kaum möglich. Die SBOM ist damit Dokumentationspflicht und zugleich die Arbeitsgrundlage des Schwachstellenmanagements. Mehr zu den Meldefristen erläutert der Artikel CRA Meldepflicht seit 11. September 2026.

Was muss eine CRA-konforme SBOM enthalten?

Der CRA verlangt eine SBOM in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten erfasst (Anhang I Teil II Nr. 1); sie ist Teil der technischen Dokumentation (Anhang VII Nr. 2 Buchst. b). Einzelfelder legt der Verordnungstext nicht fest; Format und Elemente kann die Kommission per Durchführungsrechtsakt bestimmen (Art. 13 Abs. 24). Als Orientierung für die Praxis dienen die Technische Richtlinie BSI TR-03183-2 und die Formatspezifikationen von CycloneDX und SPDX.

Als Orientierung dienen etwa folgende Felder:

End-of-Life (EOL) als unterschätztes Feld

Das EOL-Datum einer Komponente ist im CRA-Kontext besonders relevant: Hersteller müssen Schwachstellen auch in Komponenten über den gesamten Unterstützungszeitraum behandeln (Art. 13 Abs. 6 und 8). Endet der Support einer Komponente früher, muss der Hersteller selbst nachbessern oder die Komponente ersetzen; die Unterstützungszeiträume zugekaufter Komponenten können Hersteller bei der Festlegung ihres eigenen Unterstützungszeitraums berücksichtigen (Art. 13 Abs. 8 UAbs. 2). Deshalb gehört das EOL-Datum in die Planung. Eine SBOM ohne EOL-Informationen gibt keine vollständige Auskunft über das Restrisiko - und erschwert das Schwachstellen-Handling über die gesamte Produktlebensdauer.

CycloneDX oder SPDX - welches Format ist CRA-konform?

Beide Formate sind anerkannte Standards; der CRA schreibt kein Format per Verordnungstext vor. BSI TR-03183-2 (Version 2.1.0) verlangt für neu erstellte SBOMs eines dieser Formate in folgenden Versionen:

• CycloneDX ≥ 1.6 (OWASP-Standard; Stärke: umfangreiche Sicherheits-Metadaten, Vulnerability-Disclosure-Report, Services und Lizenzausdrücke; gut integrierbar mit Dependency-Track und gängigen CI/CD-Pipelines)
• SPDX ≥ 3.0.1 (Linux-Foundation-Standard; Stärke: breite Tool-Unterstützung, starke Lizenz-Ausdrucksmächtigkeit, etabliert in Open-Source-Ökosystemen)

Für sicherheitsorientierte Teams spricht vieles für CycloneDX, weil das Format nativ Schwachstelleninformationen, Bewertungen (etwa CVSS) und das Konzept eines Vulnerability Exploitability Exchange (VEX) abbilden kann - alles Elemente, die für den CRA-Schwachstellen-Meldeprozess unmittelbar nützlich sind. SPDX ist die stärkere Wahl, wenn Lizenz-Compliance im Vordergrund steht oder die Toolchain bereits auf SPDX ausgerichtet ist.

Empfehlung für die Praxis: Entscheiden Sie sich für ein Format und implementieren Sie es konsequent in Ihrer CI/CD-Pipeline - idealerweise so, dass die SBOM bei jedem Build automatisch generiert und in einem zentralen Tool wie Dependency-Track verwaltet wird. Doppelformate sind in bestimmten Lieferkettenkontexten sinnvoll, erhöhen aber den Pflegeaufwand.

Archivierungspflicht: 10 Jahre sind kein Selbstläufer

Eine leicht zu unterschätzende Anforderung im CRA-SBOM-Kontext ist die Archivierungspflicht der technischen Dokumentation. Hersteller müssen die technische Doku - einschließlich SBOM - für einen Zeitraum von mindestens 10 Jahren nach dem Inverkehrbringen des Produkts aufbewahren; ist der Supportzeitraum des Produkts länger als 10 Jahre, verlängert sich die Aufbewahrungspflicht entsprechend (je nachdem, was länger ist).

Was das in der Praxis bedeutet:

• SBOMs müssen versioniert abgelegt werden: der aktuelle Stand und jede relevante historische Version (insbesondere zum Zeitpunkt von Releases und nach Schwachstellenbehebungen).
• Das Ablagesystem muss über Personalwechsel, Unternehmensumstrukturierungen und Technologiewechsel hinaus zugänglich und lesbar bleiben.
• Bei Prüfungen durch Marktüberwachungsbehörden muss die SBOM auf Verlangen vorlegbar sein - nicht erst nach einer Rekonstruktionsphase.

Für Unternehmen, die bisher SBOMs ad hoc oder nur für einzelne Releases erstellt haben, ist die 10-Jahres-Archivierung ein substanzieller Prozess- und Infrastrukturaufwand, der frühzeitig geplant werden sollte.

BSI TR-03183-2: Der deutsche Referenzrahmen

Die Technische Richtlinie BSI TR-03183-2 (aktuell Version 2.1.0) beschreibt, welche Anforderungen an SBOMs im Kontext der Cyber-Resilienz-Anforderungen an Hersteller und Produkte sinnvoll sind. Sie legt zulässige Formate (CycloneDX ab Version 1.6, SPDX ab Version 3.0.1), Pflicht-, Zusatz- und optionale Datenfelder sowie den Detaillierungsgrad einer SBOM fest.

TR-03183-2 ist keine harmonisierte Norm zum CRA. Sie ist dennoch ein nützlicher Referenzpunkt, insbesondere für Hersteller, die im deutschen Markt tätig sind oder mit Behörden und kritischen Infrastrukturen interagieren. Wer sich an TR-03183-2 orientiert, schafft eine gute Ausgangslage für die noch ausstehenden harmonisierten Normen, an denen CEN, CENELEC und ETSI arbeiten.

Welche Produktklasse für Ihr Produkt gilt und welcher Bewertungsweg daraus folgt, erklärt der Artikel CRA-Produktklassen: Standard, Klasse I/II und kritisch.

SBOM in der Lieferkette: Was Hersteller von Zulieferern verlangen sollten

Der CRA wirkt über das fertige Produkt bis in die Lieferkette. Hersteller müssen bei Drittkomponenten die gebotene Sorgfalt walten lassen (Art. 13 Abs. 5). Zulieferer-SBOMs sind dafür ein praktisches Mittel, weil sie Komponenten dokumentieren und den Abgleich gegen Schwachstellendatenbanken ermöglichen.

In der Praxis bedeutet das:

• Zulieferer-SBOMs einfordern: Verträge mit Software-Zulieferern sollten SBOM-Lieferpflichten enthalten - idealerweise im selben Format wie die eigene SBOM (CycloneDX oder SPDX), damit eine maschinelle Integration möglich ist.
• Transitive Abhängigkeiten prüfen: Eine SBOM, die nur direkte Abhängigkeiten abbildet, erfüllt zwar die Mindestanforderung von Anhang I Teil II, reicht für ein verlässliches Schwachstellenmanagement aber nicht aus. Der vollständige Dependency-Graph inklusive transitiver Komponenten sollte bekannt und prüfbar sein.
• Continuous Monitoring einrichten: Die SBOM wird mit jedem Release fortgeschrieben. Neue CVEs werden laufend veröffentlicht; ein Werkzeug wie Dependency-Track gleicht die eigene SBOM kontinuierlich gegen Schwachstellendatenbanken (NVD, OSV) ab und meldet neue Treffer, damit Sie früh prüfen können, ob eine Schwachstelle Ihr Produkt betrifft und ob sie aktiv ausgenutzt wird.

Praxisfahrplan: SBOM-Readiness in vier Schritten

1. Bestandsaufnahme: Welche Produkte bringen Sie auf den EU-Markt? Welche Produktklasse trifft zu? Der Betroffenheits-Check gibt erste Orientierung.
2. Toolchain aufsetzen: SBOM-Generierung in die CI/CD-Pipeline integrieren (z. B. Syft, cdxgen für CycloneDX; Dependency-Track für Management und Monitoring). Format und Mindestfelder festlegen - an TR-03183-2 orientieren.
3. Zulieferer-Anforderungen klären: Bestehende Verträge mit Software-Drittanbietern auf SBOM-Pflichten prüfen und bei Bedarf anpassen.
4. Archivierungsinfrastruktur etablieren: Versionierte, langfristige Ablage der SBOMs sicherstellen - mit Zugriffsprotokoll für Behördenanfragen.

Mit dem kostenlosen SBOM-Check können Sie eine SBOM oder ein Lockfile automatisch auf bekannte Schwachstellen prüfen. Beim Aufbau der SBOM-Praxis unterstützt Blackfort Technology mit der CRA SBOM-Beratung: Wir nehmen mit Ihnen Werkzeuge, Lücken und Überschneidungen auf und legen ein Zielbild mit Plan fest.

Überblick: Alle CRA-Herstellerpflichten

Die SBOM ist eine von mehreren Kernpflichten. Den vollständigen Rahmen - Security-by-Design, CE-Kennzeichnung, technische Dokumentation, Konformitätsbewertung - beschreibt der Pillar-Artikel Cyber Resilience Act: Anforderungen, Fristen & Pflichten für Hersteller.