SBOMs expose risk, but remediation is the real security test

At a glance

What this is: This is an independent analysis of why SBOM programs often stop at inventory, even when most vulnerable components already have available fixes.

Why it matters: It matters because IAM-adjacent software governance, secrets handling, and identity-controlled delivery pipelines all depend on whether security teams can move from visibility to enforced remediation.

By the numbers:

• 94.9% of vulnerable components downloaded had a fixed, non-vulnerable version available.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Pixee's analysis of why SBOMs need a remediation layer

Context

Software bills of materials solve a visibility problem, not a security outcome problem. In practice, many teams can now identify vulnerable components quickly, but they still struggle to decide what is actually exploitable, what can be fixed safely, and what should be prioritised across a large dependency graph. That gap is especially relevant to identity-governed delivery pipelines, where access, secrets, and build integrity all depend on reliable remediation.

The article frames SBOMs as a necessary control that is increasingly being mistaken for a complete control. That is a common failure mode in mature programmes: inventory is treated as evidence of risk reduction even when the operational follow-through is weak. For identity and security leaders, the question is whether SBOMs feed governed remediation, or simply generate another compliance record.

Key questions

Q: Why do SBOMs fail as a standalone security control?

A: An SBOM shows what components are present, but not whether their vulnerabilities are exploitable or remediated. It is useful inventory, not risk closure. Organisations still need dispositioning, fix history, and support-period tracking to demonstrate continuous security rather than simply document what was shipped.

Q: Why do SBOM programs often miss the real risk signal?

A: They often miss the signal because most findings are not equally actionable. Some vulnerabilities sit in unreachable code, some have no safe upgrade path, and some are blocked by transitive dependency conflicts. Without filtering and ownership, teams spend time triaging noise instead of reducing exposure.

Q: How do security teams know whether an SBOM finding is actually urgent?

A: They should combine exploitability context, asset exposure, and business criticality rather than relying on severity scores alone. An SBOM item is urgent when it is both reachable and valuable to an attacker, not merely because it matches a CVE in a dependency list.

Q: Who is accountable when a vulnerable dependency stays unpatched?

A: Accountability should sit with the service owner, the platform owner, and the security function that approved the exception or missed the escalation. If remediation stalls, organisations should be able to identify whether the failure was due to ownership, tooling, testing, or privilege governance.

Technical breakdown

Why SBOM visibility does not equal exploitability control

An SBOM tells you what is present in a software artefact, but not whether a vulnerable component is reachable in your code path. That distinction matters because vulnerability databases often overstate practical exposure when the affected function is never called. Reachability analysis narrows the field by tracing actual code paths, while exploitability analysis asks whether the flaw can be triggered in the deployed context. Without those layers, teams create a high-volume triage queue that looks comprehensive but does not improve risk decisions.

Practical implication: pair SBOM ingestion with reachability and exploitability filtering before routing findings into remediation workflows.

How transitive dependencies turn patching into a governance problem

Most modern applications rely heavily on transitive dependencies, meaning the risky component is often several layers removed from the package a developer explicitly selected. That makes remediation a coordination problem across maintainers, build systems, test coverage, and release approvals. A patch may be technically available, but operationally blocked by compatibility constraints, downstream breakage, or missing verification gates. SBOMs reveal the dependency tree, but they do not resolve the decision chain required to change it safely.

Practical implication: treat transitive dependency updates as governed change events, not simple package bumps.

Why inventory-led compliance creates false confidence

Regulatory pressure has pushed organisations to generate SBOMs, but newer requirements increasingly expect proof of vulnerability handling, not just documentation. That changes the control objective from disclosure to action. When teams stop at producing the inventory, they satisfy the paperwork requirement while leaving the exposure unchanged. This is the same governance error seen in other security domains where evidence of monitoring is confused with evidence of control effectiveness.

Practical implication: measure remediation completion, not SBOM coverage, as the real control outcome.

Threat narrative

Attacker objective: Exploit unremediated vulnerable components before defenders convert SBOM visibility into effective patching.

1. Entry occurs when vulnerable software components are introduced or remain embedded in production builds despite SBOM visibility.
2. Escalation happens when teams assume inventory equals protection and fail to prioritise reachable or exploitable flaws.
3. Impact is prolonged exposure, delayed remediation, and continued use of known-vulnerable dependencies in live environments.

NHI Mgmt Group analysis

Inventory is not control. SBOM generation proves that an organisation can list software components, but it does not prove that risky components are reachable, exploitable, or remediated. That distinction matters because compliance programmes often reward documentation faster than they reward fix execution. Practitioners should treat SBOMs as input to governance, not evidence of protection.

Remediation latency is the real attack surface. The longer a vulnerable dependency remains deployed after discovery, the more the organisation depends on luck rather than control. In identity-governed delivery pipelines, that latency can also extend the lifetime of exposed secrets, build credentials, and deployment permissions. The practical test is whether the change workflow can move from detection to safe fix at machine speed.

Dependency transparency creates a new class of governance debt. The article names a problem that many teams already feel but rarely measure: the organisation can see more than it can safely change. That is governance debt, and it accumulates when SBOMs are not paired with reachability analysis, approval automation, and rollback discipline. Teams should judge themselves on the ratio of known exposure to actually closed exposure.

Identity controls sit underneath software supply chain remediation. Fixing vulnerable dependencies requires trusted build access, scoped automation tokens, and clear ownership of who can approve or block package changes. When those identities are over-privileged or poorly governed, remediation slows and exceptions proliferate. The implication for IAM and PAM teams is straightforward: supply chain security fails faster when privileged delivery identities are not tightly controlled.

SBOM maturity will be measured by closure, not disclosure. The market is moving from “show me the bill of materials” to “show me the closed findings.” That shift will reward organisations that can operationalise patch validation, exception handling, and attested remediation timelines. Practitioners should expect regulators and auditors to ask for proof that the inventory changed security outcomes, not just reporting volume.

What this signals

SBOM programmes are entering an accountability phase. The next maturity test is not whether teams can enumerate dependencies, but whether they can close findings quickly enough to matter. That will push many organisations toward tighter change controls, better ownership mapping, and more selective use of automated remediation.

Identity governance will matter more inside software supply chains than many security teams expect. Build systems, release pipelines, and fix automation all rely on privileged non-human identities, so poor credential governance can slow remediation even when the vulnerability is known. Teams that already manage secrets well will find it easier to convert SBOM visibility into enforceable action.

The practical shift is toward closure metrics and exception discipline. If your programme cannot prove which dependency risks were fixed, deferred, or formally accepted, it will struggle to satisfy both auditors and attackers. Use The State of Secrets in AppSec to benchmark how governance gaps show up in adjacent control domains.

For practitioners

• Measure remediation closure rate, not SBOM generation rate. Track the percentage of disclosed vulnerable components that are fixed, mitigated, or formally accepted within a defined window. If the closure rate is low, the programme is producing inventory without risk reduction.
• Add reachability analysis before ticket creation. Filter SBOM findings through code-path and exploitability checks so teams only open remediation work for issues that are actually reachable in the deployed application.
• Govern transitive dependency updates as controlled change. Require testing, rollback planning, and owner sign-off for dependency changes that cross package boundaries or affect multiple downstream services.
• Tie build and release permissions to least-privilege identities. Restrict who and what can approve package updates, push build artefacts, or alter dependency manifests so remediation is not slowed by uncontrolled automation or excess privilege.

Key takeaways

• SBOMs improve visibility, but visibility alone does not reduce exposure.
• The biggest failure is operational: teams know more about their dependencies than they can safely fix.
• Practitioners should measure remediation closure, reachability filtering, and privileged build governance as the real outcomes.

Key terms

• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• Remediation Closure: Remediation closure is the point at which a discovered access issue is actually fixed, not just logged. It matters because exposure only falls when stale accounts, excess permissions, or risky connectors are removed, justified, or re-scoped in the live environment.

What's in the full article

Pixee's full article covers the operational detail this post intentionally leaves for the source:

• The remediation decision logic behind when an SBOM finding should become a patch, an exception, or a monitored deferment.
• The practical criteria for evaluating fix tools, including transitive dependency handling, reachability filtering, and merge-rate expectations.
• The compliance implications of newer requirements that move from inventory disclosure to remediation evidence.
• The article's detailed breakdown of why automated remediation fails in legacy codebases, monorepos, and unsupported ecosystems.

👉 Pixee's full article covers the compliance shift from disclosure to remediation and the limits of fix automation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the operational realities of modern delivery pipelines.