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 den gesetzlichen Mindestumfang, die strengeren Vorgaben der BSI-Richtlinie sowie anerkannte Standards und Formate. Auch die zusätzlichen Schwierigkeiten bei KI-Produkten werden behandelt.

Quellenhierarchie für die SBOM-Pflicht: Verbindlich ist allein der Verordnungstext (EU) 2024/2847. Er verlangt für die SBOM nur „ein gängiges maschinenlesbares Format“, aus dem „zumindest die obersten Abhängigkeiten“ hervorgehen (Anhang I Teil II Nr. 1). Format und Elemente kann die Kommission nach Art. 13 Abs. 24 CRA verbindlich festlegen. Harmonisierte Normen mit Konformitätsvermutung nach Art. 27 CRA waren bis zum 11. Oktober 2026 nicht im Amtsblatt veröffentlicht. Bis zu einer solchen Veröffentlichung ist die BSI TR-03183 Teil 2 v2.1.0 rechtlich nicht bindend, aber die derzeit detaillierteste deutsche behördliche Orientierung; eine gefestigte Prüf- oder Vollzugspraxis besteht noch nicht. Sie geht in Detailpunkten über den CRA hinaus (so auch NK-CRA/Hofmann/Iffländer Art. 3 Rn. 264[21]). Bei Widersprüchen gilt die EU-Vorgabe.

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 braucht eine CRA-konforme SBOM, was gehört ausdrücklich nicht hinein — und an welchen Stellen entstehen in der Praxis die meisten Fehler?

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.

Empfohlener Mindestumfang gemäss BSI TR-03183 Teil 2 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 (Lieferant, Komponentenname, Version, eindeutige Identifikatoren, Abhängigkeitsbeziehung, Autor der SBOM-Daten, Zeitstempel). Die BSI TR-03183 Teil 2 [2] und die gelebte Praxis (CycloneDX, SPDX) gehen darüber hinaus und ergänzen insbesondere Lizenzangaben.

Die TR unterscheidet dabei drei Stufen von Datenfeldern — Pflichtfelder, Zusatzfelder (verpflichtend, sofern vorhanden) und optionale Felder. Diese Gliederung ist deutlich präziser als die NTIA-Liste und deshalb ein geeigneter Arbeitsraster für deutsche Hersteller. Die TR ist nicht bindend (siehe Kasten oben).

Pflichtfelder für die SBOM selbst (TR Kap. 5.2.1)

  • Ersteller der SBOM — als E-Mail-Adresse; nur wenn keine E-Mail-Adresse existiert, ersatzweise eine URL (etwa die Unternehmens- oder Projektseite)
  • Zeitstempel der Datenerhebung nach den Vorgaben des gewählten Formats; empfohlen wird ausschliesslich UTC („Zulu“-Zeit)

Pflichtfelder je Komponente (TR Kap. 5.2.2)

  • Ersteller der Komponente — E-Mail-Adresse, ersatzweise URL
  • Komponentenname, wie vom Ersteller vergeben; ist kein Name vergeben, der tatsächliche Dateiname
  • Komponentenversion — bestehende Identifikatoren dürfen dafür nicht verändert werden; empfohlen sind Semantic Versioning oder Calendar Versioning; ist gar keine Version vergeben, ist zwingend das Dateiänderungsdatum nach RFC 3339 zu verwenden
  • Tatsächlicher Dateiname der Komponente (der Dateiname selbst, nicht der Dateisystempfad)
  • Abhängigkeiten zu anderen Komponenten — und zwar mit der ausdrücklichen Kennzeichnung, ob diese Aufzählung vollständig ist
  • Distributionslizenz(en) — die Lizenzen, unter denen die Komponente von einem Lizenznehmer genutzt werden kann
  • Kryptografisch sichere Prüfsumme der auslieferbaren Komponente als SHA-512
  • Executable-Property — „executable“ oder „non-executable“
  • Archive-Property — „archive“ oder „no archive“
  • Structured-Property — „structured“ oder „unstructured“; enthält eine Komponente sowohl strukturierte als auch unstrukturierte Teile, ist „structured“ zu verwenden

Zusatzfelder — verpflichtend, sofern vorhanden und im gewählten Format abbildbar (TR Kap. 5.2.3 und 5.2.4)

  • SBOM-URI (für die SBOM selbst)
  • Quellcode-URI der Komponente
  • URI der auslieferbaren Form der Komponente
  • Weitere eindeutige Identifikatoren wie CPE (Common Platform Enumeration) oder purl (Package URL)
  • Originallizenz(en) — die vom Ersteller der Komponente vergebenen Lizenzen

Optionale Felder je Komponente (TR Kap. 5.2.5)

  • Effektive Lizenz — die Lizenz, unter der der Ersteller der aktuellen SBOM die Komponente nutzt
  • Prüfsumme des Quellcodes (ein verbindliches Verfahren dafür ist noch nicht festgelegt)
  • URL der security.txt des Komponentenerstellers

Zwei Feinheiten sind in der Praxis leicht zu übersehen. Erstens ist das Pflichtfeld nicht der blosse Name eines Herstellers, sondern der Ersteller der Komponente in Form einer E-Mail-Adresse. Die TR unterscheidet in Kap. 3.2.9 ausdrücklich zwischen Anbieter beziehungsweise Lieferant („vendor“/„supplier“) und Ersteller beziehungsweise Autor („creator“) und weist darauf hin, dass der deutsche Begriff „Hersteller“ beide Rollen vermischt. Zweitens gibt es kein TR-Feld „Versionsnummer der SBOM“: Die TR verlangt stattdessen für jede Softwareversion eine eigene SBOM und kennt als Zusatzfeld die SBOM-URI.

Was ausdrücklich nicht in die SBOM gehört: Schwachstelleninformationen

Hier liegt eines der häufigsten Missverständnisse in der Praxis — und die TR ist an dieser Stelle unmissverständlich: Eine SBOM MUSS frei von Schwachstelleninformationen sein (Kap. 3.1). Ein Dokument, das SBOM-Daten und Schwachstelleninformationen zusammen enthält, ist nicht konform zur TR-03183 Teil 2 — auch dann nicht, wenn CycloneDX oder SPDX entsprechende Felder anbieten.

Die Begründung ist rein technisch und überzeugend (Kap. 8.1.14): SBOM-Daten sind statisch und beziehen sich auf eine konkrete, unveränderte Softwareversion. Schwachstelleninformationen sind dynamisch — sie ändern sich laufend. Werden beide in einem Dokument vermischt, wird die statische Komponenteninformation bei jeder Aktualisierung der Schwachstellenlage unnötig erneut durch die gesamte Lieferkette geschoben. Das empfohlene Transportformat für Schwachstelleninformationen ist stattdessen CSAF (Common Security Advisory Framework), mit VEX (Vulnerability Exploitability Exchange) als Profil.

Praktisch heisst das: Die SBOM ist das Bestandsverzeichnis. Der Abgleich dieses Bestands gegen CVE-Einträge, Schwachstellendatenbanken und Herstelleradvisories findet ausserhalb der SBOM statt, und das Ergebnis dieser Analyse — die Aussage, ob und wie Ihr Produkt betroffen ist — wird als Security Advisory beziehungsweise VEX an die Nutzer ausgeliefert. Wer diese Trennung sauber implementiert, hat zwei gepflegte Artefakte statt eines überladenen; wer sie vermischt, verliert die TR-Konformität.

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 schnell auffindbar macht. Maschinenlesbar heisst, dass die Liste auch von Software durchsucht werden kann — ein eingescanntes Abbild genügt nicht, mindestens eine übliche Textcodierung ist erforderlich, und für automatisierte Vorgänge eine festgelegte Syntax. Wie hoch die Anforderungen im Einzelfall ausfallen, richtet sich nach den praktischen Umständen der Schwachstellenanalyse: Wäre diese sinnvoll nur hochautomatisiert durchführbar, fielen die Anforderungen hoch aus; ist sie überwiegend ein manueller Prozess, sind sie niedriger anzusetzen (NK-CRA/Hofmann/Iffländer Art. 3 Rn. 260–263 [21]).

Der CRA akzeptiert damit 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
  • Für TR-Konformität gilt die Mindestversion SPDX 3.0.1; SPDX 2.x scheidet aus. SPDX 3.0.x ist RDF-basiert: offiziell mit JSON-Schema unterstützt ist JSON-LD, RDF/XML ist nach der Spezifikation möglich; Tag-Value gibt es für SPDX 3 nicht
  • Fokus auf Lizenzcompliance und Komponenten-Genealogie

CycloneDX[4]

  • Optimiert für Sicherheit und Supply Chain Risk Management
  • Nativer Vulnerability-Support im Format — der für TR-konforme SBOMs allerdings gerade nicht genutzt werden darf
  • Schlanker als SPDX, oft besser für CI/CD-Integration
  • Formate: JSON, XML
  • Wachsend in der Praxis bei DevOps-Teams

Wichtig für die TR-Konformität: Nach TR-03183 Teil 2, Kap. 4 sind JSON oder XML und CycloneDX ab Version 1.6 beziehungsweise SPDX ab Version 3.0.1 zulässig; verwendet werden dürfen nur offiziell freigegebene Spezifikationsversionen. Tag-Value und SPDX 2.x scheiden aus. Die Mappingtabelle (Kap. 8.2) dokumentiert SPDX 3.0.1 in JSON; eine Formatbeschränkung folgt daraus nicht.

Empfehlung: Wählen Sie das Format am Anwendungsfall aus. SPDX 3.0.1 oder höher (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]) eignet sich, wenn die Lizenz-Compliance im Vordergrund steht; CycloneDX 1.6 oder höher (standardisiert als ECMA-424, 1. Auflage Juni 2024 [4]) eignet sich, wenn Security-Operations und CI/CD-Integration im Vordergrund stehen. Im Zweifel sollten Sie beide Formate parallel ausgeben. Für SPDX 3.0.1 empfiehlt sich die in der TR-Mappingtabelle dokumentierte JSON-Abbildung; die TR selbst lässt JSON und XML zu. Beide Standards sind gängige maschinenlesbare SBOM-Formate im Sinne von Anhang I Teil II Nr. 1 CRA[1].

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 am 12. Juli 2023 veröffentlicht und seitdem kontinuierlich weiterentwickelt; aktuelle Fassung ist Version 2.1.0 vom 20. August 2025[2]. Sie ist rechtlich nicht bindend, für deutsche Softwarehersteller aber die derzeit detaillierteste behördliche Orientierung; eine gefestigte Prüf- oder Vollzugspraxis besteht noch nicht[21].

Harmonisierte EU-Normen sollen technische Detailfragen künftig konkretisieren. Nach den FAQ der Kommissionsdienststellen zum CRA, Version 1.4 vom 04.09.2026, Nr. 6.10, sollten die horizontalen Normen zu Design, Entwicklung, Herstellung und Schwachstellenbehandlung bis 30. August 2026 und die vertikalen Normen bis 30. Oktober 2026 verabschiedet werden; die horizontale Norm zu den Produkteigenschaften nach Anhang I Teil I ist bis 30. Oktober 2027 vorgesehen[19]. Ein im Juli 2026 notifizierter, noch nicht angenommener Entwurf zur Änderung des Normungsauftrags sieht eine Verschiebung auf den 31. Oktober beziehungsweise 31. Dezember 2026 vor[23]. Bis zum 11. Oktober 2026 war keine Fundstelle einer CRA-harmonisierten Norm im Amtsblatt der Europäischen Union veröffentlicht. Die Konformitätsvermutung nach Art. 27 CRA entsteht erst mit einer solchen Veröffentlichung.

Was die TR-03183 Teil 2 leistet

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

  • Zulässige Formate und Mindestversionen: JSON oder XML sowie CycloneDX ab v1.6 oder SPDX ab v3.0.1, jeweils nur in offiziell freigegebenen Spezifikationsversionen
  • Verbindliche Datenfelder in drei Stufen (Pflichtfelder, Zusatzfelder, sofern vorhanden, und optionale Felder) — für die SBOM selbst und je Komponente
  • Ein Feld-für-Feld-Mapping dieser Datenfelder auf SPDX 3.0.1 (JSON) und CycloneDX 1.6 (JSON) im Anhang (Kap. 8.2)
  • Fünf abgestufte Detailgrade einer SBOM sowie sechs SBOM-Klassen nach Entstehungszeitpunkt
  • Eine eigene Lizenzsystematik mit verbindlicher Kaskade für SPDX-Lizenzbezeichner
  • Neu in v2.1.0: logische und identifizierte Komponenten sowie präzisierte BOM-Referenzen
  • Die klare Trennung von SBOM und Schwachstelleninformationen (letztere gehören in CSAF/VEX)
  • Regeln zur SBOM-Pflege: Für jede Softwareversion ist eine eigene SBOM zu erzeugen. Eine aktualisierte SBOM für eine bereits ausgelieferte Softwareversion ist genau dann — und nur dann — zu erstellen, wenn zusätzliche Informationen zu enthaltenen Komponenten vorliegen oder Fehler in den SBOM-Daten korrigiert werden (Kap. 3.1). Wird eine Komponente verändert, muss ihr eine neue Softwareversion zugewiesen werden.

Übergangssystem (Kap. 7): Anzuwenden ist stets die neueste auf der BSI-Website verfügbare Fassung der Richtlinie. Die unmittelbar vorhergehende Fassung darf noch bis sechs Monate nach Erscheinen einer neuen Fassung für die Erzeugung konformer SBOMs verwendet werden; ältere Fassungen sind ausgeschlossen. Für die Praxis heisst das: Seit Februar 2026 — sechs Monate nach Erscheinen der v2.1.0 am 20. August 2025 — ist die Vorgängerfassung v2.0.0 nicht mehr nutzbar. Eine SBOM, die zum Zeitpunkt ihrer Auslieferung konform war, bleibt es allerdings, auch wenn später neue Fassungen der Richtlinie erscheinen. Umgekehrt sollten Empfänger von SBOMs in der Lage sein, ältere, seinerzeit konforme SBOM-Fassungen zu interpretieren.

Lizenzidentifikation — eine verbindliche Kaskade (Kap. 6.1): Lizenzen müssen über den passenden SPDX-Lizenzbezeichner oder eine darauf aufbauende SPDX-Lizenz-Expression benannt werden. Das Mitliefern des Lizenztextes ist zwar in SPDX und CycloneDX möglich, ersetzt den Bezeichner aber ausdrücklich nicht. Findet sich kein passender Bezeichner in der SPDX-Lizenzliste, ist zwingend die Lizenzdatenbank ScanCode LicenseDB (AboutCode) heranzuziehen; deren Bezeichner tragen das Präfix LicenseRef-scancode-…. Erst wenn auch dort kein Bezeichner existiert, ist ein eigener Bezeichner nach dem Muster LicenseRef-<lizenzerfassende Stelle>-… zu vergeben. Mehrfachlizenzierungen, Lizenzwahlrechte und Ausnahmeklauseln sind über die zulässigen SPDX-Operatoren abzubilden.

Die TR unterscheidet dabei bewusst drei Lizenzkategorien (Kap. 3.2.8), die nicht mit den Formatbegriffen „declared“ und „concluded“ identisch sind: die Originallizenz(en), die der Ersteller der Komponente vergeben hat; die Distributionslizenz(en), unter denen die Komponente von einem Lizenznehmer genutzt werden kann; und die effektive Lizenz, unter der der Ersteller der aktuellen SBOM die Komponente selbst nutzt. Das BSI begründet die eigene Terminologie damit, dass „declared“ und „concluded“ in SPDX und CycloneDX unterschiedlich definiert sind und eine dritte Bedeutung die Begriffe endgültig überfrachten würde. Beim Zusammenführen mehrerer SBOMs ist die effektive Lizenz jeweils neu zu bestimmen.

Eigene Property-Taxonomie: Weil weder SPDX noch CycloneDX alle von der TR verlangten Felder nativ abbilden — etwa die Executable-, Archive- und Structured-Properties —, stellt das BSI eine eigene, bei CycloneDX registrierte Property-Taxonomie als Schlüssel-Wert-Paare bereit (github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy). Wer sein SBOM-Tooling gegen die TR ausrichtet, sollte diese Taxonomie und das Mapping in Kap. 8.2 zum Ausgangspunkt der Konfiguration machen, statt Felder frei zu erfinden.

Wie tief muss die SBOM gehen? Die fünf Detailgrade

Die Frage nach der Tiefe der Abhängigkeitsauflösung ist die häufigste Rückfrage in Projekten — und die TR beantwortet sie präzise. Sie nennt zwar keine feste Zahl an Ebenen, aber ein klares Kriterium (Kap. 5.1): Die rekursive Auflösung der Abhängigkeiten muss mindestens für jede Komponente im Lieferumfang auf jedem Pfad abwärts erfolgen, und zwar bis einschliesslich der ersten Komponente, die ausserhalb des Lieferumfangs liegt. Diese erste ausserhalb liegende Komponente muss zumindest identifiziert sein — also mit Ersteller, Name, Version und weiteren eindeutigen Identifikatoren geführt werden —, damit sich zwei SBOMs später eindeutig verketten lassen, etwa die SBOM des Lieferumfangs mit der SBOM der Ausführungsumgebung. Ihre eigenen Abhängigkeiten müssen dann nicht mehr aufgelöst werden.

Dieses Kriterium entspricht dem Detailgrad „Delivery item SBOM“. Die TR beschreibt im Anhang (Kap. 8.3) fünf Detailgrade, die sich als gemeinsame Sprache für Kunden- und Lieferantengespräche eignen:

  1. Top-level SBOM — vollständige Beschreibung der primären Komponente und aller direkt von ihr abhängigen Komponenten (entspricht einer 1-Level-SBOM).
  2. n-level SBOM — vollständige Beschreibung aller Komponenten bis zu einer auf n Schritte begrenzten Auflösungstiefe.
  3. Transitive SBOM — Auflösung auf jedem Pfad mindestens bis zur ersten externen (Dritt-)Komponente; diese muss mindestens identifiziert sein.
  4. Delivery item SBOM — Auflösung auf jedem Pfad mindestens bis zur ersten Komponente ausserhalb des Lieferumfangs; dies ist der Mindeststandard der TR.
  5. Complete SBOM — vollständige Beschreibung und vollständige rekursive Auflösung sämtlicher direkter und transitiver Abhängigkeiten ohne Abbruchkriterium.

Beachten Sie den Abstand zum Verordnungstext: Der CRA verlangt in Anhang I Teil II Nr. 1 ausdrücklich nur die obersten Abhängigkeiten — dem entspricht die Top-level SBOM. Die TR setzt mit der Delivery item SBOM erheblich höher an. Eine Forderung nach Auflösung „aller Ebenen“ läuft dagegen faktisch auf eine Complete SBOM hinaus — deutlich mehr, als selbst die TR als Minimum vorsieht. Hängt die primäre Komponente von mehreren Instanzen derselben Komponente mit unterschiedlichen Metainformationen ab, sind alle Instanzen einzeln mit ihren jeweiligen Angaben aufzuführen.

Sechs SBOM-Klassen nach Entstehungszeitpunkt

Ergänzend unterscheidet die TR sechs Klassen danach, wann im Entwicklungs- und Auslieferungsprozess eine SBOM entsteht (Kap. 8.4) — eine Unterscheidung, die bei der Einbindung in die CI/CD-Pipeline direkt zum Tragen kommt: Design SBOM (aus der geplanten Komponentenauswahl, die Komponenten müssen noch nicht existieren), Source SBOM (aus Entwicklungsumgebung und Quelldateien), Build SBOM (im Build-Prozess erzeugt), Analysed SBOM (nachträglich aus Artefakten wie Binaries, Paketen oder Containern analysiert, auch „3rd party SBOM“), Deployed SBOM (Inventar der Software auf einem System) und Runtime SBOM (zur Laufzeit erhoben, auch „Dynamic SBOM“).

Für die Build-SBOM gibt die TR zwei praktische Hinweise: Massgeblich ist der Linker-Lauf, nicht der Compiler-Lauf, damit bereits vorkompilierte Binärkomponenten erfasst werden; und damit Prüfsummen Komponenten eindeutig identifizieren können, sind reproduzierbare Builds erforderlich. Bei interpretiertem Code existiert nur Quellcode — dort ist jede ausführbare Datei als Komponente zu führen und der Interpreter als Abhängigkeit anzugeben.

Praktische Richtlinien aus TR-03183 Teil 2

  1. Für jede Softwareversion eine eigene SBOM — Aktualisierung nur bei neuen Komponenteninformationen oder Fehlerkorrektur (Kap. 3.1)
  2. Abhängigkeiten mindestens bis einschliesslich der ersten Komponente ausserhalb des Lieferumfangs auflösen, diese mindestens identifizieren; je Komponente kennzeichnen, ob die Aufzählung ihrer Abhängigkeiten vollständig ist (Kap. 5.1 und 5.2.2)
  3. Versionsangaben nach den Regeln der TR bestimmen — bei interpretiertem Code im Lieferumfang die exakt erforderliche Version, ausserhalb die minimal erforderliche, wobei Versionen mit erreichtem End-of-Life und mit bekannten Schwachstellen übersprungen werden sollten (Kap. 3.2.1); bestehende Identifikatoren bleiben unverändert, SemVer oder CalVer werden empfohlen, fehlt eine Version, gilt das Dateiänderungsdatum nach RFC 3339 (Kap. 5.2.2)
  4. Lizenzen ausschliesslich über SPDX-Bezeichner benennen — Lizenztext ist kein Ersatz; die Fallback-Kette SPDX-Lizenzliste → ScanCode LicenseDB → eigener LicenseRef--Bezeichner ist verbindlich (Kap. 6.1)
  5. Keine Schwachstelleninformationen in der SBOM — Advisories gehören in CSAF/VEX (Kap. 3.1 und 8.1.14)
  6. SBOMs digital signieren — die TR empfiehlt dies, damit Empfänger die Authentizität prüfen können (Kap. 8.1.15)

Ergänzend als allgemeine Praxisempfehlung — nicht als TR-Anforderung: Prüfen Sie Lizenzkonflikte früh, etwa die Kompatibilität der GPL (GNU General Public License) mit Ihrem Distributionsmodell. Die TR regelt die Lizenz-*Identifikation*, nicht die Kompatibilitätsprüfung. Und: Kombinieren Sie automatisierte Generierung mit einem menschlichen Review, bevor eine SBOM das Haus verlässt — eine manuelle Qualitätskontrolle verlangt die TR nicht, in der Praxis fängt sie aber die meisten Fehler ab.

Mindestumfang nach dem Massstab der BSI-Richtlinie

Checkliste für das Minimale

Die folgende Checkliste bildet den TR-Massstab ab, nicht den blossen Wortlaut des CRA. Sie ist damit die vorsichtige Variante, aber strenger als das, was Anhang I Teil II Nr. 1 CRA für sich genommen verlangt (dazu sogleich).

`` ☐ SBOM als CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1, jeweils in JSON oder XML (bei SPDX 3.0.1 praktisch JSON-LD, die einzige in der TR-Mappingtabelle dokumentierte Abbildung; nur offiziell freigegebene Spezifikationsversionen) ☐ Ersteller der SBOM als E-Mail-Adresse (ersatzweise URL) + Zeitstempel (UTC) ☐ Je Komponente: Ersteller (E-Mail-Adresse, ersatzweise URL), Name, Version, tatsächlicher Dateiname ☐ Abhängigkeiten je Komponente aufgezählt — Vollständigkeit der Aufzählung ausdrücklich gekennzeichnet ☐ Auflösung mindestens bis einschliesslich der ersten Komponente ausserhalb des Lieferumfangs; diese mindestens identifiziert ☐ Distributionslizenz je Komponente als SPDX-Bezeichner oder -Expression (Lizenztext genügt nicht) ☐ SHA-512-Prüfsumme der auslieferbaren Komponente ☐ Executable-, Archive- und Structured-Property je Komponente ☐ Zusatzfelder, sofern vorhanden: SBOM-URI, Quellcode-URI, URI der auslieferbaren Form, CPE/purl, Originallizenzen ☐ Nur Softwarekomponenten — keine Hardwarekomponenten ☐ Keine Schwachstelleninformationen in der SBOM — getrennt als CSAF/VEX ☐ Eigene SBOM je Softwareversion; Update nur bei neuen Informationen oder Fehlerkorrektur ☐ Pflege bis zum angegebenen Enddatum des Unterstützungszeitraums (mindestens fünf Jahre; kürzer nur bei entsprechend kürzerer Nutzungsdauer, länger bei langlebigen Produkten) ☐ Bereitstellbar gegenüber Marktüberwachungsbehörde nach Art. 13 Abs. 22 CRA (i. V. m. Art. 13 Abs. 13 CRA) ``

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 — mehr nicht.

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.

Unsere Linie — und was sie ist. Wir empfehlen, ein Build-Artefakt nicht als alleinige Grundlage der CRA-Compliance zu behandeln, sondern es in ein SPDX- oder CycloneDX-Dokument nach den Vorgaben der TR zu überführen. Das ist eine an der BSI-Richtlinie orientierte, vorsichtige Linie — keine zwingende Folge aus dem Verordnungstext. Wer sich am blossen Wortlaut des CRA ausrichtet, kann mit guten Argumenten weniger verlangen. Wer vorsorglich höher ansetzen will, legt den TR-Massstab zugrunde. Und weil die TR eben nicht bindend ist (oben, Rn. 264 [21]), bleibt die Frage offen, bis die Kommission nach Art. 13 Abs. 24 CRA Format und Elemente festlegt oder die harmonisierten Normen mit der Konformitätsvermutung nach Art. 27 CRA greifen.

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 ohne jede externe Referenz bleiben ausserhalb Ihrer Build-Umgebung wertlos. Die NTIA Minimum Elements[6] verlangen eindeutige Identifikatoren und Herkunftsangaben; die BSI TR-03183 Teil 2 [2] führt CPE und purl als Zusatzfelder — verpflichtend also, sofern sie existieren und im gewählten Format abbildbar sind. Verpflichtend sind dort in jedem Fall Ersteller, Name, Version und Dateiname jeder Komponente; erst damit wird eine Komponente für Aufsichtsbehörden und nachgelagerte Nutzer überhaupt auffindbar — und genau das ist nach Erwägungsgrund 77 CRA der Zweck der Stückliste[21].

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. Abhängigkeitslisten enden auf der ersten Ebene, obwohl der Lieferumfang mehrere Ebenen tiefer reicht. 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 nicht bindend, aber deutlich strenger: Auflösung bis zur ersten Komponente ausserhalb des Lieferumfangs, Pflichtfelder wie Ersteller als E-Mail-Adresse, SHA-512-Prüfsumme und Distributionslizenz, Formate CycloneDX ab 1.6 oder SPDX ab 3.0.1 in JSON oder XML.
  • Eine SBOM je Softwareversion, frei von Schwachstelleninformationen; der Abgleich gegen Schwachstellendatenbanken läuft getrennt, Ergebnisse gehen als Security Advisory beziehungsweise CSAF/VEX an die Nutzer.
  • 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 automatisch aus Ihrem Code (Git-Repository, Quellcode-Archiv oder CI-Pipeline) oder übernimmt vorhandene SBOMs per Upload; Bestandteile ohne eigenen Quellcode, etwa zugekaufte Firmware, werden manuell erfasst. 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 dar und kennzeichnet die eigene Empfehlung ausdrücklich als die an der BSI-Richtlinie orientierte, vorsichtige Linie — nicht als zwingende Folge aus dem Verordnungstext. Verbindlich geklärt wird die Frage erst durch einen Rechtsakt der Kommission nach Art. 13 Abs. 24 CRA oder durch harmonisierte Normen mit Konformitätsvermutung nach Art. 27 CRA. 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 18.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.