BSI TR-03183 Part 2: The SBOM data fields the BSI actually demands — and which SBOMs fail an audit

Formats and versions: what the BSI accepts — and what stopped counting in February 2026

Part 2 of the Technical Guideline BSI TR-03183 is titled "Software Bill of Materials (SBOM)" and is published in version 2.1.0 (see https://www.bsi.bund.de/dok/TR-03183). The document history inside the guideline dates that version to 20 August 2025. It is therefore the only version that may currently be used to generate new SBOMs — more on that below.

Section 4 of the guideline is unusually short and unusually firm: a newly generated or updated SBOM MUST be in JSON or XML format and be a valid SBOM according to one of the following specifications in one of the specified versions — CycloneDX version 1.6 or higher, or System Package Data Exchange (SPDX) version 3.0.1 or higher. Only officially released versions of those specifications MUST be used — see section 4 of the original English document (see https://www.bsi.bund.de/dok/TR-03183-en).

The step from 2.0.0 to 2.1.0 raised the bar for both formats: CycloneDX from 1.5 to 1.6, SPDX from 2.2.1 to 3.0.1. For SPDX that is not a version increment but a change of format — SPDX 3.0 is a new information model, not a point release of the 2.x line. Shipping SPDX 2.3 today because the tool emits it by default means shipping an artefact this guideline does not accept, however complete its content may be.

One practical trap sits in the navigation of the specification sites. The SPDX specifications page lists "3.0" as the current version and notes that the specification is an international open standard (ISO/IEC 5962:2021, see https://spdx.dev/use/specifications/). The version the BSI requires, 3.0.1, is published at https://spdx.github.io/spdx-spec/v3.0.1/ instead. Checking only the overview page leaves you believing 3.0 is the end of the line. CycloneDX is easier: the specification overview states version 1.7 with a release date of 21 October 2025, published as ECMA-424 on 10 December 2025 (see https://cyclonedx.org/specification/overview/). Since the guideline asks for "1.6 or higher", 1.7 qualifies — as an officially released version.

The mandatory fields: two for the SBOM, ten for every single component

Section 5.2 of the guideline distinguishes three categories: required data fields (MUST), additional data fields that must be provided if they exist and the format specification accommodates them, and optional fields. That gradation is precisely the difference between an SBOM that works as evidence and one that merely looks like evidence.

For the SBOM as a whole there are only two mandatory fields — and generic scanner output misses both with striking regularity. The creator of the SBOM must be given as the email address of the entity that produced it; where no email address is available it MUST be a URL, for instance the creator homepage or the project page. The timestamp denotes the date and time of the SBOM data compilation according to the format specification, and the guideline explicitly recommends using timestamps in UTC ("Zulu" time) only. A tool name in the metadata block is not a creator in the sense of the guideline.

At component level the list grows: for each component included in the SBOM, at least ten fields must be provided. Three of them exist as a native field in neither format and are therefore expressed through the BSI taxonomy as key-value pairs — which is exactly where most artefacts generated today fail, because no standard tool sets those properties on its own.

On top of that the guideline requires four further fields per component wherever they exist and the format specification allows them: the source code URI, the URI of the deployable form of the component, other unique identifiers such as CPE or Package URL (purl), and the original licences. For the SBOM itself the same category adds the SBOM URI. Optional are the effective licence, a hash value of the source code and the URL of the component creator security.txt.

The real charge: how deep the SBOM has to reach

The Cyber Resilience Act itself is remarkably restrained on this point. Annex I Part II point (1) requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products (see https://eur-lex.europa.eu/eli/reg/2024/2847/oj). "At the very least the top level" is a floor that practically every modern build tool clears.

TR-03183-2 starts at that floor and lifts it considerably. Section 5.1 requires, for a compliant SBOM, recursive dependency resolution — at least for each component included in the scope of delivery, on each path downward, at least up to and including the first component that lies outside the scope of delivery. The guideline states the reason explicitly: without identifying that first level outside the scope of delivery, the information needed to chain two SBOMs correctly is missing — for example the SBOM of the delivery item and the SBOM of the environment in which it is executed.

Two further rules from the same section carry more operational force than their length suggests. First: if the primary component depends on multiple instances of a component with differing meta-information, all those instances MUST be listed separately with their individual meta-information — and the appendix states that this applies even when only the licence information differs. Second: SBOMs of used components MAY be referenced instead of merged, but if and only if they are themselves compliant with the guideline. And responsibility for the availability of referenced SBOMs rests with the provider of the SBOM of the primary component.

That last point is a supplier clause in technical clothing. Whoever references a supplier SBOM is answerable for its being retrievable at audit time — not the supplier. That belongs in the contract, not in the pipeline. How to hook this requirement into supplier evaluation in a structured way is covered by our vendor and third-party assessment; the corresponding process artefacts are produced with the Governance Document Builder.

Six SBOM artefacts that will not survive a TR-03183-2 review

The following list is not a collection of theoretical edge cases but the direct inversion of the normative requirements in sections 4, 5 and 8 of the guideline. Every item can be checked against an existing SBOM in minutes — with jq, a schema validator and a look at the build configuration.

1. 1The SBOM contains vulnerability data. Section 8.1.14 explicitly requires not to include vulnerability information in an SBOM, even where the format specification supports it — the rationale being that vulnerability data changes over time while the core information of an SBOM is static. The recommended format for distributing vulnerability information is CSAF, including VEX as a profile. CycloneDX can represent vulnerabilities natively; here that capability turns into a defect.
2. 2The executable, archive and structured properties are missing. These three mandatory fields exist natively in neither format. In CycloneDX they are set via the BSI taxonomy as the properties bsi:component:executable, bsi:component:archive and bsi:component:structured, valid only in components[]/properties and metadata/component/properties, and each MUST occur exactly once per component (see https://github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy). In SPDX 3.0.1 the mapping runs through software_additionalPurpose with an explanatory comment field.
3. 3The hash is not SHA-512, or refers to the wrong artefact. What is required is the cryptographically secure checksum of the deployed or deployable component as a file on a mass storage device, as SHA-512. A SHA-1 or SHA-256 value taken from a package manager lockfile is a different thing from the hash of the file you actually ship.
4. 4The licence appears as full text instead of an identifier. Section 6.1 requires licences to be named by the appropriate SPDX licence identifier or a licence expression built on one. Both formats allow licence text to be embedded — and that MUST NOT be used as a substitute for the identifier. Where no suitable identifier exists at SPDX, the Scancode LicenseDB must be consulted next (prefix LicenseRef-scancode-), and only then a custom LicenseRef namespace.
5. 5The dependency list does not say whether it is complete. For dependencies the guideline requires not only the enumeration but a clear indication of the completeness of that enumeration. CycloneDX offers compositions with aggregate completeness values, SPDX the completeness attribute on relationships. Leaving that field empty ships a list that says nothing about its own scope.
6. 6The SBOM is poorer than the build. A compliant SBOM MUST contain the same information as was available during the build process, or equivalent information where no build process exists. An SBOM generated afterwards from the finished container image — in the classification of the guideline an "analysed SBOM" or 3rd-party SBOM — loses precisely the information that only existed inside the build. That does not make it automatically inadmissible, but it does have to carry that proof.

What the build pipeline must emit — and why the linker matters more than the compiler

Appendix 8.4 of the guideline distinguishes six SBOM classes by the point in the lifecycle at which they are created: design, source, build, analysed, deployed and runtime. That distinction is not taxonomy for its own sake but a statement about which data is available at all. A design SBOM describes planned components that need not yet exist. A runtime SBOM captures only components loaded at runtime along with their external calls. Between them sits the build SBOM, and it is the only class that can structurally satisfy the claim "the same information as in the build".

For the build SBOM the guideline makes three technical statements that translate directly into pipeline work. First: in order to capture pre-existing executable, binary components such as precompiled code, creating a build SBOM focuses on the linker run for translated code, not the compiler run. Second: in order for hash values to identify components unambiguously, reproducible builds have to be employed. Third: in the case of interpreted code only the source code exists, hence each executable file has to be listed as a component and the interpreter has to be specified as a dependency as far as reasonably possible.

The second statement is the expensive one. Reproducible builds are not a configuration switch but a project: deterministic timestamps, sorted file order, stripped build paths, pinned toolchains. Without them you can still emit hash values, but they no longer identify the component unambiguously — which removes the very property that made the hash a mandatory field in the first place.

The third statement hits every Python, JavaScript, Ruby and PHP project, meaning the bulk of modern enterprise software. The obvious reading — list the packages from the lockfile — does not cover the requirement, because for interpreted code every executable file counts as a component and the interpreter has to be named as a dependency on top. That is a different notion of granularity from the one npm- or pip-based generators work with.

In addition, section 8.1.15 recommends digitally signing the SBOM so recipients can verify its authenticity — phrased as "ideally", not as a MUST. In practice it is still the cheapest measure on the whole list, because it binds provenance to the artefact rather than to a ticket system. Where your security programme stands overall, before you rebuild individual pipeline steps, is clarified in structured form by the Cybersecurity Assessment.

The BSI namespace and the licence chain: two details with long shadows

To help produce SBOMs compliant with Part 2, the BSI created its own CycloneDX namespace and registered it with CycloneDX; the taxonomy is published in the BSI GitHub account (see https://www.bsi.bund.de/dok/TR-03183). The repository carries the taxonomy at version 0.1.2, based on TR-03183-2 v2.1.0, under the Apache 2.0 licence (see https://github.com/BSI-Bund/tr-03183-cyclonedx-property-taxonomy).

The bsi:component namespace currently comprises five active properties: executable, archive and structured as flags each required exactly once per component, filename for the actual filename with at most one occurrence per component, and effectiveLicence for the effective licence from the perspective of the SBOM creator. There is also the deprecated property associatedLicences, which goes back to TR-03183-2 v2.0.0. Anyone still running an unchanged 2025 SBOM generation may well be writing the deprecated field — technically valid, but obsolete against the guideline.

The licence model of the guideline is deliberately cut differently from that of the formats, and that is a source of error in migration projects. Section 8.1.13 clarifies that CycloneDX and SPDX define "declared" and "concluded license" differently and that both focus on the manner in which the information was obtained. TR-03183-2 instead looks at the licence situation from the perspective of the SBOM creator in both directions of the supply chain: upstream to the original source and downstream as the distribution licence. The classic example named is Qt, where the primary licensee has to choose between GPL and a proprietary licence — and only the choice actually made can be handed further down.

Practically that means the mapping between the guideline fields and the licence fields of the formats is not one-to-one and must not be automated as if it were. Since version 2.1.0 the guideline provides a written mapping recommendation in appendix 8.2, including JSON examples for both formats. Inventing your own mapping produces two generations of SBOMs that cannot later be compared.

Why all of this hangs on 11 September 2026

The Cyber Resilience Act, Regulation (EU) 2024/2847, applies in principle from 11 December 2027 under Article 71. Article 14, however, applies from 11 September 2026, and Chapter IV with Articles 35 to 51 from 11 June 2026 (see https://eur-lex.europa.eu/eli/reg/2024/2847/oj). For an actively exploited vulnerability, Article 14 requires an early warning without undue delay and in any event within 24 hours of becoming aware of it, then a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.

The 24-hour deadline is not a documentation deadline but an analysis deadline. Between the disclosure of a vulnerability in a widely used library and the early warning sits exactly one question: is this version of this component inside any of our shipped products, and in which ones? Without a dependable, version-accurate SBOM that question cannot be answered in 24 hours — with one it becomes a query. That is the real reason SBOM quality is not a compliance topic but a response capability.

What sharpens this further is that Article 14 knows no grandfathering. Products placed on the market before 11 December 2027 are subject to the essential requirements only where they undergo a substantial modification — but by way of derogation, the obligations laid down in Article 14 apply to all products with digital elements within the scope of the regulation that were placed on the market before that date. We described the general frame of this reporting duty in Cyber Resilience Act: the 24-hour reporting duty from September 2026, and the entry point into the guideline series in BSI TR-03183-1: the official entry aid into the Cyber Resilience Act.

The SBOM appears in three further places in the CRA that roadmaps routinely miss. Annex VII point 2(b) counts it as part of the technical documentation, within the description of the vulnerability handling processes. Annex VII point 8 requires it to be supplied further to a reasoned request from a market surveillance authority, provided this is necessary to check compliance. And Article 13(25) allows market surveillance authorities to request SBOMs for a Union-wide dependency assessment, whose results ADCO reports to the NIS2 Cooperation Group. In addition, under Article 13(24) the Commission may specify the format and elements of the SBOM by implementing acts — until it does, TR-03183-2 is the most concrete available interpretation in the German-speaking market.

Whether your reporting processes carry the deadline is tested by our free CRA reporting readiness check in about three minutes — no login, with a result that drops straight into a steering deck. The full toolkit for the accompanying governance artefacts sits in the template overview.