Notifications
Clear all
Topic starter
18/08/2026 2:44 pm
TL;DR: BSI’s latest SBOM guidance requires machine-digestible formats, richer component metadata, and recursive dependency resolution beyond direct dependencies, according to FOSSA. The direction of travel is clear: software transparency is becoming a compliance and assurance control, not just a documentation exercise.
NHIMG editorial — based on content published by FOSSA: BSI SBOM guidance v2.1.0 and what it means for software transparency
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should teams implement SBOM governance in a release pipeline?
A: Treat SBOM creation as a release control, not a post-build report.
Q: Why does dependency depth matter in software supply chain governance?
A: Because direct dependencies rarely tell the full story.
Q: What do security teams get wrong about supplier SBOMs?
A: They often assume receipt equals assurance.
Practitioner guidance
- Standardise SBOM generation in CI/CD Generate SBOMs for every release in a machine-digestible format and block release if required fields such as creator, timestamp, hashes, and dependency links are missing.
- Trace transitive dependencies to the delivery boundary Resolve dependencies recursively until the first out-of-scope component on each path, then record that boundary so accountability does not stop at the top-level package.
- Separate vulnerability disclosure from the SBOM record Publish vulnerability data in a standalone VEX or CSAF artefact so component inventories stay stable while exposure data can be refreshed continuously.
What's in the full article
FOSSA's full blog covers the operational detail this post intentionally leaves for the source:
- A line-by-line comparison of BSI TR-03183-2 fields against NTIA minimum elements for implementation teams
- Practical interpretation of recursive dependency scope for real build and packaging workflows
- Detailed guidance on when to publish vulnerability information in VEX or CSAF instead of the SBOM
- Additional commentary on how the guideline may influence future CRA implementation detail
👉 Read FOSSA's analysis of the latest BSI SBOM guidance →
BSI SBOM requirements: what they mean for software teams?
Explore further
18/08/2026 3:28 pm
BSI is effectively turning the SBOM into a governance artefact, not a procurement artefact. The required metadata, recursion depth, and file-level detail make the document useful for traceability, audit, and downstream automation. That matters because software assurance breaks down when teams cannot prove what was delivered, by whom, and with what dependencies. Practitioners should treat SBOM quality as a control outcome, not a documentation preference.
A question worth separating out:
Q: How do SBOMs and vulnerability disclosures work together?
A: They should be complementary, not merged. The SBOM should describe what the software is, while a VEX or CSAF file should describe what is currently known to be vulnerable. Separating them reduces staleness, avoids confusion, and lets each record follow its own update cadence.
👉 Read our full editorial: BSI SBOM guidance raises the bar on software traceability
