Von Redaktion codAIx | 11. Mai 2026

Das Zeitalter der Transparenz hat längst begonnen: Softwarehersteller müssen ab 11. Dezember 2027 für ihre Produkte eine Software Bill of Materials (SBOM) erstellen und vorhalten – das fordert der Cyber Resilience Act (CRA) [1]. Verlangt sind mindestens die obersten Abhängigkeiten in einem gängigen maschinenlesbaren Format; eine Veröffentlichungspflicht besteht nicht, wohl aber die Vorlage gegenüber der Marktüberwachungsbehörde auf Verlangen. Eine SBOM ist kein theoretisches Konzept mehr, sondern ein Geschäftsdokument, das zeigt, woraus Ihre Software wirklich besteht. In diesem Artikel erfahren Sie, welche Anforderungen der CRA konkret stellt, welche Standards und Formate anerkannt sind, welche Datenfelder die BSI-Richtlinie verlangt – und warum deren Massstab strenger ist als der des Verordnungstextes –, wie Sie die SBOM-Generierung automatisieren und warum eine SBOM für KI-Produkte komplexer ist als für traditionelle Software.

Quellenhierarchie für die SBOM-Pflicht: Der CRA-Verordnungstext (EU 2024/2847) ist unmittelbar geltendes EU-Sekundärrecht und als verbindliche Primärquelle für die Prüfung vorrangig; er verlangt für die SBOM nur „ein gängiges maschinenlesbares Format“ mit den „obersten Abhängigkeiten“ (Anhang I Teil II Nr. 1). Harmonisierte EU-Normen — entwickelt von CEN, CENELEC und ETSI im Rahmen des Normungsauftrags M/606 der EU-Kommission — sollen die technischen Detailfragen einheitlich konkretisieren. Nach den von den Kommissionsdienststellen erstellten FAQ zum CRA (Nr. 6.10, Fassung 1.3 vom 01.07.2026) sollen die horizontale Norm zu Design, Entwicklung und Herstellung sowie die horizontale Norm zur Schwachstellenbehandlung bis 30. August 2026 und 26 vertikale Normen bis 30. Oktober 2026 von den europäischen Normungsorganisationen verabschiedet werden; die horizontale Norm zu den Produkteigenschaften nach Anhang I Teil I dagegen erst bis 30. Oktober 2027 [19]. Hinzu kommt: Die Konformitätsvermutung nach Art. 27 CRA entsteht nicht schon mit der Verabschiedung durch die Normungsorganisationen, sondern erst mit der Veröffentlichung der Fundstelle im Amtsblatt der Europäischen Union. Bis dahin ist die TR-03183 Teil 2 v2.1.0 des Bundesamtes für Sicherheit in der Informationstechnik (BSI) die ausgereifteste nationale Konkretisierung in Deutschland: nicht EU-weit bindend, aber faktischer State-of-the-Art für deutsche Hersteller, deutsche notifizierte Stellen und das BSI als Koordinator-CSIRT nach Art. 14 CRA. Sie geht in Detailpunkten (z. B. SPDX-Mindestversion, Pflichtfelder) über den CRA-Mindeststandard hinaus. Diese Einordnung bestätigt der 2026 erschienene CRA-Kommentar von Schröder/Hartl: Das BSI habe in der TR-03183 eine eigene Definition der Software-Stückliste vorgenommen; deren Ergänzungen — etwa zu Mindestinformationen, Updates, Softwareversionen und zu der Frage, ob auch Schwachstellen enthalten sein sollten — gäben zwar einen Hinweis darauf, was unter einem gängigen maschinenlesbaren Format zu verstehen sei, seien aber letztlich nicht bindend; verbindlich festlegen könnte Format und Elemente der Software-Stückliste allein die Kommission, die dazu nach Art. 13 Abs. 24 CRA ermächtigt ist (NK-CRA/Hofmann/Iffländer, CRA Art. 3 Rn. 264 [21]). Der Kommentar bezieht sich dabei noch auf die Fassung v2.0.0 der TR; dieser Artikel legt durchgehend die aktuelle Fassung v2.1.0 vom 20.08.2025 zugrunde. Bei Konflikt zwischen EU- und nationaler Ebene gilt die EU-Vorgabe.

Rückblick: SBOM im Kontext der CRA-Serie

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

Heute fokussieren wir auf das Praktische: Was muss in eine CRA-konforme SBOM rein? Was gehört ausdrücklich nicht hinein? Welche Tools helfen bei der Generierung? Und wie vermeidet man häufige Fallstricke?

Was der CRA konkret zur SBOM verlangt

Legaldefinition: Was ist eine SBOM nach dem CRA?

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

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

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

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

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

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

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

Anders sieht es bei Anfragen der Marktüberwachungsbehörde aus: Nach Art. 13 Abs. 22 CRA muss die SBOM zusammen mit den übrigen Konformitätsnachweisen auf begründetes Verlangen an die zuständige Behörde übermittelt werden; gestützt wird dies durch die 10-Jahre-Aufbewahrungspflicht nach Art. 13 Abs. 13 CRA für die technische Dokumentation [1][8][15]. Dieselbe Zweiteilung zieht der Kommentar von Schröder/Hartl: Zu den Informationen nach Anhang II CRA gehört die Software-Stückliste nur, soweit der Hersteller sie den Nutzern überhaupt zur Verfügung stellt — veröffentlichen muss er sie nach Erwägungsgrund 77 nicht; in der technischen Dokumentation, die der Marktüberwachungsbehörde gegebenenfalls vorzulegen ist, muss sie dagegen enthalten sein (NK-CRA/Hofmann/Iffländer, CRA Art. 3 Rn. 258 [21]). Operativ heisst das:

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

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

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

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

1. Mindest-Unterstützungszeitraum (Art. 13 Abs. 8 CRA) — Untergrenze 5 Jahre, festzulegen als Enddatum. Hersteller müssen Sicherheitsupdates und Schwachstellenbehandlung grundsätzlich für mindestens 5 Jahre sicherstellen. 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/Hofmann/Iffländer, 1. Aufl. 2026, CRA 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]. Umgekehrt darf der Unterstützungszeitraum nach Art. 13 Abs. 8 UAbs. 3 S. 2 CRA auch kürzer als 5 Jahre sein, wenn die voraussichtliche Nutzungsdauer des Produkts dies trägt — Hersteller müssen die festgelegte Frist begründen und dokumentieren [9].

Festgelegt wird ein Enddatum, keine Dauer. Für die SBOM-Planung ist das der praktisch wichtigste Punkt: „Wir pflegen fünf Jahre“ ist noch keine Festlegung. Der juristische Kommentar von Schröder/Hartl bestimmt den Unterstützungszeitraum nicht über eine Dauer, sondern über ein festes Enddatum — die Verordnung regelt den Beginn nirgends, und Herstellungsende, Abgabe an den Endnutzer und Inverkehrbringen scheiden jeweils aus eigenen Gründen als Anknüpfungspunkt aus; nur ein Enddatum ist mit der Angabepflicht vereinbar (NK-CRA/Hofmann/Iffländer, 1. Aufl. 2026, CRA Art. 13 Rn. 25 [21]). Der Verordnungstext bestätigt das: Nach Art. 13 Abs. 19 CRA ist das Enddatum des Unterstützungszeitraums zum Zeitpunkt des Kaufs klar, verständlich und leicht zugänglich anzugeben, mindestens mit Monat und Jahr. Operativ heisst das für die SBOM: Jede Softwareversion trägt ein konkretes Datum, bis zu dem ihre Stückliste gepflegt und gegen Schwachstellendatenbanken abgeglichen wird — keine abstrakte Jahresspanne.

Wie das Datum zustande kommt — und wo es dokumentiert wird. Art. 13 Abs. 8 UAbs. 2 CRA nennt die Abwägungsfaktoren: neben der voraussichtlichen Nutzungsdauer, den angemessenen Erwartungen der Nutzer und der Art des Produkts 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 10 Jahre. Davon zu unterscheiden ist eine separate Pflicht: Bereitgestellte Sicherheitsaktualisierungen müssen für mindestens 10 Jahre oder die verbleibende Dauer des Unterstützungszeitraums verfügbar bleiben — je nachdem, welcher Zeitraum länger ist [13]. Dieselbe Lesart vertritt das BSI: Nach BSI TR-03183 Teil 1, Kap. 3.6 muss der Hersteller sicherstellen, dass Sicherheitsupdates und die technische Dokumentation mindestens zehn Jahre nach dem Inverkehrbringen des Produkts oder für die volle Dauer des Unterstützungszeitraums verfügbar sind, je nachdem, welcher Zeitraum länger ist [20]. Operativ heisst das: Jede ausgelieferte Update-Version koppelt sich mit der zugehörigen SBOM einer Softwareversion, und beides muss über die jeweils längere Frist abrufbar bleiben.

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

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

  • 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 der in der SBOM dokumentierten Komponenten gegen Schwachstellendatenbanken und Herstelleradvisories – nicht nur bei Major-Releases, sondern kontinuierlich.

Eine SBOM, die zum Releasezeitpunkt korrekt war, deren Komponenten aber drei Jahre später nicht mehr gegen aktuelle Schwachstellenmeldungen abgeglichen werden, trägt die CRA-Anforderungen an die Schwachstellenbehandlung nicht.

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

Empfohlener Mindestumfang gemäss BSI TR-03183 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 (Hersteller, Komponentenname, Version, eindeutige Identifikatoren, Abhängigkeitsbeziehung, SBOM-Ersteller, Zeitstempel). Die BSI TR-03183 Teil 2 [2] und die gelebte Praxis (CycloneDX, SPDX) gehen darüber hinaus und ergänzen insbesondere 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 der bessere Arbeitsraster für deutsche Hersteller. Zur Erinnerung: Sie ist rechtlich nicht bindend (siehe Kasten oben), aber der derzeit belastbarste Massstab, an dem sich deutsche Prüfer orientieren.

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, CRA 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
  • Serialisierungen: JSON, XML, RDF, Tag-Value — für TR-Konformität kommen davon jedoch nur JSON und XML in Betracht (siehe unten)
  • 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 muss eine neu erzeugte oder aktualisierte SBOM zwingend im JSON- oder XML-Format vorliegen und eine gültige SBOM nach CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 sein. Verwendet werden dürfen ausserdem nur offiziell freigegebene Spezifikationsversionen. SPDX in Tag-Value oder RDF scheidet für die TR-Konformität damit aus; SPDX in XML ist zulässig.

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. Beide erfüllen in den genannten Versionen die Vorgaben der BSI TR-03183 Teil 2 v2.1.0 [2] und 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 quasi die „CRA-Bedienungsanleitung“ für deutsche und europäische Softwarehersteller — rechtlich nicht bindend, praktisch aber der Massstab, an dem sich Prüfungen in Deutschland orientieren [21].

Was die TR-03183 Teil 2 leistet

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

  • Zulässige Formate und Mindestversionen: CycloneDX ab v1.6 oder SPDX ab v3.0.1, jeweils als JSON oder XML und 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. Wer „alle tieferen Ebenen“ fordert, verlangt sogar faktisch eine Complete SBOM — 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 zu überspringen sind (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 — belastbar gegenüber deutschen Behörden, notifizierten Stellen und Grosskunden, aber strenger als das, was Anhang I Teil II Nr. 1 CRA für sich genommen verlangt (dazu sogleich).

`` ☐ SBOM als JSON oder XML in CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 (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 5 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

Ob ein vorhandenes Build-Artefakt bereits als Software-Stückliste durchgeht, ist die praktisch häufigste und zugleich am wenigsten geklärte Frage — und die Antwort hängt vollständig davon ab, welchen Massstab man anlegt.

Position des Kommentars: ja, im Grundsatz. Schröder/Hartl 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, CRA 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 nur CycloneDX ab 1.6 oder SPDX ab 3.0.1, jeweils als 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 gegenüber deutschen Marktüberwachungsbehörden, notifizierten Stellen oder Grosskunden belastbar sein will, fährt mit dem TR-Massstab sicherer. 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 dagegen unstreitig:

  • Manuell gepflegte Excel-Listen sind zwar technisch auslesbar, gelten aber nicht als „gängiges maschinenlesbares Format“ im Sinne des CRA (Anhang I Teil II Nr. 1) [1]. Praxis und BSI TR-03183 Teil 2 [2] haben sich auf SPDX und CycloneDX verständigt — und die TR lässt davon nur die Serialisierungen JSON und XML zu. Ein eingescanntes oder als Bild abgelegtes Verzeichnis scheidet ohnehin aus, weil es nicht von Software durchsucht werden kann (Rn. 262 [21]).
  • 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

Falls Ihr Produkt KI-Komponenten enthält (Bezug zu Artikel 5 und Artikel 6), wird die Dokumentationslandschaft komplexer. Die CRA-SBOM bleibt auf die Softwareelemente und ihre Komponentenbeziehungen gerichtet. Trainingsdaten, Datenquellen und Test-Datasets gehören nicht allein wegen ihres KI-Bezugs automatisch in die CRA-SBOM; sie können jedoch aufgrund der KI-VO oder als ergänzende ML-BOM zu dokumentieren sein.

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 Erweiterung: ML-SBOM-Standard (Draft)

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

Warum SBOM-Compliance in der Praxis scheitert

Die rechtlichen Anforderungen klingen auf dem Papier überschaubar – „gängiges maschinenlesbares Format“, „oberste Abhängigkeiten“. Was uns in Gesprächen mit Herstellern regelmässig begegnet, ist eine ganz andere Realität: SBOMs, die einmal erzeugt und nie wieder aktualisiert wurden. Dependency-Listen, die bei der ersten Ebene aufhören, obwohl der Lieferumfang mehrere Ebenen tiefer reicht. Versionsangaben als Ranges statt als exakte Pins, so dass eine reproduzierbare SBOM gar nicht möglich ist. Interne Microservices, die aus der Stückliste herausfallen. Und — spiegelbildlich — SBOMs, in die Schwachstellenlisten hineingeschrieben wurden, so dass jede CVE-Aktualisierung eine neue Stückliste durch die Lieferkette schiebt, ohne dass sich an den Komponenten etwas geändert hätte.

Das ist kein Tool-Problem. Es ist ein kontinuierliches Compliance-Problem – eines, das bei jedem Release, jedem Dependency-Update und jeder neu gemeldeten Schwachstelle erneut bearbeitet werden muss und das bis zum angegebenen Enddatum des Unterstützungszeitraums (mindestens 5 Jahre, bei langlebigen Produkten länger) fortbesteht. Genau daran scheitern in unserer Erfahrung die meisten internen Initiativen: Die erste SBOM wird noch engagiert erstellt, aber Monate später ist sie veraltet, widerspricht dem Code, und beim ersten Audit fällt auf, dass zentrale Angaben nach Anhang I Teil II Nr. 1 und Anhang VII CRA fehlen.

crAIready für Ihre SBOM-Compliance

crAIready ist die KI-gestützte CRA-Compliance-Plattform, die Sie bei diesem Teil der CRA-Pflichten entlastet:

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

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

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act – CRA), insbesondere Art. 3 Nr. 39 (Begriffsbestimmung SBOM), Art. 13 (Pflichten der Hersteller, einschl. Abs. 5 Sorgfaltspflicht, Abs. 8 UAbs. 2 bis 5 Festlegung des Unterstützungszeitraums, Abs. 19 Angabe des Enddatums, Abs. 22 Übermittlung auf begründetes Verlangen und Abs. 24 Ermächtigung der Kommission zur Festlegung von Format und Elementen der Software-Stückliste), Art. 27 (Konformitätsvermutung), Art. 52 Abs. 16 (ADCO-Statistik und Leitlinien zu Unterstützungszeiträumen), Anhang I Teil II Nr. 1 (SBOM-Pflicht), Anhang II Nr. 9, Anhang VII (Inhalt der technischen Dokumentation, insbesondere Nr. 4 — Informationen zur Festlegung des Unterstützungszeitraums), 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, in: Wiebe (Hrsg.), Cyber Resilience Act – Kommentar, Nomos, 1. Auflage 2025, § 6 Rn. 19 (zur Legaldefinition der SBOM nach Art. 3 Nr. 39 CRA).

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

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

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

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

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

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

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

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

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

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

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

[19] Europäische Kommission (Dienststellen): „FAQs on the Cyber Resilience Act“, Version 1.3 vom 01.07.2026, insbesondere 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, M./Hartl, K. (Hrsg.) — Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos (zitiert als NK-CRA/Bearbeiter). Artikelweiser Kommentar zur Verordnung (EU) 2024/2847; Art. 3 Nr. 39 und Art. 13 kommentiert von Hofmann und Iffländer. 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 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). 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].

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.3 vom 01.07.2026 [19] herangezogen; letztere sind nicht verbindlich und geben keine offizielle Position der Kommission wieder. Als juristische Kommentare zur Auslegung wurden der CRA-Kommentar von Wiebe (Hrsg.), Nomos 2025 [7][8][9][11][12][13][14][16][17][18] sowie der CRA-Kommentar von Schröder/Hartl (Hrsg.), Nomos 2026 [21] herangezogen. Aus Wiebe stammen insbesondere die Legaldefinition nach Art. 3 Nr. 39 CRA (§ 6 Rn. 19), die Klarstellung zur Nicht-Veröffentlichungspflicht in Verbindung mit der Bereitstellungspflicht gegenüber Marktüberwachungsbehörden nach Art. 13 Abs. 22 und Abs. 13 CRA (Jossen § 5 Rn. 128 / Fn. 104), die Verkettung von SBOM-Pflege mit dem Mindest-Unterstützungszeitraum (§ 6 Rn. 25–27; 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 derselben Kommentierung zu Art. 13 CRA (Rn. 21, 23, 25–27) stammen die Bestimmung des Unterstützungszeitraums durch ein Enddatum statt durch eine Dauer, 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 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.

Stand: 12.08.2026 (v17). Das Erscheinungsdatum wurde im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 11.05.2026 gesetzt; zeitabhängige Formulierungen bleiben unverändert.

Stand: 06.08.2026 (v16). Letzte Korrekturschleife (Einarbeitung der Kommentierung zu Art. 13 CRA aus NK-CRA/Hofmann/Iffländer, 1. Aufl. 2026, Rn. 21–27 [21]): Der Drei-Fristen-Block wurde um den Punkt ergänzt, dass der Unterstützungszeitraum nicht als Dauer, sondern durch ein festes Enddatum bestimmt wird (Rn. 25) — korrespondierend mit der Angabepflicht nach Art. 13 Abs. 19 CRA, die mindestens Monat und Jahr verlangt. Ebenfalls neu: die Abwägungsfaktoren nach Art. 13 Abs. 8 UAbs. 2 CRA einschliesslich der Unterstützungszeiträume integrierter Komponenten, die künftige ADCO-Statistik nach Art. 52 Abs. 16 UAbs. 2 CRA und mögliche delegierte Rechtsakte nach Art. 13 Abs. 8 UAbs. 4 CRA (Rn. 23); die Pflicht zur Aufnahme der Abwägungsinformationen in die technische Dokumentation nach Art. 13 Abs. 8 UAbs. 5 CRA und Anhang VII Nr. 4 CRA (Rn. 27); der Serienbezug des Unterstützungszeitraums (Rn. 26); sowie der strenge Massstab, dass bereits die abstrakte Gefahr in Gestalt einer Schwachstelle die Pflicht auslöst (Rn. 21). Checkliste und der Abschnitt zum Scheitern der SBOM-Compliance auf das Enddatum umgestellt; die Beschreibung des Schwachstellen-Monitorings in Modul 3 von „täglicher Abgleich“ auf „kontinuierlicher Abgleich“ geändert. Quellen [1] und [21] sowie die Methodik entsprechend erweitert. Davor (v15, 06.08.2026; Einarbeitung des CRA-Kommentars von Schröder/Hartl (Hrsg.), Nomos 2026, Art. 3 Nr. 39 kommentiert von Hofmann/Iffländer [21]): Der Abschnitt „Was gilt NICHT als SBOM“ wurde zu „Genügt eine Dependency-Liste als SBOM? Ein umstrittener Massstab“ umgearbeitet — die frühere pauschale Aussage, Dependency Lock Files seien keine SBOM, wurde durch die Darstellung des Meinungsstandes ersetzt (Kommentar: Abhängigkeitslisten von Build-Werkzeugen wie die requirements.txt von pip genügen im Grundsatz, Rn. 265; BSI TR-03183 Teil 2 v2.1.0: genügen nicht, wegen Pflichtfeldern und Formatvorgaben), mit ausdrücklicher Kennzeichnung der eigenen Empfehlung als BSI-orientierte, vorsichtige Linie. Im Einleitungskasten zur Quellenhierarchie ergänzt, dass die BSI-Richtlinie nach Rn. 264 zwar Hinweis auf das „gängige maschinenlesbare Format“ gibt, aber nicht bindend ist und Format und Elemente allein die Kommission nach Art. 13 Abs. 24 CRA festlegen könnte; zugleich klargestellt, dass der Kommentar noch die TR-Fassung v2.0.0 zitiert, dieser Artikel dagegen die aktuelle v2.1.0 vom 20.08.2025. Neu aufgenommen: Beschränkung der Software-Stückliste auf Softwarekomponenten unter Ausschluss von Hardware (Rn. 259, auch in der Checkliste), Zweck- und Zielgruppenbestimmung nach Erwägungsgrund 77 (Rn. 261) sowie die Auslegung von „formaler Aufzeichnung“ und „maschinenlesbarem Format“ im Abschnitt zu den Formaten (Rn. 260–263). Der Beleg für die Zweiteilung Anhang II / technische Dokumentation wurde um Rn. 258 ergänzt. Art. 13 Abs. 24 CRA in die Übersicht der Rechtsgrundlagen und in die Quelle [1] aufgenommen; Abstand zwischen dem CRA-Minimum (Top-level SBOM) und dem TR-Mindeststandard (Delivery item SBOM) bei den fünf Detailgraden ausgesprochen; Checkliste als TR-Massstab gekennzeichnet. Redundanzen in den praktischen Richtlinien gekürzt. Davor (v14, 06.08.2026; vollständiger Abgleich des Artikels gegen den Volltext der BSI TR-03183 Teil 2 v2.1.0): Die zuvor an drei Stellen enthaltene Aussage, Schwachstellenbezüge (CVE/NVD, Advisory-Links) gehörten in die SBOM, wurde entfernt und durch die Regel der TR ersetzt — eine SBOM muss frei von Schwachstelleninformationen sein (Kap. 3.1); für deren Transport ist CSAF mit VEX als Profil vorgesehen (Kap. 8.1.14); dazu ein eigener Abschnitt zur Trennung statischer SBOM-Daten von dynamischen Schwachstellendaten. Erstveröffentlichungsdatum der TR auf den 12.07.2023 und die aktuelle Fassung auf den 20.08.2025 korrigiert. „Virtuelle Komponenten“ durch die tatsächliche Neuerung der v2.1.0 ersetzt: logische und identifizierte Komponenten sowie präzisierte BOM-Referenzen. Die Angabe, die TR gebe keine Mindesttiefe der Abhängigkeitsauflösung vor, durch das tatsächliche Kriterium aus Kap. 5.1 ersetzt (Auflösung mindestens bis einschliesslich der ersten Komponente ausserhalb des Lieferumfangs, diese mindestens identifiziert) und um die fünf Detailgrade aus Kap. 8.3 ergänzt. Mindestumfang und Checkliste auf die vollständigen Pflicht-, Zusatz- und optionalen Datenfelder nach Kap. 5.2 umgestellt (u. a. Ersteller als E-Mail-Adresse, tatsächlicher Dateiname, gekennzeichnete Vollständigkeit der Abhängigkeitsaufzählung, Distributionslizenz, SHA-512-Prüfsumme, Executable-/Archive-/Structured-Property). Formatvorgabe präzisiert: nur JSON oder XML und nur offiziell freigegebene Spezifikationsversionen (Kap. 4). Nicht belegte Zuschreibungen an die TR entfernt (Validierungs-Checklisten, Best Practices für Dateneingabe, Integration mit Vulnerability-Disclosure-Prozessen, manuelle Qualitätskontrolle, Unzulässigkeit von Versions-Ranges, GPL-Kompatibilitätsprüfung); Versionsregeln nach Kap. 3.2.1/5.2.2 und die Lizenzkaskade nach Kap. 6.1 ergänzt. Neu aufgenommen: Übergangssystem nach Kap. 7, drei Lizenzkategorien nach Kap. 3.2.8, BSI-Property-Taxonomie und Feld-Mapping nach Kap. 8.2, Empfehlung zur digitalen Signatur nach Kap. 8.1.15, sechs SBOM-Klassen nach Kap. 8.4. Normungszeitplan im Einleitungskasten nach FAQ Nr. 6.10 präzisiert (30.08.2026, 30.10.2026 und 30.10.2027) mit dem Hinweis, dass die Konformitätsvermutung nach Art. 27 CRA erst mit der Veröffentlichung der Fundstelle im Amtsblatt entsteht. BSI TR-03183 Teil 1 als zusätzlicher Beleg für die 10-Jahres-Aussagen aufgenommen. Davor (Stand 26.05.2026): Art. 13 Abs. 22 CRA als korrekter Verordnungsbezug für die Bereitstellung an die Marktüberwachungsbehörde gesetzt (ersetzt frühere Bezugnahme auf Art. 13 Abs. 7); Art. 13 Abs. 13 CRA und die zugehörige 10-Jahre-Aufbewahrungspflicht der technischen Dokumentation ergänzt; Art. 13 Abs. 6 CRA (Meldung an Komponentenhersteller, ggf. mit Code in maschinenlesbarem Format) ergänzt; Art. 13 Abs. 9 CRA (10 Jahre Verfügbarkeit Sicherheitsupdates) als eigenständige Frist abgegrenzt; Erwgr. 60 CRA korrekt erweitert um Software-Beispiele (Betriebssysteme, Videobearbeitungstools, industrielle Steuerungssysteme) und die Möglichkeit eines kürzeren Unterstützungszeitraums bei kürzerer Nutzungsdauer (Art. 13 Abs. 8 UAbs. 3 S. 2 CRA); Sanktionsdimension Art. 64 Abs. 2 CRA aufgenommen; Verwalter quelloffener Software (Art. 24 CRA) als Klarstellung zur SBOM-Abgrenzung aufgenommen; freiwillige Bereitstellung an Nutzer mit Anleitungs-Pflicht aus Anhang II Nr. 9 CRA ergänzt; Verortung der SBOM im Lieferantenmanagement nach Art. 13 Abs. 5 CRA ausgesprochen; Verzeichnis der Anhang-VII-Bestandteile (Risikobewertung, Cybersicherheits­konzept, Begründung nicht angewendeter Anforderungen) ergänzt; ML-BOM-Standard-Abschnitt korrigiert (Treiber sind CycloneDX und SPDX 3.0 mit AI Profile, nicht NTIA); BSI und NTIA bei Erstnennung ausgeschrieben.

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

→ Jetzt zum CRA-Quick-Check

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

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

Stand: 13.08.2026 (v18 — freigegebene Schlusskorrektur: CRA als unmittelbar geltendes EU-Sekundärrecht eingeordnet; CRA-Mindest-SBOM von weitergehender vollständiger beziehungsweise ML-BOM abgegrenzt; fehlende Prädikate, Kasus und Komposita korrigiert. Vorherige Fassung: v17; zeitabhängige Formulierungen unverändert.)