SBOM governance is shifting from inventory to runtime risk control

At a glance

What this is: OXSecurity argues that SBOM programmes are becoming operational controls, with runtime awareness and drift detection replacing passive inventory as the core governance problem.

Why it matters: This matters because security and IAM-adjacent teams need to know not just what is declared in software supply chains, but what is actually active, reachable, and able to change risk at runtime.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

Context

A software bill of materials is a machine-readable inventory of components, libraries, and dependencies, but that inventory is only useful if it stays aligned with what actually runs. In modern software supply chains, the gap between declared components and deployed components creates blind spots for vulnerability management, third-party assurance, and runtime security.

For IAM and NHI practitioners, the analogy is direct: governance fails when the system of record is treated as the system of control. SBOM drift is the software-supply-chain version of stale identity inventory, where declared state looks clean while real execution paths expose different risk.

Key questions

Q: What fails when teams rely on SBOMs without runtime context?

A: Teams lose the ability to tell which dependencies are actually active, reachable, or exploitable. A build-time SBOM can be accurate and still misleading if the live environment has drifted through containers, conditional loading, or pipeline changes. The result is over-reporting of low-risk findings and under-prioritization of the dependencies that can truly affect production.

Q: Why does runtime visibility change SBOM risk decisions?

A: Runtime visibility separates components that exist on paper from components that are loaded, invoked, and reachable in practice. That matters because remediation capacity is limited, and teams need to spend it on weaknesses that can actually be exploited. Without runtime context, vulnerability management becomes noisy and less defensible.

Q: How should security teams prioritise SBOM findings across modern pipelines?

A: Prioritise findings by reachability, runtime presence, and business exposure rather than by the size of the dependency list. A reachable issue on a live path deserves more attention than a dormant package with no execution path. The goal is to turn SBOM data into a risk-ranking mechanism, not a reporting obligation.

Q: What should third-party software governance require beyond a dependency list?

A: Third-party governance should require evidence that supplier software is mapped from source to runtime and that the delivered components still match the declared inventory. That closes the assurance gap between what a vendor says is inside a package and what your environment actually executes. This is where SBOMs become operational rather than symbolic.

Technical breakdown

Static SBOMs vs dynamic SBOMs

A static SBOM captures dependencies at a single point in time, usually during build or release. That is useful for audit evidence, but it quickly becomes stale when packages are updated, services are redeployed, or transitive dependencies change. A dynamic SBOM is continuously refreshed across the SDLC so the inventory tracks current software composition instead of historical intent. The technical value is not the file itself but the control loop around it: discovery, reconciliation, and alerting when declared and deployed state diverge.

Practical implication: Treat SBOM generation as a continuous control, not a release artifact, so drift is detected before it becomes an exposure window.

SBOM drift detection and code-to-runtime mapping

SBOM drift occurs when the software running in production no longer matches the SBOM that was approved or reviewed. Code-to-runtime mapping closes that gap by tracing components from source control through build artifacts into executed workloads, so teams can see which libraries are loaded, invoked, or never actually used. That distinction matters because the presence of a vulnerable package is not the same as reachable exposure. Runtime awareness turns SBOMs from compliance records into decision data for prioritising remediation.

Practical implication: Correlate declared components with execution telemetry so remediation focuses on reachable software, not every listed dependency equally.

Reachability analysis for supply chain risk

Reachability analysis asks whether a vulnerable component can actually be triggered in the deployed environment. A package may appear in an SBOM yet remain inert if no code path calls it, while a smaller dependency can become the real risk if it sits on a live path. This shifts prioritisation from theoretical exposure to exploitable exposure. In practice, SBOM governance becomes a control for reducing alert fatigue and aligning vulnerability management with operational reality across CI/CD and runtime layers.

Practical implication: Use reachability and runtime context to rank SBOM findings, then feed only actionable issues into remediation workflows.

Threat narrative

Attacker objective: The objective is to exploit the gap between declared software inventory and runtime reality so vulnerable components remain unaddressed and usable in production.

1. Entry begins when open-source, proprietary, or third-party components are introduced into the software build or deployment chain without complete runtime reconciliation.
2. Escalation occurs when stale SBOM records hide what is actually loaded in production, allowing vulnerable or unwanted components to persist beyond the approved inventory.
3. Impact follows when security teams prioritise the wrong dependencies, leaving reachable weaknesses exposed across modern software supply chains.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime truth, not inventory truth, is now the control objective. SBOM programmes fail when they stop at component listing and never reconcile declared software with what is actually executing. That gap matters because modern supply chain attacks exploit stale assumptions, not just missing records. For practitioners, the governance question is whether the SBOM can answer reachability and runtime presence, not whether it can produce a spreadsheet.

SBOM drift is a governance failure mode, not a reporting defect. When the approved component set diverges from the deployed component set, the organisation loses decision quality at exactly the point where prioritisation matters. This is the same control logic that identity teams face when inventory and entitlements drift apart. Practitioners should treat drift as a live risk signal that changes remediation priority, not as an audit afterthought.

Reachability is the right filter for modern software risk. A vulnerability that exists on paper but cannot execute is not the same problem as one sitting on a live code path. The article’s shift toward runtime awareness is therefore more than operational tuning; it is a recognition that security teams need exposure context before they can assign effort. That makes runtime prioritisation a practical requirement for supply chain governance.

Software supply chain governance is converging with identity governance in structure, if not in subject. In both domains, the control failure is assuming the catalog is the control, when the real issue is whether the asset still matches reality at the point of use. For NHI and IAM teams, that parallel is useful because it reinforces a core lesson: inventories only matter when they are continuously reconciled against live state.

Code-to-runtime visibility should become a baseline expectation for SBOM programmes. The next phase of supply chain governance is not larger inventories but better linkage between source, build, deployment, and execution. That linkage is what allows teams to distinguish theoretical from active risk and to defend prioritisation decisions with evidence. Practitioners should demand that level of traceability before calling SBOM coverage complete.

From our research library:

• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: NHI Lifecycle Management Guide

What this signals

SBOM drift is becoming the supply-chain equivalent of identity inventory drift: the control fails when the record of what should exist is mistaken for what actually exists. Security teams need runtime reconciliation because component lists alone do not tell them which dependencies are active, reachable, or relevant to current exposure.

Visibility is the limiting factor in both software supply chains and identity programmes. Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs, and the same governance pattern appears in SBOM work when teams cannot link declarations to runtime state.

Code-to-runtime traceability should be treated as a baseline governance requirement, not an advanced feature. Once teams can trace components through build and execution, they can prioritise reachable issues, defend remediation choices, and reduce the risk of treating inventory as control.

For practitioners

• Embed SBOM generation into CI/CD Generate and refresh SBOMs as part of build and deployment workflows so the inventory reflects current components rather than a one-time snapshot.
• Reconcile declared and deployed state Compare approved SBOM content with runtime telemetry to find drift between what was packaged and what is actually executing in production.
• Prioritise by reachability, not count Rank SBOM findings by whether the vulnerable component is reachable or invoked in the live environment before opening remediation work.
• Extend third-party assurance to runtime evidence Require suppliers to provide not just component lists but evidence that mapped components are still present and relevant in delivered software.

Key takeaways

• SBOM programmes are moving beyond component listing toward runtime governance, where drift detection and reachability analysis determine which findings matter.
• The main control gap is the mismatch between declared software and executed software, which creates blind spots in supply chain risk management.
• Practitioners should connect SBOM data to CI/CD, runtime telemetry, and supplier evidence so prioritisation reflects active exposure rather than static inventory.

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.
• SBOM Drift: SBOM drift is the mismatch between the software that was declared at build time and the software that is actually running in production. It matters because change after release can introduce hidden exposure, stale inventory, and compliance gaps that a static document will not detect.
• 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.
• Code To Runtime Mapping: Code to runtime mapping links source artifacts, build outputs, and deployed workloads so security teams can trace a dependency from creation to execution. This gives context to SBOM data and helps teams understand where a risky component appears and how it is being used.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org resources that connect identity governance to the broader security disciplines your programme depends on.