Notifications
Clear all
Topic starter
18/08/2026 2:42 pm
TL;DR: ENISA’s SBOM Landscape Analysis frames SBOMs as a governance program, not a document exercise, and highlights scope, format, automation, validation, and monitoring choices that determine whether software transparency actually improves resilience, according to FOSSA. The core lesson is that SBOM maturity depends on lifecycle control, not one-time generation, especially where regulatory pressure and supply chain risk intersect.
NHIMG editorial — based on content published by FOSSA: ENISA’s SBOM Landscape Analysis and implementation guidance
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should organisations start an SBOM programme without overcomplicating it?
A: Start with why the SBOM exists, who owns it, and which systems matter most.
Q: When does an SBOM become useful for security teams?
A: An SBOM becomes useful when it drives workflow, not when it sits as a document.
Q: What do security teams get wrong about supplier SBOMs?
A: They often assume receipt equals assurance.
Practitioner guidance
- Define SBOM scope by asset class and dependency depth Start with customer-facing applications, then expand to internal systems, third-party dependencies, and runtime components.
- Automate SBOM generation at build time Trigger SBOM creation during CI/CD builds so the inventory reflects the code that is actually released.
- Validate and sign SBOM artifacts before distribution Check completeness, compare repeated builds for drift, and sign the resulting SBOM so consumers can verify integrity.
What's in the full article
FOSSA's full blog covers the operational detail this post intentionally leaves for the source:
- Side-by-side discussion of SPDX and CycloneDX tradeoffs for teams choosing an SBOM standard
- Page-level implementation guidance on SBOM generation, validation, signing, and storage workflows
- Practical examples of SBOM management across legacy systems, monorepos, and container environments
- Detailed discussion of legal and intellectual property concerns around SBOM distribution
👉 Read FOSSA’s analysis of ENISA’s SBOM implementation guide →
SBOM governance and compliance: what ENISA’s guide changes for teams?
Explore further
18/08/2026 3:26 pm
SBOM governance is now a software supply chain control, not a documentation exercise. ENISA’s guidance reflects a broader shift away from static inventory toward lifecycle governance. Once SBOMs are used for vulnerability response, procurement evidence, and regulatory reporting, they become control inputs that need ownership, validation, and distribution rules. Practitioners should treat SBOMs as governed security data, not passive files.
A question worth separating out:
Q: Which regulatory frameworks make SBOM governance a priority?
A: DORA and the CRA are the most visible drivers in Europe, but they are not the only reason to build SBOM governance. Organisations should align SBOM controls to compliance requirements only after they have built reliable generation, validation, and update processes. Regulatory evidence is far more credible when it comes from a living SBOM programme.
👉 Read our full editorial: ENISA’s SBOM guide turns software transparency into governance
