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) keine Option, sondern Teil der verbindlichen 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 belastbare Stückliste setzt funktionierende Entwicklungs- und Lieferkettenprozesse voraus, die sich nicht über Nacht einrichten lassen.

In der Praxis zeigt sich: Viele Unternehmen haben mit der SBOM-Einführung zwar begonnen, befinden sich aber noch in einer frühen 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 entsprechend nicht innerhalb von 24 Stunden eine Frühwarnung absetzen, wie es Art. 14 ab dem 11. September 2026 verlangt.
• Sorgfaltspflicht bei Drittkomponenten (Security-by-Design): Hersteller müssen nachweisen, dass sie 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 nicht nur Dokumentationspflicht, sondern operatives Fundament des Vulnerability-Managements. Mehr zu den Meldefristen erläutert der Artikel CRA Meldepflicht ab 11. September 2026.

Was muss eine CRA-konforme SBOM enthalten?

Der CRA selbst definiert keine SBOM-Mindestfelder im Verordnungstext, verweist aber auf die technische Dokumentation (Anhang I, Teil II) und — über die zu entwickelnden harmonisierten Normen — auf etablierte Standards. Als Orientierung für die Praxis gilt derzeit das Zusammenspiel aus dem BSI-Standard TR-03183-2 und den Formatspezifikationen von CycloneDX und SPDX.

Folgende Felder gelten in der Fachwelt als Mindestinhalt einer CRA-tauglichen SBOM:

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

Das EOL-Datum einer Komponente ist im CRA-Kontext besonders relevant: Hersteller müssen den Supportzeitraum ihres Produkts ausweisen, und dieser Zeitraum setzt implizit voraus, dass alle eingesetzten Komponenten diesen Zeitraum aktiv mit Sicherheitsupdates abdecken können. 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. Die Empfehlung aus BSI TR-03183-2 und den bisherigen Entwürfen harmonisierter Normen lautet jedoch eindeutig:

• 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)

In der Praxis wählen sicherheitsorientierte Teams häufig CycloneDX, weil das Format nativ Vulnerability-Informationen, Exploit-Scores 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 der am häufigsten unterschätzten Anforderungen 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 — nicht nur der aktuelle Stand, sondern 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 Anfrage vorliegbar 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 konkretisiert für den deutschen und europäischen Markt, welche Anforderungen an SBOMs im Kontext des CRA sinnvoll sind. Sie beschreibt Mindestfelder, Reifegradmodelle und empfohlene Prozesse für Erstellung, Pflege und Weitergabe von SBOMs entlang der Lieferkette.

Auch wenn TR-03183-2 kein offiziell harmonisierter CRA-Standard ist, gilt sie als wichtiger 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, ist in der Regel gut aufgestellt für die noch ausstehenden harmonisierten Normen, deren Entwicklung unter CEN/CENELEC läuft.

Die Frage, welche Produktklasse Ihr Produkt betrifft und wie das die Tiefe Ihrer SBOM-Anforderungen beeinflusst, beantwortet der Artikel CRA-Produktklassen: Standard, Klasse I/II und kritisch.

SBOM in der Lieferkette: Was Hersteller von ihren Zulieferern fordern müssen

Der CRA wirkt nicht nur auf das fertige Produkt, sondern auf die gesamte Lieferkette. Hersteller, die Drittkomponenten oder Software-Subkomponenten von anderen Anbietern beziehen, müssen sicherstellen, dass diese Komponenten ihrerseits dokumentiert und schwachstellenseitig überwacht werden können.

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, reicht für CRA-Zwecke in der Regel nicht aus. Der vollständige Dependency-Graph inklusive transitiver Komponenten sollte bekannt und prüfbar sein.
• Continuous Monitoring einrichten: Die SBOM ist kein einmaliges Dokument, sondern ein lebendiges Artefakt. Neue CVEs erscheinen täglich; ein Tool wie Dependency-Track ermöglicht den kontinuierlichen Abgleich der eigenen SBOM gegen Schwachstellendatenbanken (NVD, OSV) und gibt Alarm, bevor eine Meldepflicht entsteht.

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.

Eine detaillierte Gap-Analyse Ihrer bestehenden SBOM-Praxis gegenüber den CRA-Anforderungen bietet Blackfort Technology als strukturierten SBOM Gap-Report an.

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