BSI TR-03183-2: Welche SBOM-Pflichtfelder das BSI wirklich verlangt — und welche SBOM durch die Prüfung fällt

Formate und Versionen: Was das BSI akzeptiert — und was seit Februar 2026 nicht mehr

Teil 2 der Technischen Richtlinie BSI TR-03183 trägt den Titel „Software Bill of Materials (SBOM)" und liegt in der Version 2.1.0 vor (siehe https://www.bsi.bund.de/dok/TR-03183). Die Versionshistorie im Dokument selbst datiert diese Fassung auf den 20. August 2025. Sie ist damit die einzige Fassung, die derzeit für die Erzeugung neuer SBOM herangezogen werden darf — dazu gleich mehr.

Abschnitt 4 der Richtlinie ist ungewöhnlich knapp und ungewöhnlich hart formuliert: Eine neu erzeugte oder aktualisierte SBOM MUSS im JSON- oder XML-Format vorliegen und eine gültige SBOM nach einer der beiden folgenden Spezifikationen in einer der genannten Versionen sein — CycloneDX in Version 1.6 oder höher oder System Package Data Exchange (SPDX) in Version 3.0.1 oder höher. Ausdrücklich dürfen ausschließlich offiziell veröffentlichte Fassungen dieser Spezifikationen verwendet werden — nachzulesen in Abschnitt 4 des englischsprachigen Originaldokuments (siehe https://www.bsi.bund.de/dok/TR-03183-en).

Der Sprung von 2.0.0 auf 2.1.0 hat die Latte für beide Formate angehoben: Bei CycloneDX von 1.5 auf 1.6, bei SPDX von 2.2.1 auf 3.0.1. Das ist bei SPDX kein Versionsschritt, sondern ein Formatwechsel — SPDX 3.0 ist ein neues Informationsmodell, kein Punkt-Release von 2.x. Wer heute SPDX 2.3 ausliefert, weil das Werkzeug es standardmäßig erzeugt, liefert nach dieser Richtlinie kein akzeptiertes Artefakt, egal wie vollständig der Inhalt ist.

Eine praktische Stolperfalle liegt in der Navigation der Spezifikationsseiten. Die Übersichtsseite von SPDX führt als aktuelle Fassung „3.0" mit dem Hinweis, dass die Spezifikation ein internationaler offener Standard ist (ISO/IEC 5962:2021, siehe https://spdx.dev/use/specifications/). Die vom BSI geforderte Fassung 3.0.1 ist dagegen unter https://spdx.github.io/spdx-spec/v3.0.1/ veröffentlicht. Wer nur die Übersichtsseite prüft, hält 3.0 fälschlich für den Endstand. Bei CycloneDX ist die Lage entspannter: Die Spezifikationsübersicht weist Version 1.7 mit Freigabedatum 21. Oktober 2025 aus, veröffentlicht als ECMA-424 am 10. Dezember 2025 (siehe https://cyclonedx.org/specification/overview/). Da die Richtlinie „1.6 oder höher" verlangt, ist 1.7 zulässig — als offiziell veröffentlichte Fassung.

Die Pflichtfelder: zwei für die SBOM, zehn für jede einzelne Komponente

Abschnitt 5.2 der Richtlinie unterscheidet drei Kategorien: erforderliche Datenfelder (MUST), zusätzliche Datenfelder, die anzugeben sind, sofern sie existieren und die Formatspezifikation sie zulässt, sowie optionale Felder. Genau in dieser Abstufung liegt der Unterschied zwischen einer SBOM, die als Nachweis taugt, und einer, die nur nach einer aussieht.

Für die SBOM als Ganzes sind es nur zwei Pflichtfelder — und beide werden von generischen Scanner-Ausgaben regelmäßig verfehlt. Der Ersteller der SBOM ist als E-Mail-Adresse der erzeugenden Instanz anzugeben; ist keine E-Mail-Adresse verfügbar, MUSS es eine URL sein, etwa die Homepage des Erstellers oder die Projektseite. Der Zeitstempel bezeichnet Datum und Uhrzeit der Datenerhebung nach Maßgabe der Formatspezifikation, wobei die Richtlinie ausdrücklich empfiehlt, ausschließlich Zeitstempel in UTC („Zulu"-Zeit) zu verwenden. Ein Werkzeugname im Metadaten-Block ist kein Ersteller im Sinne der Richtlinie.

Auf Komponentenebene wird es umfangreicher: Für jede in der SBOM enthaltene Komponente sind mindestens zehn Felder anzugeben. Drei davon existieren in keinem der beiden Formate als natives Feld und werden deshalb über die BSI-Taxonomie als Schlüssel-Wert-Paare abgebildet — genau hier scheitern die meisten heute erzeugten Artefakte, weil kein Standardwerkzeug diese Eigenschaften von sich aus setzt.

Zusätzlich verlangt die Richtlinie vier weitere Felder je Komponente, sofern sie existieren und die Formatspezifikation sie hergibt: die URI des Quellcodes, die URI der auslieferbaren Form der Komponente, weitere eindeutige Identifikatoren wie CPE oder Package URL (purl) sowie die Originallizenzen. Für die SBOM selbst kommt in dieser Kategorie die SBOM-URI hinzu. Optional sind die effektive Lizenz, ein Hashwert des Quellcodes und die URL der security.txt des Komponenten-Erstellers.

Der eigentliche Sprengsatz: Wie tief die SBOM reichen muss

Der Cyber Resilience Act selbst formuliert an dieser Stelle bemerkenswert zurückhaltend. Anhang I Teil II Nummer 1 verlangt von Herstellern, Schwachstellen und Komponenten zu identifizieren und zu dokumentieren, unter anderem durch Erstellung einer Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt (siehe https://eur-lex.europa.eu/eli/reg/2024/2847/oj). „Mindestens die oberste Ebene" ist eine Untergrenze, die praktisch jedes moderne Build-Tool erfüllt.

Die TR-03183-2 setzt an genau dieser Untergrenze an und zieht sie deutlich nach oben. Abschnitt 5.1 verlangt für eine richtlinienkonforme SBOM eine rekursive Auflösung der Abhängigkeiten — mindestens für jede Komponente im Lieferumfang, auf jedem Pfad nach unten, mindestens bis einschließlich der ersten Komponente, die außerhalb des Lieferumfangs liegt. Der Grund ist in der Richtlinie ausdrücklich benannt: Ohne diese Identifikation der ersten Ebene außerhalb des Lieferumfangs fehlt die Information, um zwei SBOM korrekt aneinanderzuketten — etwa die SBOM des Lieferartikels und die SBOM der Umgebung, in der er ausgeführt wird.

Zwei weitere Regeln aus demselben Abschnitt haben mehr operative Sprengkraft, als ihre Länge vermuten lässt. Erstens: Hängt die primäre Komponente von mehreren Instanzen einer Komponente mit unterschiedlichen Metainformationen ab, MÜSSEN alle diese Instanzen einzeln mit ihren individuellen Metainformationen aufgeführt werden — das gilt laut Anhang ausdrücklich auch dann, wenn sich lediglich die Lizenzinformation unterscheidet. Zweitens: SBOM verwendeter Komponenten DÜRFEN referenziert statt eingebettet werden, aber nur dann, wenn sie ihrerseits richtlinienkonform sind. Und die Verantwortung für die Verfügbarkeit der referenzierten SBOM liegt beim Anbieter der SBOM der primären Komponente.

Der letzte Punkt ist eine Lieferantenklausel im technischen Gewand. Wer die SBOM eines Zulieferers referenziert, haftet dafür, dass sie im Prüfungsfall abrufbar ist — nicht der Zulieferer. Das gehört in den Vertrag, nicht in die Pipeline. Wie sich diese Anforderung strukturiert in die Lieferantenbewertung einhängen lässt, deckt unser Vendor- und Third-Party-Assessment ab; die dazugehörigen Prozessartefakte erzeugen Sie mit dem Governance Document Builder.

Sechs SBOM-Artefakte, die eine Prüfung nach TR-03183-2 nicht überstehen

Die folgende Liste ist keine Sammlung theoretischer Randfälle, sondern die direkte Umkehrung der normativen Anforderungen aus den Abschnitten 4, 5 und 8 der Richtlinie. Jeder Punkt lässt sich an einer vorhandenen SBOM in wenigen Minuten prüfen — mit jq, einem Schema-Validator und einem Blick in die Build-Konfiguration.

1. 1Die SBOM enthält Schwachstellendaten. Abschnitt 8.1.14 verlangt ausdrücklich, keine Schwachstelleninformationen in die SBOM aufzunehmen, auch wenn die Formatspezifikation das unterstützt — die Begründung ist, dass sich Schwachstellendaten laufend ändern, die Kerninformation einer SBOM aber statisch ist. Empfohlenes Format für die Verteilung von Schwachstelleninformationen ist CSAF, einschließlich VEX als Profil. CycloneDX kann Vulnerabilities nativ abbilden; genau das wird hier zum Fehler.
2. 2Die Eigenschaften ausführbar, Archiv und strukturiert fehlen. Diese drei Pflichtfelder existieren in keinem der Formate nativ. In CycloneDX werden sie über die BSI-Taxonomie als Properties bsi:component:executable, bsi:component:archive und bsi:component:structured gesetzt, gültig nur in components[]/properties und metadata/component/properties, und sie MÜSSEN je Komponente genau einmal vorkommen (siehe https://github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy). In SPDX 3.0.1 erfolgt die Abbildung über software_additionalPurpose mit einem erläuternden Kommentarfeld.
3. 3Der Hashwert ist kein SHA-512 oder bezieht sich auf das falsche Artefakt. Verlangt ist die kryptografisch sichere Prüfsumme der ausgelieferten beziehungsweise auslieferbaren Komponente als Datei auf einem Massenspeicher, als SHA-512. Ein SHA-1- oder SHA-256-Wert aus dem Paketmanager-Lockfile ist etwas anderes als der Hash der tatsächlich ausgelieferten Datei.
4. 4Die Lizenz steht als Volltext statt als Identifier. Abschnitt 6.1 verlangt, Lizenzen über den passenden SPDX-Lizenzidentifier oder einen darauf aufbauenden Lizenzausdruck zu benennen. Beide Formate erlauben es, Lizenztexte einzubetten — dies DARF ausdrücklich nicht als Ersatz für den Identifier verwendet werden. Findet sich kein passender Identifier bei SPDX, ist als Nächstes die Lizenzdatenbank Scancode LicenseDB heranzuziehen (Präfix LicenseRef-scancode-), erst danach ein eigener LicenseRef-Namensraum.
5. 5Die Abhängigkeitsliste sagt nicht, ob sie vollständig ist. Die Richtlinie verlangt bei den Abhängigkeiten nicht nur die Aufzählung, sondern die eindeutige Angabe der Vollständigkeit dieser Aufzählung. CycloneDX bietet dafür Compositions mit Vollständigkeitsgraden, SPDX das completeness-Attribut in Relationships. Wer das Feld leer lässt, liefert eine Liste ohne Aussage über ihren eigenen Geltungsbereich.
6. 6Die SBOM ist ärmer als der Build. Eine richtlinienkonforme SBOM MUSS dieselben Informationen enthalten, die während des Build-Prozesses verfügbar waren, beziehungsweise gleichwertige Informationen, wenn kein Build-Prozess existiert. Eine nachträglich aus dem fertigen Container-Image erzeugte SBOM — in der Klassifikation der Richtlinie eine „Analysed SBOM" beziehungsweise 3rd-Party-SBOM — verliert genau die Informationen, die nur im Build existierten. Sie ist damit nicht automatisch unzulässig, aber sie muss diesen Nachweis erbringen.

Was die Build-Pipeline liefern muss — und warum der Linker wichtiger ist als der Compiler

Anhang 8.4 der Richtlinie unterscheidet sechs SBOM-Klassen danach, wann im Lebenszyklus sie entstehen: Design, Source, Build, Analysed, Deployed und Runtime. Diese Unterscheidung ist keine Taxonomie um ihrer selbst willen, sondern eine Aussage darüber, welche Daten überhaupt verfügbar sind. Eine Design-SBOM beschreibt geplante Komponenten, die noch nicht existieren müssen. Eine Runtime-SBOM erfasst ausschließlich zur Laufzeit geladene Komponenten und externe Aufrufe. Dazwischen liegt die Build-SBOM, und sie ist die einzige Klasse, die den Anspruch „dieselben Informationen wie im Build" strukturell erfüllen kann.

Für die Build-SBOM macht die Richtlinie drei technische Ansagen, die sich unmittelbar in Pipeline-Arbeit übersetzen. Erstens: Um bereits existierende ausführbare, binäre Komponenten wie vorkompilierten Code zu erfassen, konzentriert sich die Erzeugung einer Build-SBOM auf den Linker-Lauf für übersetzten Code, nicht auf den Compiler-Lauf. Zweitens: Damit Hashwerte Komponenten eindeutig identifizieren können, müssen reproduzierbare Builds eingesetzt werden. Drittens: Bei interpretiertem Code existiert nur der Quellcode; folglich ist jede ausführbare Datei als Komponente aufzuführen, und der Interpreter ist so weit wie vernünftig möglich als Abhängigkeit anzugeben.

Die zweite Ansage ist die teuerste. Reproducible Builds sind kein Konfigurationsschalter, sondern ein Projekt: deterministische Zeitstempel, sortierte Dateireihenfolge, entfernte Build-Pfade, gepinnte Toolchains. Wer das nicht hat, kann Hashwerte zwar erzeugen, aber sie identifizieren die Komponente nicht eindeutig — und damit fällt genau die Eigenschaft weg, wegen der der Hash überhaupt ein Pflichtfeld ist.

Die dritte Ansage trifft jedes Python-, JavaScript-, Ruby- und PHP-Projekt, also den größten Teil moderner Unternehmenssoftware. Die naheliegende Interpretation — man liste die Pakete aus dem Lockfile — deckt die Anforderung nicht ab, weil bei interpretiertem Code jede ausführbare Datei als Komponente gilt und zusätzlich der Interpreter als Abhängigkeit zu benennen ist. Das ist ein anderer Granularitätsbegriff als der, mit dem npm- oder pip-basierte Generatoren arbeiten.

Ergänzend empfiehlt Abschnitt 8.1.15 die digitale Signatur der SBOM, damit Empfänger ihre Authentizität prüfen können — formuliert als „idealerweise", nicht als MUSS. In der Praxis ist das trotzdem die günstigste Maßnahme der ganzen Liste, weil sie den Nachweis der Herkunft an das Artefakt bindet statt an ein Ticketsystem. Wo Ihr Sicherheitsprogramm insgesamt steht, bevor Sie einzelne Pipeline-Schritte umbauen, klärt das Cybersecurity Assessment in strukturierter Form.

Der BSI-Namensraum und die Lizenzkette: zwei Details mit langem Schatten

Das BSI hat als Hilfestellung für die Erstellung TR-konformer SBOM einen eigenen CycloneDX-Namensraum angelegt und bei CycloneDX registriert; die Taxonomie ist im BSI-GitHub-Account veröffentlicht (siehe https://www.bsi.bund.de/dok/TR-03183). Das Repository führt die Taxonomie in Version 0.1.2, basierend auf TR-03183-2 v2.1.0, unter Apache-2.0-Lizenz (siehe https://github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy).

Der Namensraum bsi:component umfasst derzeit fünf aktive Eigenschaften: executable, archive und structured als je genau einmal pro Komponente erforderliche Flags, filename für den tatsächlichen Dateinamen mit maximal einem Vorkommen pro Komponente, sowie effectiveLicence für die effektive Lizenz aus Sicht des SBOM-Erstellers. Hinzu kommt die als deprecated markierte Eigenschaft associatedLicences, die auf TR-03183-2 v2.0.0 zurückgeht. Wer eine SBOM-Generierung aus dem Jahr 2025 unverändert weiterlaufen lässt, schreibt möglicherweise noch das abgekündigte Feld — technisch valide, richtlinienseitig veraltet.

Die Lizenzsystematik der Richtlinie ist bewusst anders geschnitten als die der Formate, und das ist eine Fehlerquelle in Migrationsprojekten. Abschnitt 8.1.13 stellt klar, dass CycloneDX und SPDX „declared" und „concluded license" unterschiedlich definieren und beide darauf abstellen, wie die Information gewonnen wurde. Die TR-03183-2 betrachtet die Lizenzlage stattdessen aus der Perspektive des SBOM-Erstellers in beide Richtungen der Lieferkette: aufwärts bis zur Originalquelle und abwärts als Distributionslizenz. Genannt wird als klassisches Beispiel Qt, wo der primäre Lizenznehmer sich zwischen GPL und einer proprietären Lizenz entscheiden muss — und nur die getroffene Wahl weitergereicht werden kann.

Praktisch heißt das: Die Zuordnung zwischen den TR-Feldern und den Lizenzfeldern der Formate ist kein Ein-zu-eins-Mapping und darf nicht als solches automatisiert werden. Die Richtlinie liefert dafür seit Version 2.1.0 in Anhang 8.2 eine ausformulierte Zuordnungsempfehlung inklusive JSON-Beispielen für beide Formate. Wer die Zuordnung selbst erfindet, produziert zwei SBOM-Generationen, die sich später nicht vergleichen lassen.

Warum das alles am 11. September 2026 hängt

Der Cyber Resilience Act, Verordnung (EU) 2024/2847, gilt nach Artikel 71 grundsätzlich ab dem 11. Dezember 2027. Artikel 14 gilt jedoch bereits ab dem 11. September 2026, Kapitel IV mit den Artikeln 35 bis 51 ab dem 11. Juni 2026 (siehe https://eur-lex.europa.eu/eli/reg/2024/2847/oj). Artikel 14 verlangt bei einer aktiv ausgenutzten Schwachstelle eine Frühwarnung unverzüglich, in jedem Fall binnen 24 Stunden nach Kenntniserlangung, danach binnen 72 Stunden die Schwachstellenmeldung und spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme den Abschlussbericht.

Die 24-Stunden-Frist ist keine Dokumentationsfrist, sondern eine Analysefrist. Zwischen der Meldung einer Schwachstelle in einer verbreiteten Bibliothek und der Frühwarnung liegt genau eine Frage: Steckt diese Version dieser Komponente in einem unserer ausgelieferten Produkte, und in welchen? Ohne belastbare, versionsgenaue SBOM ist diese Frage in 24 Stunden nicht beantwortbar — mit ihr ist sie eine Abfrage. Das ist der eigentliche Grund, warum SBOM-Qualität kein Compliance-Thema ist, sondern eine Reaktionsfähigkeit.

Verschärfend kommt hinzu, dass Artikel 14 keine Bestandsschutzfrist kennt. Zwar unterliegen Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, den wesentlichen Anforderungen nur bei einer wesentlichen Änderung — abweichend davon gelten die Pflichten aus Artikel 14 jedoch für alle in den Anwendungsbereich fallenden Produkte mit digitalen Elementen, die vor diesem Datum in Verkehr gebracht wurden. Den allgemeinen Rahmen dieser Meldepflicht haben wir im Beitrag Cyber Resilience Act: Die 24-Stunden-Meldepflicht ab September 2026 beschrieben, den Einstieg in die Richtlinienreihe in BSI TR-03183-1: Die offizielle Einstiegshilfe in den Cyber Resilience Act.

Die SBOM taucht im CRA an drei weiteren Stellen auf, die in Roadmaps regelmäßig fehlen. Anhang VII Nummer 2 Buchstabe b zählt sie zur technischen Dokumentation als Teil der Beschreibung der Schwachstellenbehandlungsprozesse. Anhang VII Nummer 8 verlangt ihre Vorlage auf begründetes Verlangen einer Marktüberwachungsbehörde, soweit das zur Prüfung der Konformität erforderlich ist. Und Artikel 13 Absatz 25 erlaubt es der Marktüberwachung, SBOM für eine unionsweite Abhängigkeitsbewertung anzufordern, deren Ergebnisse ADCO an die NIS-2-Kooperationsgruppe berichtet. Ergänzend kann die Kommission nach Artikel 13 Absatz 24 Format und Elemente der SBOM per Durchführungsrechtsakt festlegen — bis dahin ist die TR-03183-2 die konkreteste verfügbare Auslegung im deutschsprachigen Raum.

Ob Ihre Meldeprozesse den Stichtag tragen, prüft unser kostenloser CRA-Melde-Readiness-Check in rund drei Minuten — ohne Login, mit einer Auswertung, die direkt in ein Steering-Deck passt. Den vollständigen Werkzeugkasten für die begleitenden Governance-Artefakte finden Sie in der Template-Übersicht.