Werkzeug · kostenlos

SBOM prüfen: die Pflichtfelder der BSI TR-03183-2

Legen Sie eine CycloneDX- oder SPDX-SBOM ab. Sie sehen je Feld der TR, wie viele Komponenten es tragen und welchen es fehlt. Die Prüfung läuft in Ihrem Browser, die Datei verlässt Ihren Rechner nicht.

Jetzt prüfen Die TR-03183-2 erklärt

Auf einen Blick

Feldliste aus: BSI TR-03183-2 v2.1.0
Abschnitte: 4 (Format), 5.2 (Datenfelder)
Formate: CycloneDX, SPDX
Upload: keiner
Kosten: kostenlos, ohne Anmeldung

SBOM hier ablegenDatei wählenCycloneDX (JSON oder XML) und SPDX (JSON, 2.3 oder 3.0.1)

Ihre Datei bleibt in Ihrem Browser. Es wird nichts hochgeladen und nichts gespeichert.

Oder Text einfügen

Geprüft werden Format und Datenfelder nach Abschnitt 4 und 5.2 der TR-03183-2 v2.1.0. Nicht geprüft: die Gültigkeit gegen das Schema, die Tiefe der Abhängigkeiten (5.1) und die Lizenzkennungen (6.1). Das Ergebnis ist eine Feldprüfung. Eine Aussage zur Konformität trifft es nicht.

Was geprüft wird

18 Felder und wo sie in CycloneDX und SPDX stehen

Die Prüfung liest jedes Feld an der Stelle, an der die TR es in ihren Tabellen 8 bis 11 einträgt. Steht ein Wert woanders, etwa der Hash am Bauteil statt an der Auslieferung, zählt er nicht und das Ergebnis nennt die Stelle, an der er gefunden wurde. Pflichtfelder (5.2.1, 5.2.2) gelten immer. Die zusätzlichen Felder (5.2.3, 5.2.4) verlangt die TR, sobald es den Wert gibt.

Die SBOM selbst

Feld und Vorgabe	CycloneDX 1.6	SPDX 3.0.1
Ersteller der SBOM5.2.1E-Mail-Adresse, ohne E-Mail eine URL	CycloneDX 1.6`metadata.manufacturer.url \| metadata.manufacturer.contact[].email`	SPDX 3.0.1`CreationInfo.createdBy → Person \| Organization, externalIdentifiers email \| urlScheme`
Zeitstempel5.2.1Zeitpunkt der Erstellung, empfohlen in UTC	CycloneDX 1.6`metadata.timestamp`	SPDX 3.0.1`CreationInfo.created`
SBOM-URI5.2.3URI dieser SBOM	CycloneDX 1.6`serialNumber`	SPDX 3.0.1`spdxId des software_Sbom (rootElement des SpdxDocument)`

Pflichtfelder je Komponente

Feld und Vorgabe	CycloneDX 1.6	SPDX 3.0.1
Ersteller der Komponente5.2.2E-Mail-Adresse, ohne E-Mail eine URL	CycloneDX 1.6`components[].manufacturer.url \| .manufacturer.contact[].email`	SPDX 3.0.1`software_Package.originatedBy → Person \| Organization, externalIdentifiers email \| other`
Name5.2.2Name vom Ersteller, sonst der Dateiname	CycloneDX 1.6`components[].name`	SPDX 3.0.1`software_Package.name`
Version5.2.2Version vom Ersteller, sonst das Änderungsdatum der Datei (RFC 3339)	CycloneDX 1.6`components[].version`	SPDX 3.0.1`software_Package.software_packageVersion`
Dateiname5.2.2Tatsächlicher Dateiname, ohne Pfad	CycloneDX 1.6`properties[] "bsi:component:filename"`	SPDX 3.0.1`software_File.name, verbunden über hasDistributionArtifact`
Abhängigkeiten5.2.2Alle direkten Abhängigkeiten und enthaltenen Komponenten	CycloneDX 1.6`dependencies[].ref + dependsOn[] (auch leer) \| verschachtelte components[]`	SPDX 3.0.1`Relationship contains \| dependsOn`
Vollständigkeit5.2.2Klare Angabe, ob die Liste vollständig ist	CycloneDX 1.6`compositions[].aggregate (complete \| incomplete \| unknown)`	SPDX 3.0.1`Relationship.completeness`
Vertriebslizenz5.2.2Lizenz, unter der ein Lizenznehmer die Komponente nutzen darf	CycloneDX 1.6`licenses[] mit acknowledgement "concluded"`	SPDX 3.0.1`Relationship hasConcludedLicense → LicenseExpression`
Hashwert5.2.2SHA-512 der ausgelieferten Datei	CycloneDX 1.6`externalReferences[type "distribution"].hashes[] SHA-512`	SPDX 3.0.1`software_File.verifiedUsing → Hash sha512`
Ausführbar5.2.2executable oder non-executable	CycloneDX 1.6`"bsi:component:executable"`	SPDX 3.0.1`software_additionalPurpose "executable"`
Archiv5.2.2archive oder no archive	CycloneDX 1.6`"bsi:component:archive"`	SPDX 3.0.1`software_additionalPurpose "archive"`
Strukturiert5.2.2structured oder unstructured; gemischt zählt als structured	CycloneDX 1.6`"bsi:component:structured"`	SPDX 3.0.1`software_additionalPurpose "container" \| "firmware"`

Zusätzliche Felder je Komponente

Feld und Vorgabe	CycloneDX 1.6	SPDX 3.0.1
Quellcode-URI5.2.4Quellcode der genutzten Version, sonst das Repository	CycloneDX 1.6`externalReferences[type "source-distribution"].url`	SPDX 3.0.1`software_SoftwareArtifact (primaryPurpose source), externalRef sourceArtifact, generates → Package`
URI der Auslieferung5.2.4Zeigt direkt auf die ladbare Datei	CycloneDX 1.6`externalReferences[type "distribution"].url`	SPDX 3.0.1`software_File, externalRef binaryArtifact`
Weitere Kennungen5.2.4CPE, purl oder SWID zum Nachschlagen	CycloneDX 1.6`cpe \| purl \| swid.tagId`	SPDX 3.0.1`externalIdentifiers cpe22 \| cpe23 \| swid \| packageURL`
Originallizenz5.2.4Lizenz, die der Ersteller vergeben hat	CycloneDX 1.6`licenses[] mit acknowledgement "declared"`	SPDX 3.0.1`Relationship hasDeclaredLicense → LicenseExpression`

Bei CycloneDX gilt jede Zeile für components[] und genauso für die Primärkomponente unter metadata.component. Die Werte der drei Eigenschaften und die Property-Namen sind die der BSI-Taxonomie für CycloneDX. Bei SPDX 3 stehen Dateiname, Hash und die drei Eigenschaften an der ausgelieferten Datei (software_File), nicht am Paket.

Woran SBOMs scheitern

Drei öffentliche SBOMs, geprüft am 07.11.2026

Komponenten mit dem Feld, von allen geprüften. Keine der drei Dateien wurde für die TR geschrieben, und das sieht man. Den Namen nennen alle bei jeder Komponente. Ersteller, Dateiname, Hash an der Auslieferung, Vollständigkeit, Vertriebslizenz und die BSI-Eigenschaften fehlen in allen dreien.

Feld	STM32CubeF4 1.28.3STSBOM von ST · CycloneDX 1.5	Dropwizard 1.3.15DropwizardBeispiel des CycloneDX-Projekts · 1.2	Alpine Linux 3.20.3Alpinevon uns mit syft erzeugt · 1.6
Ersteller	0/75	0/168	0/93
Name	75/75	168/168	93/93
Version	75/75	168/168	16/93
Dateiname	0/74	0/168	0/92
Abhängigkeiten	1/75	167/168	10/93
Vollständigkeit	0/75	0/168	0/93
Vertriebslizenz	0/75	0/168	0/93
SHA-512 der Auslieferung	0/74	0/168	0/92
Ausführbar	0/74	0/168	0/92
Archiv	0/74	0/168	0/92
Strukturiert	0/74	0/168	0/92
URI der Auslieferung	0/74	115/168	14/92
CPE, purl oder SWID	1/75	168/168	15/93

ST
Name und Version stehen bei allen 75 Komponenten. Die Abhängigkeiten nennt nur die Primärkomponente. Lizenzen stehen bei 74, aber ohne die Angabe concluded oder declared, die erst CycloneDX 1.6 kennt.
Dropwizard
167 Komponenten tragen einen SHA-512, aber am Bauteil selbst. Die TR erwartet ihn an der distribution-Referenz, also an der Datei, die ausgeliefert wird. 115 nennen eine Download-URL, alle 168 eine purl.
Alpine
Das neueste Format der drei, und trotzdem hat nur jeder sechste Eintrag eine Version: 77 der 93 Einträge sind einzelne Dateien ohne Version. Keine Komponente trägt die drei BSI-Eigenschaften.

Je eine Komponente ist logisch (TR 3.2.2): bei ST die Primärkomponente STM32CubeF4, bei Alpine der Betriebssystem-Eintrag alpine 3.20.3. Die Prüfung zählt sie nur gegen den kleineren Feldsatz, deshalb steht bei den Feldern, die eine Datei beschreiben, 74 oder 92 statt 75 oder 93. Quellen: die SBOM, die STMicroelectronics zu STM32CubeF4 v1.28.3 veröffentlicht, SBOM/dropwizard-1.3.15/bom.json aus CycloneDX/bom-examples, Alpine minirootfs 3.20.3 von alpinelinux.org mit syft 1.45.1 im Format CycloneDX 1.6.

Fehlende Felder ergänzen

Eine Komponente mit allen Feldern der TR

lwIP 2.2.1, so wie das Projekt es als ZIP ausliefert, in CycloneDX 1.6. Der SHA-512 ist der der Datei unter der distribution-URL, gemessen am 07.11.2026. Legen Sie das Beispiel oben in die Prüfung, als Teil einer SBOM mit Primärkomponente und Graph: die Prüfung zählt bei dieser Komponente jedes Feld als vorhanden.

components[] · ein Eintrag

{
  "bom-ref": "lwip",
  "type": "library",
  "name": "lwip",
  "version": "2.2.1",
  "manufacturer": {
    "name": "lwIP project",
    "url": ["https://savannah.nongnu.org/projects/lwip/"]
  },
  "licenses": [
    { "license": { "id": "BSD-3-Clause", "acknowledgement": "concluded" } },
    { "license": { "id": "BSD-3-Clause", "acknowledgement": "declared" } }
  ],
  "purl": "pkg:generic/lwip@2.2.1",
  "externalReferences": [
    {
      "type": "distribution",
      "url": "https://download.savannah.nongnu.org/releases/lwip/lwip-2.2.1.zip",
      "hashes": [{ "alg": "SHA-512", "content": "feb37ce0dd452c1d0252311045e0e402944574b630c89855678435c0113b25359533ae503e747027cc0e2a0b32db0202f725367178c09ae6e6b351773c8998c3" }]
    },
    {
      "type": "source-distribution",
      "url": "https://git.savannah.nongnu.org/cgit/lwip.git/tag/?h=STABLE-2_2_1_RELEASE"
    }
  ],
  "properties": [
    { "name": "bsi:component:filename", "value": "lwip-2.2.1.zip" },
    { "name": "bsi:component:executable", "value": "non-executable" },
    { "name": "bsi:component:archive", "value": "archive" },
    { "name": "bsi:component:structured", "value": "structured" }
  ]
}

Abhängigkeiten und Vollständigkeit

"dependencies": [
  { "ref": "firmware", "dependsOn": ["lwip"] },
  { "ref": "lwip", "dependsOn": [] }
],
"compositions": [
  { "aggregate": "complete", "dependencies": ["firmware", "lwip"] }
]

01Ersteller fehltIn den drei SBOMs oben steht stattdessen supplier oder publisher; syft schreibt den Paketbetreuer samt E-Mail in publisher. Die TR liest manufacturer mit url oder contact.email, für die SBOM selbst unter metadata.manufacturer.
02Dateiname und die drei Eigenschaften fehlenIn keiner der drei SBOMs oben steht eines davon, auch syft setzt sie nicht. Sie kommen als properties mit den Namen bsi:component:filename, :executable, :archive und :structured dazu, mit genau den Werten aus der TR.
03Hash am falschen OrtEin SHA-512 unter components[].hashes beschreibt das Bauteil. Die TR verlangt ihn unter externalReferences vom Typ distribution, also für die Datei, die ausgeliefert wird.
04Lizenz ohne concluded oder declaredBis CycloneDX 1.5 gibt es acknowledgement nicht. Ab 1.6 steht die Lizenz zweimal: concluded für die Vertriebslizenz, declared für die Originallizenz. Meist ist es dieselbe. Musste der Lizenznehmer wählen, etwa zwischen GPL und kommerziell, ist die Vertriebslizenz nur die gewählte (TR 8.1.13).
05Vollständigkeit fehltEin Eintrag unter compositions mit aggregate complete, incomplete oder unknown und den bom-refs, für die er gilt. Komponenten ohne eigene Abhängigkeit stehen trotzdem mit leerem dependsOn im Graphen.

Nicht jede Komponente braucht alles

Drei Arten von Komponenten, drei Feldsätze

Die TR verlangt nicht von jeder Komponente jedes Feld. Die Prüfung ordnet jede Komponente einer Art zu und zählt nur die Felder, die für diese Art gelten. Das Ergebnis nennt, wie viele Komponenten jeder Art gefunden wurden.

Voll beschriebenTR 5.2.2
alle 11 Pflichtfelder und die 4 zusätzlichen
Der Normalfall: eine ausführbare Datei, ein Archiv, eine Bibliothek.
LogischTR 3.2.2
Ersteller, Name, Version, Abhängigkeiten, Vollständigkeit, Lizenzen, Kennungen
Fasst Dateien unter einem Produktnamen zusammen, etwa ein Betriebssystem oder eine Anwendung. In CycloneDX erkannt an Typ application, framework, operating-system, platform, container oder device ohne Datei, Download und Hash, in SPDX 3 an einem solchen software_primaryPurpose ohne ausgelieferte Datei.
ReferenziertTR 3.2.5
Ersteller, Name, Version
Steht in einer anderen SBOM, auf die verwiesen wird. Erkannt an einer externalReference vom Typ bom.

Eine vierte Art, die nur identifizierte Komponente (3.2.4), sieht in der Datei aus wie eine voll beschriebene. Die Prüfung zählt sie deshalb gegen alle Pflichtfelder. Fehlen bei solchen Einträgen Dateiname, Hash, Abhängigkeiten, Lizenzen oder die drei Eigenschaften, ist das kein Fehler, sofern die Komponente außerhalb des Lieferumfangs liegt (5.1).

Fragen

Häufig gestellte Fragen

01Wird meine SBOM hochgeladen?

Nein. Die Prüfung läuft als Programm in Ihrem Browser. Die Datei wird nicht an uns oder an Dritte gesendet und nicht gespeichert.

02Ist das eine Konformitätsprüfung?

Nein. Die Prüfung zeigt, welche Datenfelder aus Abschnitt 4 und 5.2 der TR in Ihrer SBOM stehen. Die Tiefe der Abhängigkeiten (5.1), die Lizenzkennungen (6.1) und die Gültigkeit gegen das Schema prüft sie nicht. Die TR selbst ist eine Richtlinie des BSI ohne Gesetzeskraft.

03Welche Formate gehen?

CycloneDX als JSON oder XML in jeder Version und SPDX als JSON in Version 2.3 oder 3.0.1. Für neue SBOMs verlangt die TR CycloneDX ab 1.6 oder SPDX ab 3.0.1; ältere Versionen werden trotzdem geprüft und mit diesem Hinweis gezeigt.

04Warum steht bei SPDX 2.3 „eigene Zuordnung“?

Die TR ordnet ihre Felder nur CycloneDX 1.6 und SPDX 3.0.1 zu. Für SPDX 2.3 nutzen wir die naheliegenden Felder, etwa originator, packageFileName und checksums. Die Eigenschaften ausführbar, Archiv und strukturiert gibt es dort nicht.

05Welche Version der TR-03183-2 gilt?

Version 2.1.0 vom 20.08.2025. Die Vorgängerversion 2.0.0 durfte noch sechs Monate danach genutzt werden (Abschnitt 7); diese Frist endete im Februar 2026. Eine SBOM, die bei ihrer Auslieferung der damals gültigen Version entsprach, entspricht der TR laut Abschnitt 7 auch danach.

06Verlangt der CRA diese Felder?

Der CRA verlangt ab dem 11.12.2027 eine SBOM in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1). Die TR nennt er nicht. Format und Elemente kann die Kommission per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24).

07Was unterscheidet Vertriebslizenz und Originallizenz?

Die Originallizenz hat der Ersteller der Komponente vergeben. Die Vertriebslizenz ist die, unter der ein Lizenznehmer die Komponente aus dieser SBOM nutzen darf (TR 3.2.8). In CycloneDX 1.6 stehen sie als licenses mit acknowledgement declared und concluded. Werte wie NOASSERTION oder NONE zählen nicht als Lizenz.

08Warum zählt mein SHA-256 nicht?

Die TR verlangt für die ausgelieferte Datei einen SHA-512 (5.2.2). Gezählt wird nur ein Wert aus 128 Hexadezimalzeichen.

09Was mache ich mit fehlenden Feldern?

Die meisten Felder lassen sich im Werkzeug ergänzen, das die SBOM erzeugt, auch wenn heutige Standardausgaben sie selten enthalten: Ersteller, Dateiname und die drei Eigenschaften als bsi:component-Properties, den SHA-512 an der distribution-Referenz. Fehlen Komponenten ganz, hilft nur eine SBOM aus dem Build oder aus dem ausgelieferten Image.

01Wird meine SBOM hochgeladen?: Nein. Die Prüfung läuft als Programm in Ihrem Browser. Die Datei wird nicht an uns oder an Dritte gesendet und nicht gespeichert.
02Ist das eine Konformitätsprüfung?: Nein. Die Prüfung zeigt, welche Datenfelder aus Abschnitt 4 und 5.2 der TR in Ihrer SBOM stehen. Die Tiefe der Abhängigkeiten (5.1), die Lizenzkennungen (6.1) und die Gültigkeit gegen das Schema prüft sie nicht. Die TR selbst ist eine Richtlinie des BSI ohne Gesetzeskraft.
03Welche Formate gehen?: CycloneDX als JSON oder XML in jeder Version und SPDX als JSON in Version 2.3 oder 3.0.1. Für neue SBOMs verlangt die TR CycloneDX ab 1.6 oder SPDX ab 3.0.1; ältere Versionen werden trotzdem geprüft und mit diesem Hinweis gezeigt.
04Warum steht bei SPDX 2.3 „eigene Zuordnung“?: Die TR ordnet ihre Felder nur CycloneDX 1.6 und SPDX 3.0.1 zu. Für SPDX 2.3 nutzen wir die naheliegenden Felder, etwa originator, packageFileName und checksums. Die Eigenschaften ausführbar, Archiv und strukturiert gibt es dort nicht.
05Welche Version der TR-03183-2 gilt?: Version 2.1.0 vom 20.08.2025. Die Vorgängerversion 2.0.0 durfte noch sechs Monate danach genutzt werden (Abschnitt 7); diese Frist endete im Februar 2026. Eine SBOM, die bei ihrer Auslieferung der damals gültigen Version entsprach, entspricht der TR laut Abschnitt 7 auch danach.
06Verlangt der CRA diese Felder?: Der CRA verlangt ab dem 11.12.2027 eine SBOM in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1). Die TR nennt er nicht. Format und Elemente kann die Kommission per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24).
07Was unterscheidet Vertriebslizenz und Originallizenz?: Die Originallizenz hat der Ersteller der Komponente vergeben. Die Vertriebslizenz ist die, unter der ein Lizenznehmer die Komponente aus dieser SBOM nutzen darf (TR 3.2.8). In CycloneDX 1.6 stehen sie als licenses mit acknowledgement declared und concluded. Werte wie NOASSERTION oder NONE zählen nicht als Lizenz.
08Warum zählt mein SHA-256 nicht?: Die TR verlangt für die ausgelieferte Datei einen SHA-512 (5.2.2). Gezählt wird nur ein Wert aus 128 Hexadezimalzeichen.
09Was mache ich mit fehlenden Feldern?: Die meisten Felder lassen sich im Werkzeug ergänzen, das die SBOM erzeugt, auch wenn heutige Standardausgaben sie selten enthalten: Ersteller, Dateiname und die drei Eigenschaften als bsi:component-Properties, den SHA-512 an der distribution-Referenz. Fehlen Komponenten ganz, hilft nur eine SBOM aus dem Build oder aus dem ausgelieferten Image.

Was steckt wirklich im Image?

Die SBOM sagt, was der Lieferant angibt. Der Firmware-Check liest die Komponenten aus der Firmware selbst und gleicht sie mit bekannten Schwachstellen ab.

Kostenloser Firmware-Check Was ist eine SBOM?