Von Redaktion codAIx | 11. Mai 2026

Viele Hersteller können auf Knopfdruck eine Liste ihrer direkten Abhängigkeiten erzeugen. Ob diese Liste auch als Software-Stückliste (englisch software bill of materials, SBOM) für den Cyber Resilience Act (CRA) taugt, ist eine andere Frage. Ab dem 11. Dezember 2027 müssen Hersteller für ihre Produkte eine SBOM erstellen und vorhalten[1]. Öffentlich machen müssen sie die Liste nicht, der Marktüberwachungsbehörde aber auf Verlangen vorlegen. Dieser Artikel erläutert die gesetzlichen Anforderungen und ihre praktische Umsetzung. Die weitergehenden Vorgaben der BSI-Richtlinie werden gesondert eingeordnet. Auch die zusätzlichen Schwierigkeiten bei KI-Produkten werden behandelt.

Zwei Massstäbe unterscheiden: Ausgangspunkt sind der CRA und die jeweils einschlägigen verbindlichen Rechtsakte. Anhang I Teil II Nr. 1 CRA verlangt eine SBOM in einem gängigen maschinenlesbaren Format mit zumindest den obersten Abhängigkeiten. Die Kommission kann Format und Elemente nach Art. 13 Abs. 24 CRA näher festlegen. Die BSI TR-03183 Teil 2 enthält weitergehende technische Vorgaben; sie begründet für sich genommen keine zusätzlichen gesetzlichen Pflichten und keine Konformitätsvermutung nach Art. 27 CRA[1][2][21].

Rückblick: SBOM im Kontext der CRA-Serie

In Artikel 1 zu 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.

Hier geht es nun um die Umsetzung: Welche Angaben verlangt der CRA, welche Formate unterstützen die praktische Arbeit — und wann sind zusätzliche Anforderungen zu berücksichtigen?

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.

Zwei Eingrenzungen folgen unmittelbar aus dem Wortlaut. Erstens geht es nur um Komponenten, die in den Softwareelementen eines Produkts enthalten sind: Die Software-Stückliste erfasst damit ausschliesslich Softwarekomponenten — Hardwarekomponenten gehören nicht hinein (NK-CRA/Hofmann/Iffländer Art. 3 Rn. 259 [21]). Bei Produkten, die Hard- und Software verbinden, ist die Abgrenzung vor der Toolauswahl zu klären. Zweitens bestimmt der Zweck den Inhalt: Nach Erwägungsgrund 77 CRA dient die Stückliste der Schwachstellenanalyse — wer weiss, welche Komponenten integriert sind, kann leichter feststellen, ob das Produkt gerade wegen dieser Komponenten Schwachstellen aufweist. Adressiert sind dabei sowohl die Nutzer als auch Hersteller, die das Produkt als Komponente in ein eigenes Produkt integrieren wollen oder bereits integriert haben (Rn. 261 [21]).

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][21].
  • 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; systematisch ordnet der CRA-Kommentar von Wiebe die SBOM diesem Lieferantenmanagement zu[11]. Abs. 6 verpflichtet zur Meldung festgestellter Schwachstellen in eingebetteten Komponenten an den Komponentenhersteller; nach der Guidance der Kommission betrifft dies die tatsächlich integrierte Version und entfällt, wenn der Hersteller bestätigen kann, dass der Komponentenhersteller oder die wartende Stelle die Schwachstelle bereits kennt. Bei eigener Behebung sind auch der geänderte Code beziehungsweise die technischen Unterlagen mitzuteilen, möglichst in maschinenlesbarem Format[12][22]. Abs. 22 regelt die Übermittlung der für den Konformitätsnachweis erforderlichen Informationen und Unterlagen an die Marktüberwachungsbehörde auf begründetes Verlangen. Abs. 25 erlaubt den Marktüberwachungsbehörden zudem, für eine von der ADCO beschlossene unionsweite Abhängigkeitsbewertung die SBOMs bestimmter Produktkategorien anzufordern; an die ADCO gehen nur anonymisierte und aggregierte Angaben. Abs. 9 verlangt, dass jede bereitgestellte Sicherheitsaktualisierung nach ihrer Bereitstellung für mindestens zehn Jahre oder die verbleibende Dauer des Unterstützungszeitraums verfügbar bleibt, je nachdem, welcher Zeitraum länger ist[13][20]. Abs. 24 ermächtigt die Kommission, Format und Elemente der SBOM festzulegen (NK-CRA/Hofmann/Iffländer Art. 3 Rn. 258, 264 [21]); bis zum 11. Oktober 2026 hatte die Kommission keinen Durchführungsrechtsakt nach Art. 13 Abs. 24 CRA erlassen (eigene Recherche EUR-Lex, Stand 11.10.2026).
  • 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 zehn Jahre nach dem Inverkehrbringen des Produkts beziehungsweise für die Dauer des Unterstützungszeitraums den Marktüberwachungsbehörden zur Verfügung zu halten — je nachdem, welcher Zeitraum länger ist[15][20].

Die Verordnung ist seit dem 10. Dezember 2024 in Kraft[1]. Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach Art. 14 CRA; gemeldet wird über die einheitliche Meldeplattform der ENISA. Einzelheiten erläutert Artikel 8 zu den CRA-Meldepflichten. Die übrigen Compliance-Anforderungen gelten ab dem 11. Dezember 2027.

Sanktionsrisiko ab dem 11. Dezember 2027: Die Nichteinhaltung der in Anhang I festgelegten grundlegenden Cybersicherheitsanforderungen — dazu gehört auch die SBOM-Anforderung aus Anhang I Teil II Nr. 1 — kann nach Art. 64 Abs. 2 CRA mit bis zu 15 Mio. EUR oder, bei Unternehmen, bis zu 2,5 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres sanktioniert werden; massgeblich ist der höhere Höchstbetrag. Die konkrete Höhe der Geldbusse richtet sich nach den Umständen des Einzelfalls[1][16].

Hinweis zu Open-Source-Verwaltern: Juristische Personen, die — etwa als Stiftung — die Entwicklung quelloffener Software für kommerzielle Tätigkeiten systematisch und nachhaltig unterstützen, ohne selbst Hersteller zu sein, sind nach Art. 3 Nr. 14 und Art. 24 CRA Verwalter quelloffener Software. Sie trifft daher keine eigenständige SBOM-Pflicht. Ab dem 11. Dezember 2027 müssen sie eine Cybersicherheitsstrategie entwickeln und in den Grenzen des Art. 24 Abs. 3 CRA Meldepflichten erfüllen: Art. 14 Abs. 1 gilt für sie nur, soweit sie an der Entwicklung der Produkte beteiligt sind, Art. 14 Abs. 3 und 8 nur bei Vorfällen in den Netz- und Informationssystemen, die sie für die Entwicklung bereitstellen[17][19]. 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

Eine SBOM ist kein öffentliches Register. Sie dient in erster Linie als internes Lieferketten-Tracking-Instrument, nicht als Marketing-Dokument. Nach Erwägungsgrund 77 CRA sind Hersteller nicht verpflichtet, die SBOM zu veröffentlichen; eine Pflicht zur Weitergabe an Kunden sieht der CRA ebenfalls nicht vor — Anhang II Nr. 9 setzt eine freiwillige Bereitstellung gerade voraus[1][8].

Gegenüber der Marktüberwachungsbehörde gelten andere Regeln. 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[1][25]; hinzu kommt die Aufbewahrungspflicht nach Art. 13 Abs. 13 CRA[15]. Daneben kann die SBOM nach Art. 13 Abs. 25 CRA für eine unionsweite Abhängigkeitsbewertung angefordert werden. Auch NK-CRA/Hofmann/Iffländer Art. 3 Rn. 258 [21] trennt die freiwillige Bereitstellung an Nutzer von der Aufnahme in die technischen Unterlagen für die Marktüberwachung. Für die Umsetzung ergeben sich daraus drei Punkte:

  • Für jede unterstützte Produkt- oder Softwareversion muss eine zutreffende, versionierte und reproduzierbare SBOM bereitstellbar sein — idealerweise aus einem Repository, das den jeweiligen Release-Stand eindeutig abbildet.
  • Bei der verpflichtenden Vorlage geht die SBOM an die Marktüberwachungsbehörde; an die ADCO dürfen nach Art. 13 Abs. 25 nur anonymisierte und aggregierte Angaben weitergegeben werden. Eine freiwillige Bereitstellung an Kunden bleibt davon unberührt und ist gesondert zu entscheiden.
  • Eine reine „Schubladen-SBOM“ ohne eindeutige Versions- und Produktzuordnung reicht nicht: Wird sie angefordert, muss sie die Anhang-I-Anforderungen erfüllen und den Komponentenbestand der betreffenden Produkt- oder Softwareversion korrekt 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. Unterstützungszeitraum (Art. 13 Abs. 8 CRA) — grundsätzlich mindestens fünf Jahre, mit anzugebendem Enddatum. Hersteller müssen Schwachstellen während des Unterstützungszeitraums grundsätzlich für mindestens fünf Jahre wirksam nach Anhang I Teil II behandeln, insbesondere durch Sicherheitsaktualisierungen. Beträgt die voraussichtliche Nutzungsdauer weniger als fünf Jahre, entspricht der Unterstützungszeitraum dieser kürzeren Dauer. Der Massstab ist streng: Für die Pflicht genügt bereits die abstrakte Gefahr in Gestalt einer Schwachstelle, unabhängig von deren möglicher Schwere (NK-CRA/Mehnert Art. 13 Rn. 21 [21]). 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]. Hersteller müssen die festgelegte Frist begründen und dokumentieren[9].

Unterstützungszeitraum festlegen und Enddatum angeben. Für die SBOM-Planung ist das besonders wichtig: Art. 13 Abs. 8 CRA verlangt, einen Unterstützungszeitraum festzulegen, der die voraussichtliche Nutzungsdauer widerspiegelt. Zusätzlich ist nach Art. 13 Abs. 19 CRA dessen Enddatum zum Zeitpunkt des Kaufs klar, verständlich und leicht zugänglich anzugeben, mindestens mit Monat und Jahr. Der Kommentar von Schröder/Hartl betont, dass die Verordnung keinen abstrakten Fristbeginn festlegt und die Angabepflicht deshalb ein festes Enddatum erfordert (NK-CRA/Mehnert Art. 13 Rn. 25 [21]; anders noch NK-CRA/Mehnert Art. 3 Rn. 121: „festen Zeitraum oder ein Enddatum“). Das Enddatum des Unterstützungszeitraums wird für das Produkt beziehungsweise die Produktserie festgelegt und beim Kauf angegeben; die zugehörigen Versions-SBOMs müssen diesem Produktstand eindeutig zuordenbar bleiben.

Wie das Datum zustande kommt — und wo es dokumentiert wird. Art. 13 Abs. 8 UAbs. 2 CRA: Der Zeitraum ist so festzulegen, dass er die voraussichtliche Nutzungsdauer widerspiegelt. Rechnung zu tragen ist insbesondere den angemessenen Erwartungen der Nutzer, der Art des Produkts samt Zweckbestimmung und den einschlägigen Unionsvorschriften zur Lebensdauer. Berücksichtigen können Hersteller auch die Unterstützungszeiträume vergleichbarer Produkte anderer Hersteller, die Verfügbarkeit der Betriebsumgebung, die Unterstützungszeiträume integrierter Drittkomponenten mit Kernfunktion — also genau jener Komponenten, die in der SBOM stehen — sowie Leitlinien der Verwaltungszusammenarbeitsgruppe (ADCO) und der Kommission; übergreifend gilt der Verhältnismässigkeitsgrundsatz. Belastbare Referenzwerte fehlen noch, der Spielraum ist entsprechend gross; die ADCO veröffentlicht künftig nach Art. 52 Abs. 16 UAbs. 2 CRA Statistiken über die festgelegten Unterstützungszeiträume, und die Kommission kann nach Art. 13 Abs. 8 UAbs. 4 CRA Mindestzeiträume für Produktkategorien durch delegierte Rechtsakte festlegen, die dann nur für danach in Verkehr gebrachte Produkte gelten (Rn. 23 [21]). Die dabei berücksichtigten Informationen gehören nach Art. 13 Abs. 8 UAbs. 5 CRA und Anhang VII Nr. 4 CRA in dieselbe technische Dokumentation, in der auch die SBOM liegt — ausdrücklich zu dem Zweck, dass die Abwägung stattfindet und überprüfbar bleibt (Rn. 27 [21]). Und: Festgelegt wird der Unterstützungszeitraum für eine Produktserie, nicht für jedes Einzelexemplar; eine von vornherein lange geplante Vertriebszeit erhöht über die Nutzererwartung zugleich den Unterstützungszeitraum (Rn. 26 [21]).

2. Verfügbarkeit von Sicherheitsupdates (Art. 13 Abs. 9 CRA) — mindestens zehn Jahre nach Bereitstellung. Bereitgestellte Sicherheitsaktualisierungen müssen nach ihrer Bereitstellung für mindestens zehn Jahre oder die verbleibende Dauer des Unterstützungszeitraums verfügbar bleiben — je nachdem, welcher Zeitraum länger ist[13]. Die BSI TR-03183 Teil 1, Kap. 3.6, fasst diese Pflicht mit der Aufbewahrung der technischen Dokumentation zusammen und knüpft dabei an das Inverkehrbringen an; massgeblich ist jedoch der Verordnungstext, nach dem die Frist für jedes Update mit dessen Bereitstellung beginnt[20]. Praktisch empfiehlt es sich deshalb, jede ausgelieferte Update-Version mit der zugehörigen SBOM zu verknüpfen.

3. Aufbewahrung der technischen Dokumentation (Art. 13 Abs. 13 CRA) — mindestens zehn 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 zehn Jahre nach dem Inverkehrbringen des Produkts beziehungsweise für die Dauer des Unterstützungszeitraums den Marktüberwachungsbehörden zur Verfügung zu halten — je nachdem, welcher Zeitraum länger ist[15][20].

Operativ folgt daraus: Die SBOM muss für die jeweilige Produkt- beziehungsweise Softwareversion korrekt, versioniert und reproduzierbar sein. Ändert sich der Komponentenbestand, ist für die neue Fassung eine entsprechend aktualisierte SBOM zu führen. Neu bekannt gewordene Schwachstellen lösen Bewertung und Behandlung aus, ändern aber nicht den historischen Komponentenbestand. Die technischen Unterlagen einschliesslich der zugehörigen Versions-SBOMs müssen während der gesetzlichen Aufbewahrungsfrist verfügbar bleiben. Das bedeutet:

  • Eine eigene SBOM je Softwareversion, parallel zur Produktversionierung (jedes Release erzeugt eine neue SBOM).
  • Rückverfolgbarkeit zwischen ausgelieferten Produktinstanzen und der jeweils gültigen SBOM, damit bei einer neu gemeldeten Schwachstelle in einer Komponente alle betroffenen Releases identifiziert werden können.
  • Fortlaufender Abgleich des Komponenten- und Versionsinventars gegen Schwachstellendatenbanken und Herstelleradvisories — getrennt vom statischen SBOM-Artefakt der jeweiligen Version.

Eine zum Releasezeitpunkt korrekte SBOM wird durch eine später entdeckte Schwachstelle nicht rückwirkend falsch. Unzureichend wäre es jedoch, den dokumentierten Komponentenbestand während des Unterstützungszeitraums nicht mehr gegen aktuelle Schwachstellenmeldungen abzugleichen und festgestellte Schwachstellen nicht nach Anhang I Teil II zu behandeln.

Der Angriff „Shai-Hulud“ vom November 2025 zeigt, wie konkret dieses Lieferkettenrisiko ist. Über kompromittierte npm-Pakete verbreitete sich Schadcode entlang der Abhängigkeitsketten und erbeutete Zugangsdaten; mit solchen Daten wurde unter anderem eine weit verbreitete Browser-Erweiterung kompromittiert. Der 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 veranschaulicht jedoch, weshalb eine gepflegte SBOM auch über das gesetzliche Minimum hinaus operativ sinnvoll ist: Nur wer seine transitiven Abhängigkeiten kennt und dokumentiert, kann nach einem solchen Angriff feststellen, ob das eigene Produkt betroffen ist.

Praktische Umsetzung: Inhalt, Format und Pflege

Komponenten und Beziehungen nachvollziehbar erfassen

Der gesetzliche Ausgangspunkt ist die Dokumentation der Softwarekomponenten und ihrer Lieferkettenbeziehungen nach Art. 3 Nr. 39 CRA; Anhang I Teil II Nr. 1 verlangt zumindest die obersten Abhängigkeiten[1]. Für die praktische Umsetzung empfiehlt sich ein Inventar mit eindeutig erkennbaren Komponenten und Versionen, den Beziehungen zwischen ihnen sowie einer Zuordnung zur betreffenden Produktversion. Diese Umsetzungsempfehlung ist keine zusätzliche gesetzliche Feldliste.

Als ergänzende Arbeitshilfe beschreiben die „Minimum Elements“ der US-amerikanischen National Telecommunications and Information Administration (NTIA) sieben Angaben: Lieferant, Komponentenname, Version, eindeutige Identifikatoren, Abhängigkeitsbeziehung, Autor der SBOM-Daten und Zeitstempel[6]. Auch diese Liste ist vom CRA-Verordnungstext zu unterscheiden.

Eine aus Quellcode und Abhängigkeitsdateien erzeugte SBOM ist ein Ausgangspunkt. Vor der Verwendung muss geprüft werden, ob sie den betreffenden Produktstand zutreffend abbildet. Zugekaufte Software, vorkompilierte Komponenten oder erst beim Bauen hinzugefügte Bestandteile können zusätzliche Informationen erfordern. Dafür kommen beispielsweise Lieferanten-SBOMs, die Untersuchung ausgelieferter Softwaredateien oder dokumentierte manuelle Ergänzungen in Betracht. Fehlende Angaben sollten als solche erkennbar bleiben.

Formate: SPDX und CycloneDX

Was „formal“ und „maschinenlesbar“ bedeuten. Der Verordnungstext definiert beides nicht. Der Kommentar von Schröder/Hartl liest die „formale Aufzeichnung“ aus Art. 3 Nr. 39 CRA im Sinne des „gängigen maschinenlesbaren Formats“ aus Anhang I Teil II Nr. 1: Verlangt ist ein systematischer Aufbau, der die notwendigen Angaben auffindbar macht. Maschinenlesbar heisst, dass die Liste auch von Software durchsucht werden kann; ein eingescanntes Abbild genügt nicht. Die Anforderungen an die Automatisierung richten sich nach den praktischen Umständen der Schwachstellenanalyse (NK-CRA/Hofmann/Iffländer Art. 3 Rn. 260–263 [21]).

Der CRA legt im Verordnungstext weder ein bestimmtes SBOM-Format noch eine bestimmte Formatversion fest[1][5]. Zwei etablierte Standards sind:

  • SPDX (Software Package Data Exchange): ein Standard für den Austausch von Komponenten-, Lizenz- und Herkunftsinformationen[3].
  • CycloneDX: ein Standard für Stücklisten mit einem Schwerpunkt auf Software-Lieferketten und Sicherheitsanwendungen[4].

Praktische Empfehlung: Wählen Sie Format und Version nach den verwendeten Werkzeugen, den benötigten Angaben und den Anforderungen der Empfänger. Ein formal gültiges SPDX- oder CycloneDX-Dokument belegt für sich allein weder die Vollständigkeit der SBOM noch die CRA-Konformität des Produkts. Bestimmte Mindestversionen gelten dagegen, wenn zusätzlich die BSI TR-03183-2 erfüllt werden soll; sie sind im folgenden Abschnitt ausdrücklich diesem Massstab zugeordnet.

Checkliste für die praktische CRA-Umsetzung

Die folgende Liste verbindet die genannten CRA-Pflichten mit Umsetzungsschritten. Sie ist keine vollständige Produkt-Konformitätsprüfung und kein Prüfkatalog für BSI-TR-Konformität.

  • Inhalt: Softwarekomponenten und ihre Lieferkettenbeziehungen dokumentieren; zumindest die obersten Abhängigkeiten abbilden (Art. 3 Nr. 39 und Anhang I Teil II Nr. 1 CRA).
  • Format: Ein gängiges maschinenlesbares Format verwenden; als praktische Umsetzung eignen sich insbesondere SPDX oder CycloneDX.
  • Produktbezug: Die SBOM dem konkreten Produkt- und Softwarestand zuordnen und den erfassten Bestand auf Richtigkeit prüfen.
  • Pflege: Bei Änderungen des Komponentenbestands die zugehörige SBOM aktualisieren; das Inventar während des Unterstützungszeitraums für die Schwachstellenbehandlung nutzen.
  • Dokumentation: Die SBOM in die technische Dokumentation einordnen und nach Art. 13 Abs. 13 und 22 CRA aufbewahren beziehungsweise auf begründetes Verlangen vorlegen.
  • Freiwillige Weitergabe: Wird die SBOM Nutzern bereitgestellt, den Zugriffsweg in der Nutzeranleitung erläutern (Anhang II Nr. 9 CRA).

Empfehlung für den Betrieb: Komponentenbestand und aktuelle Schwachstellenbewertung getrennt pflegen. Eine neu bekannt gewordene Schwachstelle verändert den historischen Komponentenbestand nicht. Die Trennung erleichtert es, eine unveränderte Softwareversion fortlaufend zu bewerten. Für eine SBOM nach dem BSI-Massstab ist diese Trennung ausdrücklich vorgeschrieben[2].

Weitergehende Orientierung: BSI TR-03183-2

Die Technische Richtlinie BSI TR-03183 Teil 2, Version 2.1.0 vom 20. August 2025, beschreibt detaillierte Anforderungen an Aufbau und Inhalt einer SBOM[2]. Sie ist rechtlich nicht bindend und geht über den Mindestwortlaut des CRA hinaus (NK-CRA/Hofmann/Iffländer Art. 3 Rn. 264 [21]). Eine Ausrichtung kann sinnvoll sein, insbesondere wenn Kunden oder Auftraggeber diesen Massstab verlangen.

Wesentliche zusätzliche Vorgaben der TR sind:

  • Format und Version: CycloneDX ab 1.6 oder SPDX ab 3.0.1, jeweils in JSON oder XML und in einer offiziell freigegebenen Spezifikationsversion (Kap. 4). SPDX 2.x erfüllt diese TR-Formatvorgabe nicht; daraus folgt kein entsprechendes Verbot im CRA-Verordnungstext.
  • Inhalt und Tiefe: Die TR unterscheidet Pflicht-, Zusatz- und optionale Felder. Sie verlangt unter anderem Angaben zum Ersteller der SBOM und der Komponenten, zu Lizenzen und zur Vollständigkeit der Abhängigkeitsaufzählung. Für Dateikomponenten kommen insbesondere Dateiname, SHA-512-Prüfsumme und Dateieigenschaften hinzu; für logische Komponenten gelten abweichende Regeln. Die Abhängigkeiten sind auf jedem Pfad mindestens bis einschliesslich der ersten Komponente ausserhalb des Lieferumfangs aufzulösen (Kap. 3.2, 5 und 6).
  • Trennung und Pflege: Schwachstelleninformationen dürfen nicht Bestandteil einer TR-konformen SBOM sein. Für jede Softwareversion ist eine eigene SBOM vorgesehen; zusätzliche Komponenteninformationen oder Fehlerkorrekturen können eine Aktualisierung für dieselbe Version erfordern (Kap. 3.1).

Diese Übersicht ersetzt nicht die Prüfung der vollständigen Richtlinie. Die Verwendung eines zulässigen Formats allein genügt nicht für TR-Konformität. Ebenso besagt die Einordnung als Source-, Build- oder Analysed-SBOM lediglich, in welcher Phase beziehungsweise aus welchen Daten die Stückliste entstanden ist; die TR beschreibt diese Klassen in Kap. 8.4.

Welcher Massstab ist sinnvoll? Ausgangspunkt sind die Anforderungen des CRA. Ob zusätzlich die BSI-Vorgaben vollständig eingehalten werden sollen, hängt von den Anforderungen des konkreten Vorhabens und seiner Empfänger ab. Das muss gesondert festgelegt und geprüft werden. Dieser Artikel empfiehlt die vollständige TR-Konformität daher nicht pauschal als Voraussetzung jeder CRA-Umsetzung.

Europäische Konkretisierung: Format und Elemente kann die Kommission nach Art. 13 Abs. 24 CRA verbindlich festlegen. Harmonisierte Normen können nach Veröffentlichung ihrer Fundstellen im EU-Amtsblatt eine Konformitätsvermutung nach Art. 27 CRA begründen. Der bisherige Recherchestand dieses Artikels vom 11. Oktober 2026 weist weder einen solchen SBOM-Durchführungsrechtsakt noch veröffentlichte Fundstellen CRA-harmonisierter Normen aus. Die FAQ der Kommissionsdienststellen und der Entwurf zur Änderung des Normungsauftrags beschreiben den damaligen Zeitplan der Normung[19][23].

Genügt eine Dependency-Liste als SBOM? Ein umstrittener Massstab

Eine der häufigsten Praxisfragen ist zugleich besonders schlecht geklärt: Reicht ein vorhandenes Build-Artefakt bereits als Software-Stückliste? Die Antwort hängt vollständig vom angelegten Massstab ab.

Position des Kommentars: ja, im Grundsatz. Hofmann/Iffländer nennen die Abhängigkeitslisten gängiger Build-Werkzeuge — ausdrücklich die requirements.txt des Python-Werkzeugs pip — als typische, in der Praxis bereits eingesetzte Variante einer Software-Stückliste. Sie enthielten die Abhängigkeiten bereits mit Paketname und Version und liessen sich mit automatischen Werkzeugen verknüpfen, die auf Schwachstellen prüfen und Updates vorschlagen, sodass sowohl die Anforderungen des CRA als auch die Empfehlungen des BSI berücksichtigt werden könnten (NK-CRA/Hofmann/Iffländer Art. 3 Rn. 265 [21]). Am Verordnungstext gemessen ist das nachvollziehbar: Anhang I Teil II Nr. 1 CRA verlangt nur ein gängiges maschinenlesbares Format, aus dem zumindest die obersten Abhängigkeiten hervorgehen.

Am BSI-Massstab gemessen: nein. Eine requirements.txt, eine package-lock.json oder eine poetry.lock erfüllt die BSI TR-03183 Teil 2 v2.1.0 [2] nicht. Es fehlen dort Pflichtfelder wie der Ersteller als E-Mail-Adresse, der tatsächliche Dateiname, die SHA-512-Prüfsumme der auslieferbaren Komponente, die Executable-, Archive- und Structured-Property, die ausdrückliche Kennzeichnung, ob die Abhängigkeitsaufzählung vollständig ist, und die Distributionslizenz als SPDX-Bezeichner. Hinzu kommt die Formatvorgabe: Zulässig sind CycloneDX ab Version 1.6 und SPDX ab Version 3.0.1, jeweils in JSON oder XML.

Praktische Folgerung: Eine vorhandene Abhängigkeitsliste sollte darauf geprüft werden, ob sie für das konkrete Produkt die CRA-Anforderungen abbildet und sich für die laufende Schwachstellenbehandlung nutzen lässt. Eine Überführung in SPDX oder CycloneDX kann den Austausch und die automatisierte Auswertung erleichtern. Ob darüber hinaus die vollständigen BSI-Vorgaben erfüllt werden sollen, ist eine gesonderte Entscheidung.

Zwei weitere Abgrenzungen sind wichtig:

  • Ein Bild oder Scan ist nicht maschinenlesbar. Ob eine strukturierte, manuell gepflegte Tabellendatei bereits den offenen CRA-Mindestwortlaut erfüllt, ist nicht abschliessend geklärt; für die Konformität mit BSI TR-03183-2 reicht sie nicht, weil die TR bestimmte Formate und Felder verlangt. Die technisch belastbarere Linie ist deshalb CycloneDX oder SPDX nach dem jeweils einschlägigen Standard.
  • Komponenten eindeutig zuordnen: Namen, Versionen und verfügbare Herkunftsangaben erleichtern den Abgleich mit Schwachstelleninformationen. NTIA und BSI beschreiben dafür weitergehende Datenfelder[2][6]. Welche dieser Angaben für eine vollständige TR-Konformität erforderlich sind, ist gesondert nach der Richtlinie zu prüfen.

Ergänzende KI-/ML-Dokumentation — nicht automatisch Teil der CRA-SBOM

KI-Komponenten machen die Dokumentation komplexer (siehe Artikel 5 und Artikel 6). An der Reichweite der CRA-SBOM ändert das zunächst nichts: Sie bleibt auf die Softwareelemente und deren Komponentenbeziehungen gerichtet. Trainingsdaten, Datenquellen und Test-Datasets gehören wegen ihres KI-Bezugs nicht automatisch hinein; zu dokumentieren sein können sie gleichwohl aufgrund der KI-VO oder im Rahmen einer ergänzenden ML-BOM.

KI-/ML-Artefakte, die ergänzend dokumentiert werden sollten

  1. Trainings-Datasets

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

  1. Pre-trained Models

- Model Card (Hugging Face, 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. Abhängigkeiten bei Validierung und Tests

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

Empfohlene Ergänzung: ML-BOM nach CycloneDX oder SPDX

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 Cybersicherheits-Arbeitsgruppe der G7 im Mai 2026 die nicht verbindliche Empfehlung „Software Bill of Materials (SBOM) for Artificial Intelligence – Minimum Elements“ veröffentlicht, die unter anderem das BSI und die US-amerikanische CISA bereitstellen[24]. Im CRA-Text ist ein ML-BOM-Standard nicht ausdrücklich verankert. Solche Angaben können jedoch als ergänzende Dokumentation sinnvoll sein:

  • 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 CRA solche Angaben nicht ausdrücklich verlangt.

Warum SBOM-Compliance in der Praxis scheitert

„Gängiges maschinenlesbares Format“, „oberste Abhängigkeiten“: Der Wortlaut wirkt zunächst überschaubar. In Gesprächen mit Herstellern zeigt sich ein deutlich unordentlicheres Bild. Manche SBOM wird einmal erzeugt und danach nie wieder aktualisiert. Eine Liste der direkten Abhängigkeiten wird ungeprüft als vollständiges Inventar behandelt, obwohl der Lieferumfang weitere Komponenten enthält. Versionen werden als Bereiche statt als exakt festgelegte Versionen geführt; eine reproduzierbare SBOM ist dann nicht möglich. Interne Microservices fehlen ganz. Das gegenteilige Problem gibt es ebenfalls: Schwachstellenlisten werden in die SBOM geschrieben, sodass jede CVE-Aktualisierung eine neue Stückliste durch die Lieferkette schiebt, obwohl sich an den Komponenten nichts geändert hat.

Die Ursache liegt selten im Tool. SBOM-Compliance ist eine fortlaufende Aufgabe: bei jedem Release, jedem Dependency-Update und jeder neu gemeldeten Schwachstelle, bis zum angegebenen Enddatum des Unterstützungszeitraums — mindestens fünf Jahre, bei langlebigen Produkten länger. Viele interne Initiativen verlieren genau hier an Kraft. Die erste SBOM wird noch engagiert erstellt; Monate später ist sie veraltet, stimmt nicht mehr mit dem Code überein, und beim ersten Audit fehlen zentrale Angaben nach Anhang I Teil II Nr. 1 und Anhang VII CRA.

Das Wichtigste für Hersteller

  • Ab dem 11. Dezember 2027 verlangt Anhang I Teil II Nr. 1 CRA eine SBOM in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen. Veröffentlichen müssen Hersteller sie nicht; sie gehört aber in die technische Dokumentation und ist der Marktüberwachungsbehörde auf begründetes Verlangen vorzulegen (Art. 13 Abs. 13 und 22 CRA).
  • Die BSI TR-03183 Teil 2 v2.1.0 ist eine weitergehende, rechtlich nicht bindende Orientierung. Ihre vollständige Einhaltung ist gesondert zu vereinbaren beziehungsweise als Projektziel festzulegen und anhand der konkreten SBOM zu prüfen.
  • SBOM und Softwareversion eindeutig zuordnen. Als praktische Empfehlung sollten Komponentenbestand und aktuelle Schwachstellenbewertung getrennt gepflegt werden; für TR-konforme SBOMs ist diese Trennung vorgeschrieben.
  • Die SBOM ist bis zum Enddatum des Unterstützungszeitraums zu pflegen und mit der technischen Dokumentation mindestens zehn Jahre aufzubewahren; die Sicherheitsupdates selbst bleiben nach Art. 13 Abs. 9 CRA mindestens zehn Jahre ab ihrer Bereitstellung verfügbar.
  • Eine reine Abhängigkeitsliste wie die requirements.txt genügt nach dem NK-CRA dem Verordnungswortlaut im Grundsatz, dem TR-Massstab aber nicht; KI-Komponenten lassen sich ergänzend in einer ML-BOM dokumentieren.

So unterstützt crAIready

Hinweis der Herausgeberin: crAIready ist die CRA-Compliance-Plattform der codAIx GmbH.

  • SBOM & Lieferkette: erstellt die Software-Stückliste auf Wunsch aus Ihrem Quellcode und den verfügbaren Abhängigkeitsdateien (Git-Repository, Quellcode-Archiv oder CI-Pipeline) oder übernimmt vorhandene SBOMs per Upload. Bestandteile ohne eigenen Quellcode, etwa zugekaufte Firmware, können über Lieferanten-SBOMs oder manuell erfasst werden. Der erfasste Bestand ist auf Vollständigkeit und die Zuordnung zum ausgelieferten Produktstand zu prüfen. Für eingebundene Drittkomponenten unterstützt die Plattform die Sorgfaltspflicht nach Art. 13 Abs. 5 CRA.
  • Schwachstellen & CVD: gleicht die SBOM-Komponenten regelmässig mit OSV, NVD, CISA KEV und EUVD ab, ordnet Hinweise den betroffenen Komponenten zu und bereitet sie für die Triage auf. Ob eine Meldepflicht nach Art. 14 besteht, wird gesondert geprüft.
  • Dokumentation & Konformität: erstellt Entwürfe der technischen Dokumentation nach Anhang VII und der EU-Konformitätserklärung zur fachlichen Prüfung und Freigabe.

Wenn Sie zunächst Ihren Ausgangspunkt bestimmen möchten, können Sie den öffentlichen CRA-Quick-Check unabhängig von der Plattform nutzen. Er unterstützt mit wenigen Fragen eine kostenlose und unverbindliche Ersteinschätzung dazu, ob und wie der CRA Ihr Produkt betreffen könnte.

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 in der Fassung v2.1.0 vom 20.08.2025 [2] und den Industriestandards SPDX[3] und CycloneDX[4]. Ergänzend wurden die BSI-Richtlinie TR-03183 Teil 1 [20] und die von den Kommissionsdienststellen erstellten FAQ zum CRA in der Fassung 1.4 vom 04.09.2026 [19] herangezogen; letztere sind nicht verbindlich und geben keine offizielle Position der Kommission wieder. Ebenfalls herangezogen wurde die nicht bindende Guidance der Kommission C(2026) 5252 [22]. Als juristische Kommentare zur Auslegung wurden der CRA-Kommentar von Wiebe (Hrsg.), Das neue Recht der Cyberresilienz, Nomos, Stand Juni 2025 [7][8][9][11][12][13][14][16][17][18][25] sowie der Kommentar von Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos 2026 [21] herangezogen. Aus dem Kommentar Wiebe (Hrsg.) stammen insbesondere die Legaldefinition nach Art. 3 Nr. 39 CRA (Wiebe, § 6 Rn. 19), die Klarstellung, dass keine Veröffentlichungspflicht besteht (Jossen, § 5 Rn. 128 / Fn. 104), die Vorlagepflicht gegenüber der Marktüberwachung nach Art. 13 Abs. 22 CRA (Wiebe, § 6 Rn. 41), der Mindest-Unterstützungszeitraum und seine Dokumentation (Wiebe, § 6 Rn. 25–28; Erwägungsgrund 60 CRA), die 10-Jahres-Verfügbarkeit von Sicherheitsupdates nach Art. 13 Abs. 9 CRA (§ 6 Rn. 35), die Meldepflicht gegenüber Komponentenherstellern nach Art. 13 Abs. 6 CRA (§ 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 (§ 4 Rn. 38, § 6 Rn. 4) sowie die Anleitungs-Pflicht aus Anhang II Nr. 9 CRA bei freiwilliger SBOM-Bereitstellung (Jossen § 5 Rn. 147). Aus Schröder/Hartl stammen die Kommentierung zu Art. 3 Nr. 39 CRA durch Hofmann/Iffländer (Rn. 258–265): Verortung der Software-Stückliste zwischen Anhang II und technischer Dokumentation, Beschränkung auf Softwarekomponenten, Auslegung von „formaler Aufzeichnung“ und „maschinenlesbarem Format“, fehlende Bindungswirkung der BSI-Richtlinie und die Einordnung von Abhängigkeitslisten der Build-Werkzeuge; aus der Kommentierung von Mehnert zu Art. 13 CRA (Rn. 21, 23, 25–27) stammen die Bedeutung eines konkret anzugebenden Enddatums zusätzlich zum Unterstützungszeitraum, die Abwägungsfaktoren samt Verhältnismässigkeitsgrundsatz, der Serienbezug, die Pflicht zur Aufnahme der Abwägung in die technische Dokumentation und der Massstab der abstrakten Gefahr. Die Angaben zu Art. 13 Abs. 8 UAbs. 2 bis 5, Art. 13 Abs. 19, Art. 52 Abs. 16, Art. 64 Abs. 2 und 5, Art. 71 Abs. 2 und Anhang VII Nr. 4 CRA wurden gegen die deutsche Verordnungsfassung geprüft. 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 zur Quellenlage: 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 Teil 2, den NTIA Minimum Elements[6] und den Best Practices der SPDX/CycloneDX-Communities — sie gehen über den Mindeststandard des CRA hinaus. Bei der Frage, was als Software-Stückliste genügt, legen juristischer Kommentar und BSI-Richtlinie unterschiedlich strenge Massstäbe an: Hofmann/Iffländer halten Abhängigkeitslisten gängiger Build-Werkzeuge im Grundsatz für ausreichend (Rn. 265 [21]), während die TR-03183 Teil 2 Pflichtfelder und Formatvorgaben verlangt, die solche Artefakte nicht erfüllen. Dieser Artikel stellt beide Massstäbe getrennt dar. Die praktischen Umsetzungsempfehlungen begründen keine zusätzlichen gesetzlichen Pflichten; eine vollständige Ausrichtung an der BSI-Richtlinie wird nicht pauschal vorausgesetzt. Weitere verbindliche Vorgaben können insbesondere durch einen Rechtsakt der Kommission nach Art. 13 Abs. 24 CRA entstehen; harmonisierte Normen können unter den Voraussetzungen des Art. 27 CRA eine Konformitätsvermutung begründen. 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.

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. 14 und 39, Art. 13 Abs. 5, 6, 8, 9, 13, 19, 22, 24 und 25, Art. 14, Art. 27, Art. 52 Abs. 16, Art. 64 Abs. 2 und 5, Art. 24, Art. 71 Abs. 2, Anhang I Teil II Nr. 1, Anhang II Nr. 9, Anhang VII (insbesondere Nr. 2 lit. b, Nr. 4 und Nr. 8) sowie 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)“, Version 2.1.0 vom 20. August 2025; Erstveröffentlichung (Version 1.0) am 12. Juli 2023. v2.1.0 ergänzt gegenüber v2.0.0 insbesondere ein Mapping der einzelnen Datenfelder auf SPDX und CycloneDX, eine restrukturierte und erweiterte Lizenz- und Datenfeldsystematik, die Anhebung der Mindestversionen auf CycloneDX 1.6 und SPDX 3.0.1 sowie die Einführung logischer und identifizierter Komponenten samt präzisierter BOM-Referenzen. Ü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, 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); die BSI TR lässt dabei nur die Serialisierungen JSON und XML und nur offiziell freigegebene Spezifikationsversionen zu (Kap. 4).

[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, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 6 Rn. 19 (Praxishinweis, S. 118; zur Legaldefinition der SBOM nach Art. 3 Nr. 39 CRA).

[8] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Jossen, § 5 Rn. 128 und Fn. 104 (keine Pflicht zur Veröffentlichung der SBOM; Fn. 104 zitiert Erwägungsgrund 78, gemeint ist Erwägungsgrund 77 CRA). 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, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 6 Rn. 25–28 (Unterstützungszeitraum: Begriff, Kriterien, Mindestdauer und Dokumentation der Festlegung in der technischen Dokumentation; Rn. 27 zu Erwägungsgrund 60 CRA, der neben Hardwarekomponenten und Netzwerkgeräten auch bestimmte Softwareprodukte und industrielle Steuerungssysteme nennt).

[10] The Hacker News, „Weekly Recap: IoT Exploits, Wallet Breaches, Rogue Extensions, AI Abuse & More“, 5. 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-Bericht, herangezogen als illustratives Vorfallbeispiel, nicht als juristische Primärquelle.

[11] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 6 Rn. 19, Praxishinweis (zur systematischen Verortung der SBOM im Lieferantenmanagement nach Art. 13 Abs. 5 CRA).

[12] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 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, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 6 Rn. 35 (zur 10-Jahres-Verfügbarkeit von Sicherheitsupdates nach Art. 13 Abs. 9 CRA).

[14] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 5 Rn. 87 und § 6 Rn. 12, 14 (zur Aufnahme der Cybersicherheitsrisikobewertung nach Art. 13 Abs. 3 CRA, des Cybersicherheitskonzepts 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] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Jossen, § 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, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 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] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Jossen, § 5 Rn. 147 (zur Pflicht aus Anhang II Nr. 9 CRA, bei freiwilliger Bereitstellung der SBOM den Zugriffsweg in der Nutzeranleitung zu beschreiben).

[19] Europäische Kommission (Dienststellen): „FAQs on the Cyber Resilience Act“, Version 1.4 vom 04.09.2026, insbesondere Nr. 5.5 (Geltung des Art. 24 Abs. 3 CRA für Verwalter quelloffener Software ab dem 11.12.2027) und Nr. 6.10 (Zeitplan der harmonisierten Normen unter dem Normungsauftrag M/606). Das Dokument ist von den Kommissionsdienststellen erstellt und stellt nach eigener Angabe keine offizielle Position der Europäischen Kommission dar; es ist nicht verbindlich, begründet keine zusätzlichen Rechte oder Pflichten und wird als „lebendes Dokument“ fortlaufend aktualisiert.

[20] Bundesamt für Sicherheit in der Informationstechnik (BSI): Technische Richtlinie TR-03183 Teil 1 – „Cyber Resilience Requirements for Manufacturers and Products – Part 1: General requirements“, Version 1.0.0, ausdrücklich als „Living Document“ gekennzeichnet, insbesondere Kap. 3.6 (Sicherheitsupdates und technische Dokumentation mindestens zehn Jahre nach Inverkehrbringen oder für die volle Dauer des Unterstützungszeitraums verfügbar, je nachdem, welcher Zeitraum länger ist). Hinweis zur Datierung: Das Deckblatt des PDF nennt den 31.07.2026, der Changelog desselben Dokuments dagegen den 31.07.2025. Die Angaben im BSI-Original widersprechen einander; eine eindeutige Zuordnung ist nicht möglich, weshalb hier auf eine Datumsangabe verzichtet wird.

[21] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Hofmann/Iffländer, Art. 3 Rn. 258–265; Mehnert, Art. 3 Rn. 121, Art. 13 Rn. 21, 23, 25–27. Artikelweiser Kommentar zur Verordnung (EU) 2024/2847; Art. 3 Nr. 39 kommentiert von Hofmann/Iffländer, Art. 3 Nr. 20 (Rn. 121) und Art. 13 (Rn. 1–65) von Mehnert. Herangezogen: Rn. 258 (Software-Stückliste als Teil der Anhang-II-Informationen nur bei Bereitstellung an Nutzer, keine Veröffentlichungspflicht nach Erwgr. 77, aber zwingender Bestandteil der technischen Dokumentation), Rn. 259 (nur Software-, keine Hardwarekomponenten), Rn. 260–263 (Auslegung von „formaler Aufzeichnung“ und „gängigem maschinenlesbarem Format“; Zweck der Schwachstellenanalyse nach Erwgr. 77; Zielgruppe Nutzer und integrierende Hersteller), Rn. 264 (BSI TR-03183 als Hinweis, aber nicht bindend; Festlegung von Format und Elementen obliegt der Kommission nach Art. 13 Abs. 24 CRA) und Rn. 265 (Abhängigkeitslisten von Build-Werkzeugen, genannt die requirements.txt von pip, als typische Variante einer Software-Stückliste). Aus der Kommentierung von Mehnert zu Art. 13 CRA herangezogen: Rn. 21 (für die Pflicht aus Art. 13 Abs. 8 CRA genügt die abstrakte Gefahr in Gestalt einer Schwachstelle, unabhängig von deren möglicher Schwere), Rn. 23 (Abwägungsfaktoren, Verhältnismässigkeitsgrundsatz, fehlende Referenzwerte, ADCO-Statistik, delegierte Rechtsakte), Rn. 25 (Bestimmung durch ein Enddatum statt durch eine Dauer; Vereinbarkeit allein dieser Lösung mit der Angabepflicht aus Art. 13 Abs. 19 CRA), Rn. 26 (Festlegung für die Produktserie; längere geplante Vertriebszeit führt über die Nutzererwartung zu einem längeren Unterstützungszeitraum) und Rn. 27 (Aufnahme der massgeblichen Informationen in die technische Dokumentation nach Art. 31 CRA und Anhang VII); aus der Kommentierung von Mehnert zu Art. 3 Nr. 20 CRA Rn. 121 (Hersteller kann einen festen Zeitraum oder ein Enddatum bestimmen; abweichend von Art. 13 Rn. 25). Hinweis: Der Kommentar bezieht sich auf die TR-03183 Teil 2 in der Fassung v2.0.0; dieser Artikel legt die aktuelle Fassung v2.1.0 vom 20.08.2025 zugrunde [2].

[22] Europäische Kommission, Mitteilung C(2026) 5252 final, Guidance on the application of the Cyber Resilience Act, Anhang, insbesondere Rn. 223 zur Mitteilung von Schwachstellen in integrierten Komponenten. Die Guidance ist nicht bindend.

[23] Europäische Kommission, Entwurf eines Durchführungsbeschlusses zur Änderung des Durchführungsbeschlusses C(2025) 618 (Normungsauftrag M/606 zum CRA), im EU-Notifizierungssystem am 07.07.2026 veröffentlicht; Verschiebung der Fristen für die horizontalen Normen auf den 31.10.2026 und für die vertikalen Normen auf den 31.12.2026; Entwurf, bis zum 11.10.2026 nicht angenommen, EU-Notifizierungssystem.

[24] G7 Cybersecurity Working Group, „Software Bill of Materials (SBOM) for Artificial Intelligence – Minimum Elements“, 12.05.2026, bereitgestellt vom BSI: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.html (abgerufen am 13.10.2026). Nicht verbindliche Empfehlung.

[25] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Wiebe, § 6 Rn. 41 (Übermittlung der für den Konformitätsnachweis erforderlichen Informationen und Unterlagen an die Marktüberwachungsbehörde auf begründetes Verlangen, Art. 13 Abs. 22 CRA).

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. Keine Rechtsberatung im Sinne des RDG. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 11.05.2026, zuletzt geändert am 21.10.2026.

Im nächsten Artikel dieser Serie: CRA-Meldepflichten seit 2026: Fristen, ENISA-Plattform, Praxis — welche Fristen seit dem 11. September 2026 für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten, wie die einheitliche Meldeplattform funktioniert und wie Sie Ihre Prozesse für die koordinierte Offenlegung von Schwachstellen aufstellen.