Von Redaktion codAIx | 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.

Quellenhierarchie für die SBOM-Pflicht: Der CRA-Verordnungstext (EU 2024/2847) ist als Primärrecht unmittelbar EU-weit bindend; er verlangt für die SBOM nur „ein gängiges maschinenlesbares Format" mit den „obersten Abhängigkeiten" (Anhang I Teil II Nr. 1). Harmonisierte EU-Normen — entwickelt von CEN/CENELEC im Rahmen des Normungsauftrags M/606 der EU-Kommission — sollen ab Q3/Q4 2026 die technischen Detailfragen einheitlich konkretisieren. Bis dahin ist die TR-03183 Teil 2 v2.1.0 des Bundesamtes für Sicherheit in der Informationstechnik (BSI) die ausgereifteste nationale Konkretisierung in Deutschland: nicht EU-weit bindend, aber faktischer State-of-the-Art für deutsche Hersteller, deutsche notifizierte Stellen und das BSI als Koordinator-CSIRT nach Art. 14 CRA. Sie geht in Detailpunkten (z. B. SPDX-Mindestversion, Pflichtfelder) über den CRA-Mindeststandard hinaus. Bei Konflikt zwischen EU- und nationaler Ebene gilt die EU-Vorgabe.

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

Legaldefinition: Was ist eine SBOM nach dem CRA?

Die SBOM ist keine blosse Branchenkonvention, sondern ein im CRA legaldefinierter Begriff. Nach Art. 3 Nr. 39 CRA ist eine SBOM die formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind [1][7]. Diese Definition ist der Anker für sämtliche operativen Pflichten – ohne strukturierte Komponentenliste mit dokumentierten Lieferkettenbeziehungen liegt im Sinne des CRA keine SBOM vor.

Rechtliche Grundlagen

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

  • Art. 3 Nr. 39 CRA (Begriffsbestimmung): Legaldefinition der SBOM als formale Aufzeichnung der Komponenten und ihrer Lieferkettenbeziehungen [1][7].
  • 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, einschliesslich quelloffener Software ("free and open-source software"); systematisch ordnet der CRA-Kommentar von Wiebe die SBOM ausdrücklich diesem Lieferantenmanagement nach Art. 13 Abs. 5 CRA zu — sie ist nicht nur Schwachstellen-Werkzeug, sondern ein Lieferketten-Transparenzinstrument [11]. Abs. 6 regelt die Pflicht, festgestellte Schwachstellen in eingebetteten Komponenten dem Komponentenhersteller zu melden; bei eigener Behebung sind auch der geänderte Code bzw. die technischen Unterlagen mitzuteilen, idealerweise in maschinenlesbarem Format [12]. Abs. 22 regelt die Übermittlung an die Marktüberwachungsbehörde auf deren begründetes Verlangen — alle Informationen und Unterlagen, die für den Konformitätsnachweis nach Anhang I erforderlich sind. Abs. 9 verlangt darüber hinaus, dass bereitgestellte Sicherheitsaktualisierungen für mindestens 10 Jahre oder die verbleibende Dauer des Unterstützungszeitraums verfügbar bleiben (je nachdem, welcher Zeitraum länger ist) [13].
  • Anhang VII (Inhalt der technischen Dokumentation): Legt den gesamten Umfang der technischen Dokumentation fest, innerhalb derer die SBOM dokumentiert wird — zusammen mit der Cybersicherheitsrisikobewertung nach Art. 13 Abs. 3 CRA, dem Konzept zur Gewährleistung eines angemessenen Cybersicherheitsniveaus und einer Begründung, weshalb bestimmte Anforderungen nach Anhang I keine Anwendung gefunden haben [14]. Die technische Dokumentation einschliesslich der SBOM ist nach Art. 13 Abs. 13 CRA für mindestens 10 Jahre nach dem Inverkehrbringen des Produkts bzw. für die Dauer des Unterstützungszeitraums den Marktüberwachungsbehörden zur Verfügung zu halten — je nachdem, was länger dauert [15].

Die Verordnung ist seit 10. Dezember 2024 in Kraft [1]. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle 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.

Sanktionsrisiko: Verstösse gegen Anhang I Teil II Nr. 1 (SBOM-Pflicht) sowie gegen Art. 13/14 CRA fallen nach Art. 64 Abs. 2 CRA in die höchste Bussgeldstufe — bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist [16]. Die SBOM ist damit keine Form-Pflicht, sondern unmittelbar bussgeldbewehrt.

Hinweis zu Open-Source-Verwaltern: Stiftungen oder gemeinnützige Organisationen, die quelloffene Software systematisch zur Unterstützung kommerzieller Tätigkeiten anderer pflegen, sind nach Art. 3 Nr. 14 + Art. 24 CRA Verwalter quelloffener Software — keine Hersteller. Sie trifft daher keine eigenständige SBOM-Pflicht; sie müssen aber eine Cybersicherheitsstrategie entwickeln (Art. 24 Abs. 1 CRA) und Meldepflichten erfüllen (Art. 24 Abs. 3 CRA i. V. m. Art. 14 Abs. 1, 3 und 8 CRA) [17]. Wer dagegen FOSS-Komponenten in das eigene Produkt integriert und das Produkt in Verkehr bringt, ist Hersteller mit voller SBOM-Pflicht — die Verwalter-Privilegierung gilt nur für die Pflege selbst, nicht für die Integration in Drittprodukte.

Keine Veröffentlichungspflicht – aber Bereitstellungspflicht gegenüber Behörden

Ein häufiges Missverständnis: Die SBOM muss nicht öffentlich publiziert werden. Sie ist primär ein internes Lieferketten-Tracking-Instrument und kein Marketing-Dokument. Das stellt Erwägungsgrund 77 CRA klar – Hersteller sind nicht verpflichtet, die SBOM einer breiten Öffentlichkeit, ihren Kunden oder Konkurrenten gegenüber offenzulegen [1][8].

Anders sieht es bei Anfragen der Marktüberwachungsbehörde aus: Nach Art. 13 Abs. 22 CRA muss die SBOM zusammen mit den übrigen Konformitätsnachweisen auf begründetes Verlangen an die zuständige Behörde übermittelt werden; gestützt wird dies durch die 10-Jahre-Aufbewahrungspflicht nach Art. 13 Abs. 13 CRA für die technische Dokumentation [1][8][15]. Operativ heisst das:

  • Die SBOM muss jederzeit aktuell und bereitstellbar sein – idealerweise in einem Repository, aus dem sie reproduzierbar exportiert werden kann.
  • Vertraulichkeitsinteressen (Geschäftsgeheimnisse, Lieferantenverträge) bleiben gewahrt, weil die Übergabe nur an die Behörde erfolgt – nicht an Kunden oder Wettbewerber.
  • Eine reine „Schubladen-SBOM" reicht aber nicht: Wenn die Behörde eine SBOM anfordert, muss sie die Anhang-I-Anforderungen erfüllen und das tatsächliche Produkt zum Zeitpunkt der Anfrage abbilden.

Sonderfall — freiwillige Weitergabe an Nutzer: Stellt ein Hersteller seinen Nutzern die SBOM freiwillig zur Verfügung (zum Beispiel an Grosskunden im B2B-Kontext oder zur Unterstützung von deren eigener Schwachstellenanalyse), muss nach Anhang II Nr. 9 CRA die Art des Zugriffs auf die Liste in der Nutzeranleitung beschrieben werden [18]. Aus der freiwilligen Bereitstellung folgt also keine Veröffentlichungspflicht, aber eine Pflicht zur transparenten Dokumentation des Zugriffswegs.

Mindest-Unterstützungszeitraum und SBOM-Pflege — drei Fristen, die zu unterscheiden sind

Die SBOM ist kein einmaliges Release-Artefakt, sondern verkettet sich operativ mit drei unterschiedlichen Fristen des CRA, die in der Praxis häufig verwechselt werden:

1. Mindest-Unterstützungszeitraum (Art. 13 Abs. 8 CRA) — typischerweise 5 Jahre. Hersteller müssen Sicherheitsupdates und Schwachstellenbehandlung grundsätzlich für mindestens 5 Jahre nach Inverkehrbringen sicherstellen. Erwägungsgrund 60 CRA nennt aber ausdrücklich auch Produktkategorien, die typischerweise länger genutzt werden — neben Hardwarekomponenten (Hauptplatinen, Mikroprozessoren) und Netzwerkgeräten (Router, Modems, Switches) auch bestimmte Softwareprodukte wie Betriebssysteme oder Videobearbeitungstools sowie industrielle Steuerungssysteme [1][9]. Umgekehrt darf der Unterstützungszeitraum nach Art. 13 Abs. 8 UAbs. 3 S. 2 CRA auch kürzer als 5 Jahre sein, wenn die voraussichtliche Nutzungsdauer des Produkts dies trägt — Hersteller müssen die festgelegte Frist begründen und dokumentieren [9].

2. Verfügbarkeit von Sicherheitsupdates (Art. 13 Abs. 9 CRA) — mindestens 10 Jahre. Davon zu unterscheiden ist eine separate Pflicht: Bereitgestellte Sicherheitsaktualisierungen müssen für mindestens 10 Jahre oder die verbleibende Dauer des Unterstützungszeitraums verfügbar bleiben — je nachdem, welcher Zeitraum länger ist [13]. Operativ heisst das: Jede ausgelieferte Update-Version koppelt sich mit der zugehörigen SBOM-Version, und beides muss über die jeweils längere Frist abrufbar bleiben.

3. Aufbewahrung der technischen Dokumentation (Art. 13 Abs. 13 CRA) — mindestens 10 Jahre. Die SBOM ist Bestandteil der technischen Dokumentation nach Anhang VII Nr. 2 lit. b CRA (Vorlage auf Verlangen: Nr. 8). Aus Art. 13 Abs. 13 CRA folgt daher: Die SBOM ist mit der übrigen technischen Dokumentation und der EU-Konformitätserklärung mindestens 10 Jahre nach dem Inverkehrbringen des Produkts bzw. für die Dauer des Unterstützungszeitraums den Marktüberwachungsbehörden zur Verfügung zu halten — je nachdem, was länger dauert [15].

Operativ folgt daraus: Die SBOM muss über den gesamten Unterstützungszeitraum gepflegt und insgesamt mindestens 10 Jahre vorhanden sein. Neu gemeldete Schwachstellen in eingebetteten Komponenten – auch in tiefen transitiven Abhängigkeiten – müssen über die SBOM nachvollziehbar werden. Das bedeutet:

  • Versionierung der SBOM parallel zur Produktversionierung (jedes Update erzeugt eine neue SBOM-Version).
  • Rückverfolgbarkeit zwischen ausgelieferten Produktinstanzen und der jeweils gültigen SBOM, damit bei einer neuen CVE in einer Komponente alle betroffenen Releases identifiziert werden können.
  • Fortlaufende Schwachstellen-Recherche gegen die in der SBOM dokumentierten Komponenten – nicht nur bei Major-Releases, sondern kontinuierlich.

Eine SBOM, die zum Releasezeitpunkt korrekt war, aber drei Jahre später keine neuen CVE-Einträge mehr berücksichtigt, erfüllt die CRA-Anforderungen nicht.

Wie real das Lieferketten-Risiko ist, zeigte der Angriff „Shai-Hulud" im November 2025: Über kompromittierte npm-Pakete verbreitete sich Schadcode entlang der Abhängigkeitsketten; betroffen war unter anderem eine weit verbreitete Browser-Erweiterung, der dadurch verursachte Schaden lag im Millionenbereich [10]. Der Vorfall ist kein CRA-Anwendungsfall im engeren Sinne — das blosse Teilen von Open-Source-Paketen in einem offenen Repository gilt für sich genommen nicht als Inverkehrbringen — er illustriert aber präzise, warum der CRA eine vollständige, gepflegte SBOM verlangt: Nur wer seine transitiven Abhängigkeiten kennt und dokumentiert, kann nach einem solchen Lieferkettenangriff überhaupt feststellen, ob das eigene Produkt betroffen ist.

Empfohlener Mindestumfang gemäss 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 „Minimum Elements" der US-amerikanischen National Telecommunications and Information Administration (NTIA) [6] beschreiben den engen Kern dessen, was eine SBOM mindestens enthalten soll — sieben Datenfelder (Hersteller, Komponentenname, Version, eindeutige Identifikatoren, Abhängigkeitsbeziehung, SBOM-Ersteller, Zeitstempel). Die BSI TR-03183 Teil 2 [2] und die gelebte Praxis (CycloneDX, SPDX) gehen darüber hinaus und ergänzen insbesondere Lizenz- und Schwachstellen-Bezüge. Daraus ergeben sich folgende empfohlene Mindestinformationen für eine CRA-konforme SBOM:

  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 und SBOM-Ersteller

- Zeitstempel der SBOM-Erstellung - Versionsnummer der SBOM selbst - SBOM-Ersteller (Werkzeug oder Person, die die SBOM generiert hat — NTIA-Pflichtfeld „Author of SBOM Data")

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: Wählen Sie das Format am Use-Case aus. SPDX 3.0.1 oder höher (aktuelle Mindestversion gemäss BSI TR-03183 Teil 2 v2.1.0 [2]; ISO/IEC 5962:2021 standardisiert die ältere Fassung SPDX 2.2.1 [3]) wenn Lizenz-Compliance führend ist; CycloneDX 1.6 oder höher (standardisiert als ECMA-424, 1. Auflage Juni 2024 [4]) wenn Security-Operations, CVE-Matching und CI/CD-Integration im Vordergrund stehen. Im Zweifel beide Formate parallel ausgeben – beide werden vom CRA Anhang I Teil II Nr. 1 [1] und der BSI TR-03183 Teil 2 v2.1.0 [2] als gängige maschinenlesbare Formate akzeptiert.

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 Fassung ist Version 2.1.0 (2025) [2]. Sie ist quasi die „CRA-Bedienungsanleitung" für deutsche und europäische Softwarehersteller.

Was die TR-03183 Teil 2 leistet

Die TR-03183 Teil 2 v2.1.0 konkretisiert [2]:

  • Mindestanforderungen für maschinenlesbare SBOMs in CycloneDX (v1.6 oder höher) oder SPDX (v3.0.1 oder höher) als zulässige Formate
  • Mapping zwischen den im BSI-Datenmodell genannten Pflichtfeldern und den jeweiligen SPDX-/CycloneDX-Feldern
  • Checklisten für die SBOM-Validierung (u. a. Lizenzangaben als SPDX-Bezeichner, Hashwerte z. B. SHA-512, Executable/Archive/Structured-Properties)
  • Best Practices für Dateneingabe und Qualitätskontrolle
  • Behandlung neu eingeführter Komponenten­arten (virtuelle und referenzierte Komponenten)
  • Integration mit Vulnerability-Disclosure-Prozessen
  • Anforderungen an die SBOM-Pflege über den Produktlebenszyklus

Praktische Richtlinien aus TR-03183 Teil 2

  1. SBOM muss mit jedem Release aktualisiert werden – nicht bloss einmalig erstellen und vergessen
  2. Transitive Abhängigkeiten so tief erfassen, dass die für die Schwachstellenbewertung relevanten Komponenten sichtbar sind – nicht nur direkte Abhängigkeiten; eine starre Mindesttiefe gibt die BSI TR-03183 hier nicht vor
  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äss 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, so tief erfasst, dass die für die Schwachstellenbewertung relevanten Komponenten sichtbar sind ☐ 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) ☐ Pflege über den Mindest-Unterstützungszeitraum (≥ 5 Jahre) ☐ Bereitstellbar gegenüber Marktüberwachungsbehörde nach Art. 13 Abs. 22 CRA (i. V. m. Art. 13 Abs. 13 CRA) ``

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 ausserhalb Ihrer Build-Umgebung nachvollziehbar sind – Voraussetzung dafür, dass Aufsichtsbehörden und nachgelagerte Nutzer die SBOM überhaupt verwenden können.

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össe, 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 Entwicklung eines ML-BOM-Standards treiben aktuell vor allem CycloneDX (OWASP) mit Machine-Learning-Komponenten und Model-Card-Unterstützung ab v1.5 (Juni 2023, ausgebaut in v1.6 und v1.7) und SPDX 3.0 mit dem dortigen AI Profile voran; ergänzend hat die US-amerikanische CISA AI-SBOM-Empfehlungen veröffentlicht. Im CRA-Text ist ein ML-BOM-Standard noch nicht ausdrücklich verankert, in der Praxis aber bereits faktisch erwartbar:

  • Model Inventory: Name, Version, Trainings-Datum, Genauigkeitsmetriken
  • Data Inventory: Trainingsdaten-Quellen, Grössen, 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ässig 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, und das über den gesamten Mindest-Unterstützungszeitraum von 5 Jahren (bei Hardware ggf. länger). 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 KI-gestützte CRA-Compliance-Plattform, die Sie bei diesem Teil der CRA-Pflichten entlastet:

  • SBOM & Lieferkette (Modul 2): automatische Stückliste aus Ihren Repositories in CycloneDX 1.6 und SPDX 3.0.1 — orientiert an BSI TR-03183 Teil 2 —, versioniert und exportierbar über die Vertragsdauer.
  • Lieferketten-Sorgfalt (Modul 2): für jede Drittkomponente eine abgestufte Due Diligence nach Art. 13 Abs. 5 — mit Lieferantenbewertung oder Lifecycle-Check (Upstream aktiv, EOL-Datum, Release-Kadenz).
  • Schwachstellen-Monitoring (Modul 3): täglicher Abgleich aller SBOM-Komponenten gegen NVD, OSV, GitHub Advisory und CISA KEV — so wird eine betroffene Komponente sichtbar, bevor der Auditor sie findet.
  • Dokumentation & Audit-Log (Modul 4, Fundament): technische Dokumentation nach Anhang VII; jede Änderung manipulationssicher protokolliert und 10 Jahre aufbewahrt (Art. 13 Abs. 13).

Eine erste, kostenlose Orientierung — unabhängig von der Plattform — bietet der öffentliche CRA-Quick-Check: In wenigen Minuten erhalten Sie eine orientierende Einschätzung, wo Ihr Unternehmen bei der CRA- und SBOM-Compliance steht.

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. 3 Nr. 39 (Begriffsbestimmung SBOM), Art. 13 (Pflichten der Hersteller, einschl. Abs. 5 Sorgfaltspflicht und Abs. 22 Übermittlung auf begründetes Verlangen), Anhang I Teil II Nr. 1 (SBOM-Pflicht), Anhang VII (Inhalt der technischen Dokumentation), Erwägungsgründe 60 und 77. 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 Fassung Version 2.1.0 (2025). v2.1.0 ergänzt insbesondere ein Mapping zwischen Datenfeldern und den SBOM-Formaten SPDX und CycloneDX, eine überarbeitete Lizenzregelung sowie virtuelle und referenzierte Komponenten. Übersichtsseite und Download (EN): https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/tr-03183.html – PDF (EN): https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2_v2_1_0.pdf

[3] SPDX Project: Software Package Data Exchange® Specification. Als ISO/IEC 5962:2021 international standardisierte Fassung ist SPDX 2.2.1 (https://www.iso.org/standard/81870.html). Die SPDX-Community pflegt die Spezifikation darüber hinaus weiter; verbreitete praktische Versionen sind SPDX 2.3 (Aug 2022) und SPDX 3.0/3.0.1, abrufbar unter https://spdx.dev/. Fokus: maschinenlesbare Software-Stücklisten mit starkem Lizenz- und Provenienz-Modell.

[4] CycloneDX (OWASP-Projekt): Bill of Materials Specification, von Ecma International standardisiert als ECMA-424. 1. Auflage Juni 2024 (CycloneDX v1.6); 2. Auflage Dezember 2025 (CycloneDX v1.7). Standard-Seite: https://ecma-international.org/publications-and-standards/standards/ecma-424/ – Spezifikation im Volltext: https://cyclonedx.org/specification/overview/. Fokus: Supply-Chain-Security, CVE-Bezüge, CI/CD-Integration.

[5] SPDX 2.2.1 ist als ISO/IEC 5962:2021 standardisiert; CycloneDX 1.6 bzw. 1.7 sind als ECMA-424 (1. bzw. 2. Auflage) standardisiert. Beide Formate gelten in der Praxis und gemäss BSI TR-03183 Teil 2 [2] 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.

[7] Wiebe, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 6 Rn. 19 (zur Legaldefinition der SBOM nach Art. 3 Nr. 39 CRA).

[8] Jossen, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 5 Rn. 128 und Fn. 104 (zur Klarstellung, dass die SBOM nicht zu veröffentlichen, aber gegenüber der Marktüberwachungsbehörde bereitzustellen ist; mit Bezug auf Erwägungsgrund 77 CRA; Jossen, Fn. 104, zitiert abweichend Erwgr. 78). Die im Verordnungstext einschlägigen Bereitstellungspflichten sind Art. 13 Abs. 22 CRA (Übermittlung auf begründetes Verlangen) i. V. m. Art. 13 Abs. 13 CRA (Aufbewahrung zur Verfügung der Marktüberwachungsbehörden).

[9] Wiebe, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 6 Rn. 25–27 (zum Mindest-Unterstützungszeitraum und zur operativen Verkettung mit der SBOM-Pflege; vgl. auch Erwägungsgrund 60 CRA für Hardware-Produkte).

[10] The Hacker News, „Weekly Recap: IoT Exploits, Wallet Breaches, Rogue Extensions, AI Abuse & More", Januar 2026, zum npm-Lieferkettenangriff „Shai-Hulud" (zweite Welle, November 2025). Verfügbar unter: https://thehackernews.com/2026/01/weekly-recap-iot-exploits-wallet.html. Hinweis: Fachmedien-Quelle, herangezogen als illustratives Vorfallbeispiel, nicht als juristische Primärquelle.

[11] Wiebe, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 6 Rn. 19 (zur systematischen Verortung der SBOM im Lieferantenmanagement nach Art. 13 Abs. 5 CRA).

[12] Wiebe, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 6 Rn. 20 (zur Pflicht des Herstellers nach Art. 13 Abs. 6 CRA, Schwachstellen in eingebetteten Komponenten dem Komponentenhersteller zu melden und bei eigener Behebung den geänderten Code bzw. die Unterlagen ggf. in maschinenlesbarem Format mitzuteilen).

[13] Wiebe, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 6 Rn. 35 (zur 10-Jahres-Verfügbarkeit von Sicherheitsupdates nach Art. 13 Abs. 9 CRA).

[14] Wiebe, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 5 Rn. 87 und § 6 Rn. 14 (zur Aufnahme der Cybersicherheitsrisikobewertung nach Art. 13 Abs. 3 CRA, des Cybersicherheits­konzepts und der Begründung nicht angewendeter Anhang-I-Anforderungen in die technische Dokumentation gemäss Art. 13 Abs. 4 CRA und Anhang VII).

[15] Verordnung (EU) 2024/2847 — Art. 13 Abs. 13 CRA: „Die Hersteller bewahren die technische Dokumentation und die EU-Konformitätserklärung nach dem Inverkehrbringen des Produkts mit digitalen Elementen mindestens zehn Jahre lang oder für die Dauer des Unterstützungszeitraums, je nachdem, welcher Zeitraum länger ist, für die Marktüberwachungsbehörden auf." Vgl. auch Wiebe, § 5 Rn. 88 und § 6 Rn. 8 (zur Aufbewahrungspflicht).

[16] Jossen, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 7 Rn. 58 (zur Sanktionsstufe nach Art. 64 Abs. 2 CRA: bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres bei Verstössen gegen Anhang I sowie gegen Art. 13/14 CRA, einschliesslich der SBOM-Pflicht in Anhang I Teil II Nr. 1).

[17] Wiebe, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 4 Rn. 38 und § 6 Rn. 4 (zu den Verwaltern quelloffener Software nach Art. 3 Nr. 14 und Art. 24 CRA — eigene Cybersicherheitsstrategie und Meldepflichten, aber keine Hersteller-SBOM-Pflicht).

[18] Jossen, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 5 Rn. 147 (zur Pflicht aus Anhang II Nr. 9 CRA, bei freiwilliger Bereitstellung der SBOM den Zugriffsweg in der Nutzeranleitung zu beschreiben).

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]. Als juristischer Kommentar zur Auslegung wurde der CRA-Kommentar von Wiebe (Hrsg.), Nomos 2025 [7][8][9][11][12][13][14][16][17][18] herangezogen, insbesondere für die Legaldefinition nach Art. 3 Nr. 39 CRA (Wiebe § 6 Rn. 19), die Klarstellung zur Nicht-Veröffentlichungspflicht in Verbindung mit der Bereitstellungspflicht gegenüber Marktüberwachungsbehörden nach Art. 13 Abs. 22 und Abs. 13 CRA (Jossen § 5 Rn. 128 / Fn. 104), die Verkettung von SBOM-Pflege mit dem Mindest-Unterstützungszeitraum (Wiebe § 6 Rn. 25–27; Erwägungsgrund 60 CRA), die 10-Jahres-Verfügbarkeit von Sicherheitsupdates nach Art. 13 Abs. 9 CRA (Wiebe § 6 Rn. 35), die Meldepflicht gegenüber Komponentenherstellern nach Art. 13 Abs. 6 CRA (Wiebe § 6 Rn. 20), die Sanktionsdimension nach Art. 64 Abs. 2 CRA (Jossen § 7 Rn. 58), die Privilegierung der Verwalter quelloffener Software nach Art. 24 CRA (Wiebe § 4 Rn. 38, § 6 Rn. 4) sowie die Anleitungs-Pflicht aus Anhang II Nr. 9 CRA bei freiwilliger SBOM-Bereitstellung (Jossen § 5 Rn. 147). Die wörtlichen Zitate aus Anhang I Teil II Nr. 1 und aus Art. 13 Abs. 13 CRA 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. Das im Abschnitt zum Mindest-Unterstützungszeitraum genannte Beispiel des npm-Lieferkettenangriffs „Shai-Hulud" [10] beruht auf einem Fachmedienbericht; es dient der Illustration des Lieferketten-Risikos und ist kein CRA-Anwendungsfall im engeren Sinne. Stand: 26.05.2026. Letzte Korrekturschleife (Kommentar-Abgleich Wiebe gegen Artikel 07, ein Korrektur- und ein unabhängiger Verifikations-Agent): Art. 13 Abs. 22 CRA als korrekter Verordnungsbezug für die Bereitstellung an die Marktüberwachungsbehörde gesetzt (ersetzt frühere Bezugnahme auf Art. 13 Abs. 7); Art. 13 Abs. 13 CRA und die zugehörige 10-Jahre-Aufbewahrungspflicht der technischen Dokumentation ergänzt; Art. 13 Abs. 6 CRA (Meldung an Komponentenhersteller, ggf. mit Code in maschinenlesbarem Format) ergänzt; Art. 13 Abs. 9 CRA (10 Jahre Verfügbarkeit Sicherheitsupdates) als eigenständige Frist abgegrenzt; Erwgr. 60 CRA korrekt erweitert um Software-Beispiele (Betriebssysteme, Videobearbeitungstools, industrielle Steuerungssysteme) und die Möglichkeit eines kürzeren Unterstützungszeitraums bei kürzerer Nutzungsdauer (Art. 13 Abs. 8 UAbs. 3 S. 2 CRA); Sanktionsdimension Art. 64 Abs. 2 CRA aufgenommen; Verwalter quelloffener Software (Art. 24 CRA) als Klarstellung zur SBOM-Abgrenzung aufgenommen; freiwillige Bereitstellung an Nutzer mit Anleitungs-Pflicht aus Anhang II Nr. 9 CRA ergänzt; Verortung der SBOM im Lieferantenmanagement nach Art. 13 Abs. 5 CRA ausgesprochen; Verzeichnis der Anhang-VII-Bestandteile (Risikobewertung, Cybersicherheits­konzept, Begründung nicht angewendeter Anforderungen) ergänzt. Davor (gleicher Stand): Mindestinformationen präzisiert, NTIA-Kern aus sieben Datenfeldern von den BSI-/Praxis-Erweiterungen Lizenz und Vulnerabilität abgegrenzt, „Author of SBOM Data" als SBOM-Ersteller in Kategorie 6 ergänzt, starre Zahlen zur Abhängigkeits-Tiefe durch eine risikoorientierte Formulierung ersetzt, ML-BOM-Standard-Abschnitt korrigiert (Treiber sind CycloneDX und SPDX 3.0 mit AI Profile, nicht NTIA), BSI und NTIA bei Erstnennung ausgeschrieben.

Sie fragen sich: „Wo steht mein Unternehmen bei der SBOM-Compliance?" – Nutzen Sie unseren CRA-Quick-Check, um in wenigen Minuten eine orientierende Einschätzung zu erhalten, wo Ihr Unternehmen bei der CRA-Compliance steht:

→ Jetzt zum CRA-Quick-Check

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Veröffentlicht am: 20.04.2026. Zuletzt geprüft am: 03.07.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

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.