SBOM für Softwarehersteller – Was der CRA verlangt und wie man sie praktisch umsetzt

Von codAIx GmbH | April 2026

Das Zeitalter der Transparenz hat längst begonnen: Softwarehersteller müssen ab 11. Dezember 2027 eine vollständige Software Bill of Materials (SBOM) für alle ihre Produkte bereitstellen – das fordert der Cyber Resilience Act (CRA) unmissverständlich [1]. Eine SBOM ist kein theoretisches Konzept mehr, sondern ein Geschäftsdokument, das zeigt, woraus Ihre Software wirklich besteht und wo die Sicherheitsrisiken liegen. In diesem Artikel erfahren Sie, welche Anforderungen der CRA konkret stellt, welche Standards und Formate anerkannt sind, wie Sie die SBOM-Generierung automatisieren – und warum eine SBOM für KI-Produkte komplexer ist als für traditionelle Software.

Rückblick: SBOM im Kontext der CRA-Serie

In Artikel 1 zur SaaS und dem CRA haben wir die grundsätzliche Erfassung von Softwareprodukten behandelt. Artikel 3 zu den abgestuften CRA-Pflichten führte in die abgestuften Herstellerpflichten nach Art. 13 CRA ein – und dort findet sich die SBOM als eine der zentralen Dokumentationspflichten. In Artikel 5 zur doppelten Regulierung durch AI Act und CRA und Artikel 6 zu Hochrisiko-KI sahen wir, wie KI-Komponenten zusätzliche Komplexität in die Lieferkette bringen.

Heute fokussieren wir auf das Praktische: Was muss in eine CRA-konforme SBOM rein? Welche Tools helfen bei der Generierung? Und wie vermeidet man häufige Fallstricke?

Was der CRA konkret zur SBOM verlangt

Rechtliche Grundlagen

Der CRA verankert die SBOM-Anforderung in mehreren Bestimmungen [1]:

• Anhang I Teil II Nr. 1 (Anforderungen an die Behandlung von Schwachstellen): Die zentrale SBOM-Pflicht – Hersteller 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" (Wortlaut der deutschen Verordnungsfassung).
• Artikel 13 (Pflichten der Hersteller): Abs. 5 verpflichtet Hersteller zur Sorgfaltspflicht (Due Diligence) bei der Integration von Drittanbieter-Komponenten, einschließlich quelloffener Software ("free and open-source software").
• Anhang VII (Inhalt der technischen Dokumentation): Legt den gesamten Umfang der technischen Dokumentation fest, innerhalb derer die SBOM ein Element darstellt – neben Risikoanalyse, Systemarchitektur und Schwachstellenmanagement.

Die Verordnung ist seit 10. Dezember 2024 in Kraft [1]. Die Meldepflichten für kritische Schwachstellen beginnen bereits ab 11. September 2026 – und ohne SBOM wird eine effektive Schwachstellenverwaltung unmöglich. Die vollen Compliance-Anforderungen gelten erst ab 11. Dezember 2027.

Empfohlener Mindestumfang gemäß BSI TR-03183 und Industriestandards

Der CRA selbst schreibt lediglich ein „gängiges maschinenlesbares Format" vor, aus dem „zumindest die obersten Abhängigkeiten" hervorgehen [1]. Die BSI TR-03183 [2] und die NTIA Minimum Elements [6] konkretisieren dies zu folgenden empfohlenen Mindestinformationen:

1. Komponentenidentifikation

- Name der Komponente - Version - Eindeutige Identifikatoren (CPE, PURL oder vergleichbar) - Herkunft (interner Code vs. Open Source)

1. Lizenzinformationen

- SPDX-Lizenzbezeichner für jede Komponente - Angabe, ob die Lizenz mit dem Produkt kompatibel ist

1. Abhängigkeitsbaum

- Direkte und transitive Abhängigkeiten - Abhängigkeitsauflösung auf alle tieferen Ebenen

1. Vulnerabilität-Bezüge

- NVD-CVE-Nummern (National Vulnerability Database) - Links zu Sicherheitsadvisories

1. Herstellerangaben

- Name des Komponentenherstellers - Kontaktdaten des Herkunftsrepositoriums (z.B. GitHub-URL für OSS)

1. Versionierungsinformationen

- Zeitstempel der SBOM-Erstellung - Versionsnummer der SBOM selbst

Formate: SPDX und CycloneDX

Der CRA akzeptiert grundsätzlich mehrere maschinenlesbare Formate [1][5], aber die Praxis hat zwei Standards etabliert:

SPDX (Software Package Data Exchange) [3]

• ISO/IEC 5962 Standard
• Besonders weit verbreitet im Enterprise-Umfeld
• Formate: JSON, XML, RDF, Tag-Value
• Fokus auf Lizenzcompliance und Komponenten-Genealogie

CycloneDX [4]

• Optimiert für Sicherheit und Supply Chain Risk Management
• Nativer Vulnerability-Support
• Schlanker als SPDX, oft besser für CI/CD-Integration
• Formate: JSON, XML
• Wachsend in der Praxis bei DevOps-Teams

Empfehlung: Für CRA-Compliance empfehlen wir JSON-formatiertes SPDX als Primärformat – es ist am weitesten standardisiert – plus CycloneDX als ergänzendes Format, um Schwachstelleninformationen präzise zu dokumentieren.

BSI TR-03183 Teil 2 als praktischer Leitfaden

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Technische Richtlinie TR-03183 Teil 2 zum Thema "Software Bill of Materials" erstmals im August 2023 veröffentlicht und seitdem kontinuierlich weiterentwickelt (aktuelle Version 2.0.0 vom September 2024) [2]. Sie ist quasi die "CRA-Bedienungsanleitung" für deutsche und europäische Softwarehersteller.

Was die TR-03183 Teil 2 leistet

Die TR-03183 konkretisiert:

• Mindestanforderungen für maschinenlesbare SBOMs in SPDX- und CycloneDX-Format
• Checklisten für die SBOM-Validierung
• Best Practices für Dateneingabe und Qualitätskontrolle
• Integration mit Vulnerability Disclosure Processes
• Anforderungen an die SBOM-Pflege über den Produktlebenszyklus

Praktische Richtlinien aus TR-03183 Teil 2

1. SBOM muss mit jedem Release aktualisiert werden – nicht bloß einmalig erstellen und vergessen
2. Transitive Abhängigkeiten zu Tiefe 4+ erfassen – nicht nur direkte Abhängigkeiten
3. Ungenaue Versionsnummern vermeiden – Ranges wie "1.2.x" sind unzulässig
4. Lizenzkonflikte frühzeitig erkennen – GPL-Kompatibilität (GNU General Public License) prüfen
5. Automatisierte Generierung + manuelle Qualitätskontrolle (Best Practice gemäß BSI TR-03183) – kein vollständig automatischer Prozess ohne Review

Mindestumfang einer CRA-konformen SBOM

Checkliste für das Minimale

☐ SBOM in SPDX JSON oder CycloneDX XML/JSON
☐ Alle direkten Abhängigkeiten der 1. Ebene
☐ Alle transitiven Abhängigkeiten (bis Tiefe ≥ 3)
☐ SPDX-Lizenzbezeichner für jede Komponente
☐ CPE oder PURL für eindeutige Identifikation
☐ NVD/CVE-Cross-References wo vorhanden
☐ Komponentenherkunft (Source URL oder Repository)
☐ Versionsnummern (exakt, keine Ranges)
☐ Erstellungszeitstempel und SBOM-Version
☐ Herstellerangaben (name, contact)

Was gilt NICHT als SBOM

Häufige Missverständnisse:

• Dependency Lock Files (package-lock.json, poetry.lock) sind keine SBOM. Sie sind zwar öffentlich spezifiziert, erfüllen aber die NTIA Minimum Elements [6] nicht: Es fehlen strukturierte Angaben zum Komponentenhersteller (Supplier Name), eindeutige Identifikatoren wie CPE oder PURL sowie standardisierte Abhängigkeitsbeziehungen. Für CRA-Konformität müssen sie in ein SPDX- oder CycloneDX-Format überführt werden.
• Manuell gepflegte Excel-Listen sind zwar technisch maschinenlesbar, gelten aber nicht als „gängiges maschinenlesbares Format" im Sinne des CRA (Anhang I Teil II Nr. 1) [1]. Die Praxis und die BSI TR-03183 Teil 2 [2] haben sich auf SPDX und CycloneDX als anerkannte Standardformate verständigt.
• Interne Build-Artefakte ohne externe Referenzen reichen nicht aus. Die NTIA Minimum Elements [6] und die BSI TR-03183 Teil 2 [2] verlangen eindeutige Identifikatoren (CPE, PURL) und Herkunftsangaben, über die Komponenten auch außerhalb Ihrer Build-Umgebung nachvollziehbar sind – Voraussetzung dafür, dass Aufsichtsbehörden und nachgelagerte Nutzer die SBOM überhaupt verwenden können.

So gehen Sie es richtig an

Die gute Nachricht: Der Weg zu einer CRA-konformen SBOM lässt sich weitgehend automatisieren – genau dort setzt crAIready an. Unsere AI-gestützte SaaS-Plattform mappt die CRA-SBOM-Pflichten aus Anhang I Teil II Nr. 1 und Anhang VII automatisch auf Ihr Produkt, prüft vorhandene SBOMs gegen die Mindestanforderungen aus BSI TR-03183 und NTIA Minimum Elements und zeigt offene Lücken in einem Compliance-Dashboard mit Ampelstatus und priorisiertem Maßnahmen-Backlog – kontinuierlich und audit-fest, statt als einmalige Beratung, die im nächsten Release veraltet ist.

Der Einstieg ist unser CRA Quick Assessment: In fünf bis sieben Werktagen erhalten Sie einen belastbaren Bericht darüber, wo Ihre SBOM-Dokumentation heute steht, welche Lücken gegenüber dem CRA bestehen und welche Top-10-Maßnahmen Sie zuerst angehen sollten.

SBOM für KI-Produkte – Die zusätzliche Komplexität

Falls Ihr Produkt KI-Komponenten enthält (Bezug zu Artikel 5 und Artikel 6), wird die SBOM komplexer:

ML-Komponenten, die dokumentiert werden müssen

1. Trainings-Datasets

- Herkunft und Zusammensetzung - Größe, Zeitraum der Erhebung - Datenqualitätsprobleme (Bias, Label-Errors)

1. Pre-trained Models

- Model Card (huggingface, Google) mit Trainingsdaten-Quellen - Framework und Version (PyTorch 2.0, TensorFlow 2.14 etc.) - Abhängigkeiten (CUDA, ONNX Runtime)

1. Feature Engineering Pipelines

- Datenverarbeitungsschritte vor Modell-Input - Abhängigkeiten (Pandas, Scikit-learn, benutzerdefinierte Tools) - Versionierung des Feature-Schemas

1. Validation & Testing Abhängigkeit

- Test-Datasets - Metriken-Libraries (MLflow, Weights & Biases) - Evaluierungsskripte

Empfohlene Erweiterung: ML-SBOM-Standard (Draft)

Die NTIA [6] und führende Security-Organisationen arbeiten an einem ML BOM Standard, der noch nicht offiziell in den CRA aufgenommen ist, aber faktisch erwartet wird:

• Model Inventory: Name, Version, Trainings-Datum, Genauigkeitsmetriken
• Data Inventory: Trainingsdaten-Quellen, Größen, Bias-Tests
• Dependency Inventory: ML-Framework, Libraries, Runtime-Dependencies

Als Best Practice empfehlen wir: Dokumentieren Sie ML-Komponenten zusätzlich in strukturiertem Format (JSON oder YAML), auch wenn der Standard noch nicht vollständig in den CRA aufgenommen ist.

Warum SBOM-Compliance in der Praxis scheitert

Die rechtlichen Anforderungen klingen auf dem Papier überschaubar – „gängiges maschinenlesbares Format", „oberste Abhängigkeiten". Was uns in Gesprächen mit Herstellern regelmäßig begegnet, ist eine ganz andere Realität: SBOMs, die einmal erzeugt und nie wieder aktualisiert wurden. Dependency-Listen, die bei der ersten Ebene aufhören, obwohl die Angriffsfläche in Tiefe 3 oder 4 liegt. Versionsangaben als Ranges statt als exakte Pins, so dass eine „reproducible SBOM" gar nicht möglich ist. Interne Microservices, die aus der Stückliste herausfallen. Fehlende Verknüpfung mit CVE-Daten, so dass eine neu gemeldete Schwachstelle im Unternehmen niemand aufruft.

Das ist kein Tool-Problem. Es ist ein kontinuierliches Compliance-Problem – eines, das jeden Release, jedes Dependency-Update und jede neu gemeldete Schwachstelle erneut bearbeitet werden muss. Genau daran scheitern in unserer Erfahrung die meisten internen Initiativen: Die erste SBOM wird noch engagiert erstellt, aber Monate später ist sie veraltet, widerspricht dem Code, und beim ersten Audit fällt auf, dass zentrale Angaben nach Anhang I Teil II Nr. 1 und Anhang VII CRA fehlen.

crAIready für Ihre SBOM-Compliance

crAIready ist die AI-gestützte SaaS-Plattform, die genau diesen Teil der CRA-Pflichten für Sie übernimmt:

• Automatisches Requirement-Mapping Ihrer Produkte gegen die 39 CRA-Anforderungen – inklusive der SBOM-Pflichten aus Anhang I Teil II Nr. 1 und der Dokumentationspflichten aus Anhang VII.
• Kontinuierliche Gap-Analyse Ihrer SBOM-Dokumentation gegen CRA, BSI TR-03183 Teil 2 und die NTIA Minimum Elements – mit Ampelstatus und priorisiertem Maßnahmen-Backlog.
• Laufendes Monitoring der dokumentierten Abhängigkeiten, ihrer Versionsstände und bekannter Schwachstellen – so dass eine veraltete oder widersprüchliche SBOM sichtbar wird, bevor der Auditor sie findet.
• Audit-feste Dokumentation nach Anhang VII CRA auf Knopfdruck, inklusive Tamper-Proof-Logging aller Änderungen.

Der Einstieg ist unser CRA Quick Assessment: In 5–7 Werktagen erhalten Sie einen belastbaren Bericht, wo Ihre SBOM- und Compliance-Dokumentation heute steht, welche Lücken CRA-relevant sind und welche Top-10-Maßnahmen Sie zuerst angehen sollten – zum Festpreis und ohne Beratungsabhängigkeit.

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act – CRA), insbesondere Art. 13 (Pflichten der Hersteller), Anhang I Teil II Nr. 1 (SBOM-Pflicht), Anhang VII (Inhalt der technischen Dokumentation). ABl. L, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

[2] Bundesamt für Sicherheit in der Informationstechnik (BSI): Technische Richtlinie TR-03183 Teil 2 – „Cyber Resilience Requirements for Manufacturers and Products – Part 2: Software Bill of Materials (SBOM)", erstmals veröffentlicht August 2023, aktuelle Version 2.0.0 vom September 2024. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03183/BSI-TR-03183-2.pdf

[3] SPDX Project: SPDX Specification Version 3.0 (ISO/IEC 5962), abrufbar unter https://spdx.github.io/spdx-spec/v3.0/ – Internationaler Standard für maschinenlesbare Software-Stücklisten mit Fokus auf Lizenz-Compliance.

[4] CycloneDX Project: CycloneDX Specification (ECMA-424), abrufbar unter https://cyclonedx.org/specification/overview/ – OWASP-Projekt für SBOM-Erstellung mit Fokus auf Sicherheit und Supply Chain Risk Management.

[5] SPDX ist als ISO/IEC 5962:2021 standardisiert; CycloneDX als ECMA-424. Beide Formate gelten in der Praxis als „gängige maschinenlesbare Formate" im Sinne des CRA (Anhang I Teil II Nr. 1).

[6] National Telecommunications and Information Administration (NTIA): Minimum Elements for a Software Bill of Materials (SBOM), abrufbar unter https://ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf – US-Bundesrichtlinie zu SBOM-Mindestanforderungen, die als internationale Referenz dient.

Hinweis zur Methodik

Dieser Artikel basiert auf dem offiziellen Verordnungstext des Cyber Resilience Act [1] in der deutschen Sprachfassung, der BSI-Richtlinie TR-03183 Teil 2 [2] und den Industriestandards SPDX [3] und CycloneDX [4]. Die wörtlichen Zitate aus Anhang I Teil II Nr. 1 wurden gegen die deutsche Amtsblatt-Fassung (ABl. L vom 20.11.2024) abgeglichen. Wichtig: Der CRA selbst schreibt für SBOMs lediglich ein „gängiges maschinenlesbares Format" mit mindestens den „obersten Abhängigkeiten" vor (Anhang I Teil II Nr. 1). Die detaillierten Inhaltskategorien in diesem Artikel orientieren sich an der BSI TR-03183, den NTIA Minimum Elements [6] und den Best Practices der SPDX/CycloneDX-Communities – sie gehen über den Mindeststandard des CRA hinaus.

Sie fragen sich: „Wo steht mein Unternehmen bei der SBOM-Compliance?" – Nutzen Sie unseren crAIready Quick Check, um in wenigen Minuten zu sehen, wie weit Ihr Unternehmen auf dem Weg zur vollständigen CRA-Konformität ist:

→ Jetzt zum crAIready Quick Check

Im nächsten Artikel dieser Serie: CRA-Meldepflichten ab September 2026 — welche Fristen für aktiv ausgenutzte Schwachstellen gelten, wie die ENISA-Meldeplattform funktioniert und wie Sie Ihre Vulnerability-Disclosure-Prozesse jetzt aufstellen, damit Sie ab dem 11. September 2026 rechtssicher melden können.