The check reads each field where the TR places it in its Tables 8 to 11. A value in another place, such as the hash on the component instead of on the deployable, does not count, and the result names where it was found. Required fields (5.2.1, 5.2.2) always apply. The TR asks for the additional fields (5.2.3, 5.2.4) whenever the value exists.
Tool · free
SBOM checker for BSI TR-03183-2
Drop a CycloneDX or SPDX SBOM. You see for each field of the TR how many components carry it and which lack it. The check runs in your browser; the file never leaves your machine.
- Field list from
- BSI TR-03183-2 v2.1.0
- Sections
- 4 (format), 5.2 (data fields)
- Formats
- CycloneDX, SPDX
- Upload
- none
- Cost
- free, no sign-up
Your file stays in your browser. Nothing is uploaded and nothing is stored.
Or paste the text
Checked: format and data fields under sections 4 and 5.2 of TR-03183-2 v2.1.0. Not checked: schema validity, depth of the dependency resolution (5.1) and licence identifiers (6.1). The result is a field check. It makes no statement of conformity.
What is checked
18 fields and where they sit in CycloneDX and SPDX
The SBOM itself
| Field and requirement | CycloneDX 1.6 | SPDX 3.0.1 |
|---|---|---|
| SBOM creator5.2.1E-mail address, a URL if there is none | metadata.manufacturer.url | metadata.manufacturer.contact[].email | CreationInfo.createdBy → Person | Organization, externalIdentifiers email | urlScheme |
| Timestamp5.2.1Time of compilation, UTC recommended | metadata.timestamp | CreationInfo.created |
| SBOM URI5.2.3URI of this SBOM | serialNumber | spdxId of the software_Sbom (rootElement of the SpdxDocument) |
Required fields per component
| Field and requirement | CycloneDX 1.6 | SPDX 3.0.1 |
|---|---|---|
| Component creator5.2.2E-mail address, a URL if there is none | components[].manufacturer.url | .manufacturer.contact[].email | software_Package.originatedBy → Person | Organization, externalIdentifiers email | other |
| Name5.2.2Name given by the creator, else the filename | components[].name | software_Package.name |
| Version5.2.2Creator's version, else the file's modification date (RFC 3339) | components[].version | software_Package.software_packageVersion |
| Filename5.2.2Actual filename, without path | properties[] "bsi:component:filename" | software_File.name, linked by hasDistributionArtifact |
| Dependencies5.2.2All direct dependencies and contained components | dependencies[].ref + dependsOn[] (empty too) | nested components[] | Relationship contains | dependsOn |
| Completeness5.2.2A clear statement whether the list is complete | compositions[].aggregate (complete | incomplete | unknown) | Relationship.completeness |
| Distribution licence5.2.2Licence under which a licensee may use the component | licenses[] with acknowledgement "concluded" | Relationship hasConcludedLicense → LicenseExpression |
| Hash value5.2.2SHA-512 of the deployable file | externalReferences[type "distribution"].hashes[] SHA-512 | software_File.verifiedUsing → Hash sha512 |
| Executable5.2.2executable or non-executable | "bsi:component:executable" | software_additionalPurpose "executable" |
| Archive5.2.2archive or no archive | "bsi:component:archive" | software_additionalPurpose "archive" |
| Structured5.2.2structured or unstructured; mixed counts as structured | "bsi:component:structured" | software_additionalPurpose "container" | "firmware" |
Additional fields per component
| Field and requirement | CycloneDX 1.6 | SPDX 3.0.1 |
|---|---|---|
| Source code URI5.2.4Source of the version used, else the repository | externalReferences[type "source-distribution"].url | software_SoftwareArtifact (primaryPurpose source), externalRef sourceArtifact, generates → Package |
| URI of the deployable5.2.4Points directly at the downloadable file | externalReferences[type "distribution"].url | software_File, externalRef binaryArtifact |
| Other identifiers5.2.4CPE, purl or SWID for lookups | cpe | purl | swid.tagId | externalIdentifiers cpe22 | cpe23 | swid | packageURL |
| Original licence5.2.4Licence assigned by the creator | licenses[] with acknowledgement "declared" | Relationship hasDeclaredLicense → LicenseExpression |
In CycloneDX each row applies to components[] and equally to the primary component under metadata.component. The values of the three properties and the property names come from the BSI taxonomy for CycloneDX. In SPDX 3, filename, hash and the three properties sit on the deployed file (software_File), not on the package.
Where SBOMs fall short
Three public SBOMs, checked on 07.11.2026
Components carrying the field, of all checked. None of the three files was written for the TR, and it shows. All three name every component. Creator, filename, hash on the deployable, completeness, distribution licence and the BSI properties are missing in all three.
| Field | STM32CubeF4 1.28.3STSBOM by ST · CycloneDX 1.5 | Dropwizard 1.3.15DropwizardCycloneDX project example · 1.2 | Alpine Linux 3.20.3Alpinegenerated by us with syft · 1.6 |
|---|---|---|---|
| Creator | 0/75 | 0/168 | 0/93 |
| Name | 75/75 | 168/168 | 93/93 |
| Version | 75/75 | 168/168 | 16/93 |
| Filename | 0/74 | 0/168 | 0/92 |
| Dependencies | 1/75 | 167/168 | 10/93 |
| Completeness | 0/75 | 0/168 | 0/93 |
| Distribution licence | 0/75 | 0/168 | 0/93 |
| SHA-512 of the deployable | 0/74 | 0/168 | 0/92 |
| Executable | 0/74 | 0/168 | 0/92 |
| Archive | 0/74 | 0/168 | 0/92 |
| Structured | 0/74 | 0/168 | 0/92 |
| URI of the deployable | 0/74 | 115/168 | 14/92 |
| CPE, purl or SWID | 1/75 | 168/168 | 15/93 |
ST
All 75 components carry name and version. Only the primary component lists dependencies. 74 carry a licence, but without the concluded or declared marker that CycloneDX 1.6 introduced.
Dropwizard
167 components carry a SHA-512, but on the component itself. The TR expects it on the distribution reference, the file that is shipped. 115 give a download URL, all 168 a purl.
Alpine
The newest format of the three, and still only one entry in six has a version: 77 of the 93 entries are single files without one. No component carries the three BSI properties.
One component in each is logical (TR 3.2.2): in ST the primary component STM32CubeF4, in Alpine the operating-system entry alpine 3.20.3. The check counts it only against the smaller field set, so the fields that describe a file read 74 or 92 instead of 75 or 93. Sources: the SBOM STMicroelectronics publishes for STM32CubeF4 v1.28.3, SBOM/dropwizard-1.3.15/bom.json from CycloneDX/bom-examples, Alpine minirootfs 3.20.3 from alpinelinux.org scanned with syft 1.45.1 to CycloneDX 1.6.
Adding missing fields
One component with every field of the TR
lwIP 2.2.1 as the project ships it as a zip, in CycloneDX 1.6. The SHA-512 is that of the file at the distribution URL, measured on 07.11.2026. Drop it into the check above as part of an SBOM with a primary component and a graph: the check counts every field of this component as present.
components[] · one entry
Dependencies and completeness
- 01Creator missingThe three SBOMs above use supplier or publisher instead; syft puts the package maintainer and e-mail into publisher. The TR reads manufacturer with url or contact.email, for the SBOM itself under metadata.manufacturer.
- 02Filename and the three properties missingNone of the three SBOMs above carries any of them, and syft does not set them. They are added as properties named bsi:component:filename, :executable, :archive and :structured, with exactly the values from the TR.
- 03Hash in the wrong placeA SHA-512 under components[].hashes describes the component. The TR wants it under externalReferences of type distribution, for the file that is shipped.
- 04Licence without concluded or declaredacknowledgement does not exist before CycloneDX 1.6. From 1.6 the licence is listed twice: concluded for the distribution licence, declared for the original licence. Mostly it is the same one. Where the licensee had to choose, say between GPL and commercial, the distribution licence is only the one chosen (TR 8.1.13).
- 05Completeness missingOne entry under compositions with aggregate complete, incomplete or unknown and the bom-refs it covers. Components without dependencies of their own still appear in the graph with an empty dependsOn.
Not every component needs everything
Three kinds of component, three field sets
The TR does not ask every component for every field. The check assigns each component a kind and counts only the fields that apply to that kind. The result says how many components of each kind it found.
Fully describedTR 5.2.2
all 11 required fields and the 4 additional ones
The normal case: an executable file, an archive, a library.
LogicalTR 3.2.2
creator, name, version, dependencies, completeness, licences, identifiers
Groups files under a product name, such as an operating system or an application. In CycloneDX recognised by type application, framework, operating-system, platform, container or device with no file, download or hash, in SPDX 3 by such a software_primaryPurpose with no deployed file.
ReferencedTR 3.2.5
creator, name, version
Described in another SBOM that is referenced. Recognised by an externalReference of type bom.
A fourth kind, the merely identified component (3.2.4), looks like a fully described one in the file. The check therefore counts it against every required field. If such entries lack filename, hash, dependencies, licences or the three properties, that is not a fault as long as the component lies outside the scope of delivery (5.1).
Questions
Frequently asked questions
01Is my SBOM uploaded?
No. The check runs as a program in your browser. The file is not sent to us or anyone else and is not stored.
02Is this a conformity check?
No. It shows which data fields from sections 4 and 5.2 of the TR your SBOM carries. It does not check the depth of the dependency resolution (5.1), the licence identifiers (6.1) or schema validity. The TR itself is a BSI guideline without force of law.
03Which formats work?
CycloneDX as JSON or XML in any version and SPDX as JSON in version 2.3 or 3.0.1. For new SBOMs the TR requires CycloneDX 1.6 or later or SPDX 3.0.1 or later; older versions are still checked and shown with that note.
04Why does SPDX 2.3 say “own mapping”?
The TR maps its fields only to CycloneDX 1.6 and SPDX 3.0.1. For SPDX 2.3 we use the obvious fields, such as originator, packageFileName and checksums. The executable, archive and structured properties do not exist there.
05Which version of TR-03183-2 applies?
Version 2.1.0 of 20.08.2025. The previous version 2.0.0 could be used for six more months (section 7); that period ended in February 2026. An SBOM that matched the version valid when it was delivered still meets the TR under section 7.
06Does the CRA require these fields?
From 11.12.2027 the CRA requires an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies (Annex I Part II point 1). It does not name the TR. The Commission may set format and elements by implementing act (Art. 13(24)).
07What separates the distribution licence from the original licence?
The original licence is the one the component's creator assigned. The distribution licence is the one under which a licensee may use the component from this SBOM (TR 3.2.8). In CycloneDX 1.6 they are licenses with acknowledgement declared and concluded. Values such as NOASSERTION or NONE do not count as a licence.
08Why does my SHA-256 not count?
The TR asks for a SHA-512 of the deployable file (5.2.2). Only a value of 128 hexadecimal characters is counted.
09What do I do about missing fields?
Most fields can be added in the tool that generates the SBOM, even though default output rarely carries them today: creator, filename and the three properties as bsi:component properties, the SHA-512 on the distribution reference. If whole components are missing, only an SBOM from the build or from the shipped image helps.
What is really in the image?
The SBOM says what the supplier declares. The firmware check reads the components from the firmware itself and matches them against known vulnerabilities.