Notifications
Clear all
Topic starter
18/08/2026 2:37 pm
TL;DR: SBOM regulation is moving from abstract policy to enforceable operational expectation, with PCI DSS, DORA, CRA and SEBI all pushing organisations toward maintained component visibility, vulnerability handling and machine-readable inventory workflows, according to FOSSA. The real shift is away from one-time compliance artefacts toward continuous software supply chain governance that can survive audit, patching and supplier scrutiny.
NHIMG editorial — based on content published by FOSSA: a webinar analysis of SBOM regulations and program maturity
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should teams operationalise SBOMs instead of treating them as documents?
A: Treat SBOMs as living control data.
Q: Why do SBOM requirements keep appearing in regulations and contracts?
A: Because software risk is now supply chain risk.
Q: What breaks when SBOMs are not kept current?
A: An outdated SBOM weakens vulnerability triage, supplier review, and incident response because it no longer reflects what is actually deployed.
Practitioner guidance
- Tie SBOMs to release governance Require every build and release to produce machine-readable component data that is versioned, stored and diffed against the previous release.
- Connect inventory to remediation workflows Link SBOM findings to vulnerability management so that component exposure, patch priority and exception approval follow one controlled process.
- Separate compliance evidence from operational truth Keep the audit artefact, the engineering source data and the supplier attestation aligned, but do not rely on a PDF as the system of record.
What's in the full article
FOSSA's full webinar covers the regulatory context and program maturity detail this post intentionally leaves at a higher level:
- Stage-by-stage SBOM maturity guidance for financial services teams moving from inventory creation to operational governance
- Regulation-specific differences across PCI DSS, DORA, CRA and SEBI that affect evidence, scope and maintenance
- Practical discussion of why machine-readable SBOM data matters for patching, audit support and supplier oversight
- Context from the webinar on how practitioners should think about program baselines versus target-state maturity
👉 Read FOSSA's webinar analysis of SBOM regulations and program maturity →
SBOM regulations and the governance gap teams are still missing?
Explore further
18/08/2026 3:22 pm
SBOM maturity is now a governance discipline, not a documentation exercise. The article correctly shows that multiple regulatory regimes are converging on the same operational expectation: know what is in your software and keep that knowledge current. That is the same pattern identity teams see when inventories are detached from lifecycle controls. For practitioners, the lesson is that SBOMs must be governed like access and secrets data, with ownership, refresh cadence and escalation paths.
A question worth separating out:
Q: Who is accountable when an SBOM gap causes exposure in a regulated product?
A: Accountability should sit with product and security owners together, because SBOM gaps usually arise where engineering release practices and compliance evidence diverge. For regulated products, the organisation must be able to show who owns the data, who approves exceptions, and who is responsible for updates when dependencies change.
👉 Read our full editorial: SBOM regulations are turning software transparency into a governed duty
