BSI TR-03183: die Richtlinie des BSI zum Cyber Resilience Act

Die BSI TR-03183 ist eine Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik (BSI). Sie sammelt Anforderungen an Hersteller und Produkte und soll auf den Cyber Resilience Act (CRA), offiziell Cyberresilienz-Verordnung, vorbereiten. Sie ist nicht verbindlich und begründet keine Konformitätsvermutung; wer sie einhält, erfüllt damit nicht automatisch den CRA.

Am bekanntesten ist Teil 2 über die Stückliste (SBOM). Er stellt deutlich genauere Regeln auf als der CRA selbst.

Die vier Teile

Das BSI veröffentlicht die Richtlinie auf seiner Seite zur TR-03183, auf Englisch. Stand 1. November 2026 gibt es diese Teile:

Teil	Thema	Aktuelle Version
TR-03183-1	Allgemeine Anforderungen an Hersteller und Produkte, angelehnt an Artikel und Anhänge des CRA	1.0.0
TR-03183-2	Software Bill of Materials (SBOM): Format und Inhalt	2.1.0
TR-03183-3	Umgang mit eingehenden Schwachstellenmeldungen	1.0.0
TR-03183-H	Konformität über umfassende Qualitätssicherung (Modul H), aufbauend auf einem Managementsystem für Informationssicherheit nach ISO/IEC 27001, etwa IT-Grundschutz	1.1.0

Das BSI beschreibt die Richtlinie als Einstiegshilfe, vor allem für Hersteller ohne ausgereifte Sicherheitsprozesse. Sie soll nach und nach durch harmonisierte europäische Normen ersetzt werden, sobald es sie gibt.

Wie sie zum CRA steht

Der CRA verlangt eine maschinenlesbare SBOM „in einem gängigen maschinenlesbaren Format“, die mindestens die obersten Abhängigkeiten abdeckt (Anhang I Teil II Nr. 1 der Verordnung (EU) 2024/2847). Ein Format schreibt er nicht vor. Die Kommission darf das per Durchführungsrechtsakt nachholen (Artikel 13 Absatz 24), hat es aber noch nicht getan.

Die TR-03183-2 füllt diese Lücke für Deutschland mit konkreten Vorgaben. Rechtlich ist sie eine Empfehlung. Eine SBOM, die nicht TR-konform ist, kann den CRA trotzdem erfüllen, und umgekehrt beweist TR-Konformität allein nichts gegenüber einer Marktüberwachungsbehörde. Praktisch ist sie trotzdem nützlich: Wer nach ihr arbeitet, hat eine SBOM, die sich gut belegen lässt.

Was Teil 2 von einer SBOM verlangt

Die Version 2.1.0 vom 20. August 2025 stellt unter anderem diese Regeln auf:

Format. JSON oder XML, gültig nach CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Ältere Formatversionen reichen nicht mehr.

Eine SBOM pro Version. Für jede Softwareversion eine eigene SBOM. Ändert sich ein Bauteil, bekommt es eine neue Version und das Produkt eine neue SBOM.

Keine Schwachstellen in der SBOM. Die SBOM beschreibt, was drinsteckt, und ist für eine Version statisch. Informationen zu Schwachstellen ändern sich täglich und gehören in getrennte Dokumente, etwa CSAF-Sicherheitshinweise oder VEX. Eine Datei mit beidem ist nicht TR-konform.

Tiefe. Abhängigkeiten werden rekursiv aufgelöst, für alles im Lieferumfang, mindestens bis zur ersten Komponente außerhalb des Lieferumfangs. Das ist deutlich mehr als die „obersten Abhängigkeiten“ des CRA.

Pflichtfelder für die SBOM selbst: Ersteller (E-Mail-Adresse, sonst URL) und Zeitstempel.

Pflichtfelder für jede Komponente:

• Ersteller der Komponente, mit E-Mail-Adresse oder URL;
• Name und Version, ohne Version das Änderungsdatum der Datei;
• tatsächlicher Dateiname;
• direkte Abhängigkeiten, mit Angabe, ob die Liste vollständig ist;
• Lizenzen, mit SPDX-Lizenzkennungen;
• Hashwert der auslieferbaren Datei als SHA-512;
• ob die Komponente ausführbar ist, ein Archiv ist und strukturiert ist.

Dazu kommen Felder, die Sie angeben müssen, wenn es sie gibt: URI des Quellcodes, URI der herunterladbaren Form, weitere Kennungen wie CPE oder Package-URL (purl), ursprüngliche Lizenzen.

Und: Die SBOM muss dieselben Informationen enthalten, die beim Build vorliegen, oder gleichwertige, wo es keinen Build gibt. Am einfachsten erfüllen Sie das, wenn Sie die SBOM beim Bauen erzeugen.

Übergangsfristen

Teil 2 regelt selbst, welche Version gilt (Abschnitt 7). Maßgeblich ist die neueste Version auf der Website des BSI. Die direkte Vorgängerversion darf noch sechs Monate nach Erscheinen der neuen Version genutzt werden. Version 2.1.0 erschien am 20. August 2025, die Frist für die Vorgängerversion 2.0.0 lief also im Februar 2026 ab. Eine SBOM, die bei Auslieferung konform war, bleibt konform, auch wenn später eine neue Version der Richtlinie erscheint.

Prüfen Sie vor jedem Projekt auf der Seite des BSI, ob es eine neuere Version gibt.

Wann sich der Aufwand lohnt

Das BSI nennt die Richtlinie selbst eine Hilfestellung ohne verbindlichen Charakter. Sinnvoll ist sie trotzdem, wenn

• Ihre Kunden in Ausschreibungen oder Verträgen eine SBOM „nach BSI TR-03183-2“ verlangen;
• Sie ohnehin ein neues Build-System aufsetzen und das Format gleich richtig wählen wollen;
• Sie wissen wollen, wie genau eine SBOM sein muss, und der CRA allein Ihnen das nicht sagt.

Für den Einstieg reicht es oft, die Pflichtfelder als Checkliste neben die eigene SBOM zu legen und zu sehen, was fehlt.

Was Proofsheet hier erstellt, und was nicht

Proofsheet ist eine Web-App. Sie liest die fertige Datei, also Ihr Firmware-Image oder Ihre App, und listet automatisch die Bauteile und Versionen auf, die darin sichtbar sind. Die Stückliste erzeugt die App als CycloneDX 1.5 und SPDX 2.3. Diese Formatversionen liegen unter den Mindestversionen der TR-03183-2 in Version 2.1.0. Die Dateien sind also nicht TR-03183-2-konform, und Proofsheet behauptet das auch nicht.

Nützlich sind sie trotzdem als Gegenprobe zur eigenen Build-SBOM: Die App zeigt, was in der ausgelieferten Datei tatsächlich steckt, gleicht exakte Versionen mit der NVD ab und markiert Lücken von der CISA-Liste aktiv ausgenutzter Schwachstellen. Findet sie in der Datei ein Bauteil, das in Ihrer Build-SBOM fehlt, wissen Sie, wo Sie nachbessern müssen. Kein Mensch sieht sich Ihre Datei an.

Proofsheet liefert technische Nachweise, kein rechtliches Zertifikat. Wie eine erzeugte Stückliste aussieht, zeigt der Beispielbericht. Weiter lesen: SBOM nach dem CRA und technische Dokumentation.