SBOM regulations are turning software transparency into a governed duty

At a glance

What this is: This is an analysis of how SBOM expectations are converging across regulations and what that means for software supply chain governance.

Why it matters: It matters because teams that treat SBOMs as static compliance documents will miss the operational controls needed to manage third-party software risk, auditability and remediation at scale.

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.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read FOSSA's webinar analysis of SBOM regulations and program maturity

Context

SBOM regulation is really a governance problem: organisations are being asked to show what software components exist, how they are maintained, and how they are handled when vulnerabilities emerge. The article frames this as a shift from static inventory thinking to continuous supply chain control, which is where compliance, security operations and procurement begin to overlap.

The primary SBOM challenge is not producing a list once. It is keeping component data current enough to support remediation, audit evidence and third-party risk management across software that changes constantly. That is a familiar pattern in identity governance too, where visibility without lifecycle control rarely survives contact with real operations.

For practitioners, the article is a useful map of how regulatory expectations differ in ambition, but it is not unusual in its core conclusion. Mature SBOM programmes look less like documentation projects and more like governed operational systems.

Key questions

Q: How should teams operationalise SBOMs instead of treating them as documents?

A: Treat SBOMs as living control data. Generate them automatically at build time, store them with version history, and connect them to vulnerability management, release approvals and supplier review. The test is whether the data can support patch decisions and audit evidence after the product changes, not whether it exists once in a repository.

Q: Why do SBOM requirements keep appearing in regulations and contracts?

A: Because software risk is now supply chain risk. Regulators and customers want evidence that organisations know what they ship, can trace third-party components, and can respond quickly when vulnerabilities emerge. SBOMs make that evidence machine-readable, which is essential when products, dependencies and suppliers change continuously.

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. When the software inventory drifts, teams waste time chasing false assumptions or miss affected applications entirely. That turns a useful control into a reporting artifact.

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.

Technical breakdown

Why SBOMs shifted from inventory to regulatory evidence

An SBOM is a structured record of software components, dependencies and related metadata that can be processed by tools rather than read only by people. Regulators and buyers increasingly care because that structure supports vulnerability correlation, supplier accountability and change tracking. A spreadsheet may satisfy a narrow audit question, but it does not scale to dependency analysis, deltas or automated remediation workflows. The regulatory trend is therefore not just about transparency. It is about proving that software composition is governable across the product lifecycle.

Practical implication: Practitioners should treat SBOM generation as part of software delivery and vulnerability management, not as a one-off compliance artefact.

How PCI DSS and DORA turn component visibility into operational control

PCI DSS Requirement 6 and DORA both push organisations toward knowing what is inside critical software and keeping that knowledge usable as systems change. The point is not merely to catalogue third-party code. It is to connect inventory data to patching, risk assessment and business-critical function scoping. DORA is especially explicit about operational resilience, while PCI ties the expectation to secure development and maintenance practices. Together they show that the control objective is lifecycle management, not document production.

Practical implication: Teams should link SBOM data to change management, patch workflows and supplier assurance for systems that support regulated or high-impact functions.

What CRA changes about software accountability in the market

The Cyber Resilience Act broadens the conversation beyond finance by attaching security expectations to digital products sold into Europe. That matters because it shifts SBOMs from a niche procurement request to part of market access and product assurance. CRA also reinforces vulnerability disclosure and component transparency as obligations rather than optional hygiene. For suppliers, this means the ability to prove composition and respond to vulnerabilities becomes a standing product requirement, not just an internal security preference.

Practical implication: Product and security teams should align SBOM processes with release governance, vulnerability disclosure and market-entry checks for European distribution.

Threat narrative

Attacker objective: Exploit ungoverned software components to gain a persistence or execution foothold in business-critical systems.

1. Entry begins when organisations ship or buy software without an accurate picture of third-party and open source components.
2. Escalation occurs when untracked dependencies inherit known vulnerabilities or unsupported versions that are difficult to prioritise and patch.
3. Impact is delayed remediation, audit findings and exposure to supply chain exploitation across regulated environments.

NHI Mgmt Group analysis

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.

Component transparency is becoming a market access requirement. CRA broadens the scope beyond sector-specific compliance and makes software composition a product accountability issue. That changes the buying conversation for security, compliance and procurement teams because suppliers will increasingly need to prove they can maintain component evidence over time. Practitioners should expect SBOM maturity to influence vendor selection and contract language.

Lifecycle maintenance is the real control gap. The article’s strongest point is that a static inventory can exist without helping anyone reduce risk. The named concept here is SBOM governance drift: the gap between creating component data and keeping it actionable as software changes. That drift is what weakens auditability, vulnerability response and third-party oversight. Practitioners should measure how quickly SBOM data becomes stale after release.

Regulatory ambition is outpacing many organisations’ operating model maturity. PCI, DORA and CRA differ in scope, but they all assume teams can operationalise component knowledge under pressure. That assumption fails when security, engineering and compliance work from separate inventories or inconsistent data formats. The result is not just slower remediation but weaker evidence during audit or incident response. Practitioners should align SBOMs with change control and supplier assurance.

Software supply chain governance and identity governance now share the same structural problem. Both depend on continuously maintained records that are only useful if they drive action. In identity, that means entitlement and credential lifecycle. In SBOM, it means component and vulnerability lifecycle. The cross-domain lesson is simple: visibility without enforced maintenance does not reduce risk. Practitioners should build lifecycle controls, not evidence repositories.

What this signals

SBOM programmes will increasingly be judged on how fast component evidence becomes operationally useful after release. The organisations that win here will be the ones that treat component inventory as governed data, not compliance packaging, and that connect it to change control, patching and supplier assurance.

SBOM governance drift: the gap between creating component data and keeping it actionable will become a recurring audit and resilience issue. Teams should expect regulators and customers to ask not only whether an SBOM exists, but whether it still matches the software in production.

For identity and NHI teams, the parallel is clear. Static records do not reduce risk if lifecycle control is missing. That is why governance models built around refresh cadence, ownership and exception handling will be more durable than document-first compliance approaches.

For practitioners

• 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.
• Set ownership for regulated product lines Assign named accountability for SBOM upkeep on products that fall under PCI DSS, DORA or CRA scope, including update cadence and exception handling.

Key takeaways

• SBOM regulation is converging on a single expectation: continuous, usable software component governance.
• The real risk is not missing documentation, but stale component data that cannot support remediation or audit.
• Practitioners should connect SBOMs to release control, vulnerability workflows and supplier accountability now.

Key terms

• SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• SBOM Governance Drift: SBOM governance drift is the gap between generating component data and keeping it accurate enough to support decisions. It usually appears when release cadence, dependency changes and remediation workflows outpace the organisation’s ability to refresh records and act on them.

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

👉 FOSSA's full webinar covers regulatory nuance, maturity stages and practitioner guidance in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle and secrets management for practitioners who need governed access control across complex environments. It is designed for teams building durable identity and security programmes, not one-off compliance artefacts.