As governments and regulatory bodies around the world continue to push for software transparency, we’re continuing to see evolving SBOM (software bill of materials) regulations and recommendations.
In Europe, the Cyber Resilience Act (CRA) will soon impose SBOM requirements across a range of digital products. But even prior to the CRA entering into force, Germany’s Federal Office for Information Security (BSI) has been at the forefront of shaping the SBOM conversation in the EU. The BSI published the first version of its “Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products - Software Bill of Materials (SBOM)” publication in the summer of 2023, with several updates and new versions in the months and years that followed.
In this blog, we’ll break down the latest version of the BSI SBOM guidelines (v2.1.0, released in August of 2025), discuss key definitions and nuances, and compare it to other frameworks like the U.S. federal government’s NTIA Minimum Elements.
(Note: It’s expected that the BSI’s recommendations will at least partially inform the formal CRA SBOM requirement implementation, but details are still to be determined.)
Required Data Fields in the BSI SBOM Guidelines
The BSI guideline outlines specific fields that must be present in any compliant SBOM. These fields are designed to ensure that an SBOM is both machine-readable and sufficiently detailed to support practical use cases such as dependency analysis, vulnerability tracking, and compliance activities.
SBOM Format
First and foremost, the BSI states that SBOMs must be produced in a machine-digestible format: either CycloneDX (v1.6 or higher) or SPDX (v3.0.1 or higher).
SBOM Metadata
At the document level, the BSI guideline requires the following fields:
- Creator of the SBOM: The contact information (email, or URL if no email is available) of the person or organization that generated the SBOM
- Timestamp: The exact date and time when the SBOM was generated, following the format rules of the chosen SBOM schema
Component-Level Data Fields
For each component listed in the SBOM, document producers should include:
- Component Creator: Contact information for the entity that created or maintains the component.
- Component Name: The formal name assigned by the creator
- Component Version: The version identifier used by the creator
- Filename: The actual filename for the deployable artifact
- Dependency relationships: Explicit references to other direct dependencies upon which this component depends or contains
- Distribution Licences: Licensing information for the component; this must be communicated using standardized SPDX license identifiers or expressions
- Hash Value: A cryptographic checksum (e.g., SHA-512) of the deployable component form
- Executable Property: Communicates executability of the component; this field’s value is required to be either “executable” or “non-executable”
- Archive Properties: Communicates if the component is an archive; this field’s value must be either “archive” or “no archive”
- Structured Properties: Communicates whether the component is a structured file; this field’s value must be either “structured” or “unstructured”; (if the component includes both unstructured and structured elements, the SBOM producer is required to use the “structured” value)
Some additional fields (for example, unique identifiers like PURL) are also encouraged if available. You can see the full list on Page 14 of the BSI document.
BSI Guideline Nuances: Definitions and Clarifications
The BSI guideline also includes definitions and clarifications that ensure consistent interpretation of its requirements.
Update Frequency
Producers are expected to generate new SBOMs to accompany each new software version. Additionally, even if/when a new software version is not released, organizations should update SBOMs if:
- An error in SBOM data is corrected
- Additional information about components in the SBOM becomes available
Dependency Depth
In addition to including all direct (e.g. top-level) dependencies, the BSI document explicitly states that recursive dependency resolution must be performed at least until the first “out of scope” component on each path.
This means you must resolve dependencies recursively for every component you deliver (reference: "Scope of Delivery" - Section 8.1.11 on Page 20 of the most recent BSI guidance).
However, it also means identifying “at least up to and including the first component that is outside the scope of delivery.”
Page 35 of the BSI document explains the rationale for this requirement as follows:
The first component outside the scope of delivery must at least be identified in the SBOM in order to correlate this dependency unambiguously; consequently, its dependencies in turn do not have to be resolved.
Vulnerability Information
Although both SPDX and CycloneDX offer the ability for SBOM producers to embed component vulnerability information directly into the SBOM, the BSI document rejects this practice. Its rationale is that although the core information in an SBOM generally remains mostly consistent over time, vulnerability information is quite dynamic. As such, the BSI suggests SBOM producers recommend providing vulnerability information in a standalone file (such as a VEX or CSAF document).
BSI vs. NTIA SBOM Frameworks
The BSI covers similar ground to other SBOM guidance, but it's notably more comprehensive. We'll compare it with the U.S. federal government's NTIA Minimum Elements (broadly considered the foundational global SBOM publication) in the table below.
| Data Field | NTIA Minimum Elements | BSI TR-03183-2 |
|---|---|---|
| SBOM Creator | Required | Required |
| Timestamp | Required | Required |
| Supplier Name | Required | Required (the "Component Creator" field) |
| Component Name & Version | Required | Required |
| Dependency Relationships | Required | Required |
| Hash Values | Optional | Required |
| Licenses | Optional | Required (associated licences) |
| Filename | Not included | Required |
| Executable/Archive Metadata | Not included | Required |
In other words, the BSI guideline not only covers the basics that show up in most regulatory discussions, but also prescribes richer semantic metadata and deeper dependency resolution than the NTIA baseline. It will be interesting to see which direction the CRA goes when it releases its complete list of required data fields and dependency depth.
The Bottom Line on BSI SBOM Guidelines
Germany’s BSI TR-03183-2 represents one of the more structured and extensive SBOM content standards emerging from a national cybersecurity authority. While grounded in the same core principles as global SBOM norms like NTIA’s Minimum Elements, it adds mandatory licensing identifiers, cryptographic hashes, file-level metadata, and explicit dependency resolution requirements that enhance traceability and automation.
If your organization is looking for support generating and managing SBOMs for the BSI, CRA, or other regulatory standards, feel free to reach out to our team for information on how we can help.