TL;DR: SBOMs gave security teams visibility into software composition, but OXSecurity argues that static inventories cannot show which dependencies are actually executed, exposed, or exploitable across containers, APIs, pipelines, and AI-assisted development. The governance shift is from component counting to execution-aware risk control, because inventory without runtime context leaves supply-chain decisions structurally incomplete.
At a glance
What this is: This article argues that SBOMs are useful inventories but fail to show execution context, reachability, or runtime exposure, so they cannot by themselves reduce supply-chain risk.
Why it matters: It matters because IAM, NHI, and security teams increasingly need exposure-aware control over dependencies, pipelines, and service identities, not just component lists.
Context
SBOMs solve an inventory problem, not a governance problem. They tell teams what components were present at build time, but they do not tell teams which dependencies are actually executed, which paths are reachable, or which artifacts have drifted into a different runtime state. In fast-moving delivery environments, that gap matters because the security question is no longer simply what exists, but what is exposed and what can be abused.
The identity intersection is real here: pipelines, build artifacts, service accounts, API credentials, and container runtimes are all part of the control plane that determines whether a component can be used safely. Static software bills of materials are therefore incomplete when used alone for IAM, NHI, or application security governance. The article’s core point is typical of modern supply-chain programmes, not an edge case.
Key questions
Q: What breaks when SBOMs are used without execution lineage?
A: Static SBOMs break down when teams need to decide whether a dependency is actually reachable, executed, or exposed. A component can exist in the inventory yet never influence production risk, while a smaller dependency on a live API path may matter more. Execution lineage closes that governance gap by tying software composition to real runtime behaviour.
Q: Why do build-time inventories fail to control software supply chain risk?
A: Because the risk emerges after the build succeeds. Dependency changes, container mutations, and deployment shortcuts can all create divergence between the recorded bill of materials and the live environment. If policy is only applied at generation time, the organisation is governing a snapshot instead of the actual production workload.
Q: How should security teams decide which dependency updates to prioritise first?
A: Start with the vulnerabilities that affect reachable, internet-facing, or business-critical code paths, then move down by exploitability and blast radius. A dependency that is vulnerable in theory but unreachable in practice is not the same as one exposed in production. Prioritisation should follow runtime exposure, not package count.
Q: Should SBOM governance include CI/CD and runtime controls?
A: Yes. SBOM governance only becomes operational when CI/CD permissions, deployment context, and runtime behaviour are part of the same control model. Otherwise, teams know what was built but not what can actually be used or attacked in production.
Technical breakdown
Why build-time SBOMs miss runtime exposure
A build-time SBOM captures the dependency graph at a specific moment, usually when code is compiled or packaged. That snapshot does not reflect conditional loading, environment-specific configuration, or dependencies fetched later in runtime paths. In modern delivery pipelines, the same component may be present in multiple artifacts but only become reachable in one deployment context. That is why inventory alone cannot answer exploitability questions. The technical issue is not just completeness, but temporal mismatch between what was built and what is actually running.
Practical implication: correlate SBOM data with deployment and runtime signals before making risk decisions.
How execution lineage changes supply-chain governance
Execution lineage tracks how a dependency moves from source code into build artifacts, containers, APIs, and live runtime use. Unlike a static component list, lineage lets teams determine whether a package is merely present or actually part of an attack path. This is especially important in CI/CD systems, where transitive dependencies, inherited base-image layers, and AI-generated code can introduce components without clear human intent. The control question becomes reachability and usage, not just presence.
Practical implication: prioritise dependencies that are reachable, externally exposed, or attached to privileged execution paths.
Why APIs and pipelines are part of the same risk surface
SBOM programmes often separate application composition from delivery mechanics, but the article shows that separation no longer holds. Pipelines can inject or transform dependencies, APIs can expose them, and runtime behaviour can activate them. That means a dependency’s security relevance depends on how it is deployed and exposed, not just whether it appears in the inventory. For IAM and NHI teams, this also means service identities and pipeline permissions can amplify the impact of a weak component if they allow code or artifacts to move unchecked.
Practical implication: treat CI/CD permissions, API exposure, and artifact provenance as part of the dependency risk model.
Threat narrative
Attacker objective: The attacker’s objective is to exploit a dependency or delivery-path weakness that static SBOM review fails to prioritise correctly.
- Entry occurs through a trusted dependency, build artifact, or pipeline path that introduces software the inventory records but does not contextualise.
- Escalation happens when a reachable component, exposed API, or runtime-loaded library becomes available in production and can be exercised by an attacker.
- Impact is the abuse of an apparently known component that was not actually governed as part of the live attack path.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
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
Static inventories are not a control. SBOMs provide visibility into software composition, but visibility alone cannot tell teams whether a dependency is reachable, executed, or exposed in production. That makes component lists useful for audit evidence but incomplete for operational governance. Practitioners should treat inventory as an input to control decisions, not the control itself.
Execution lineage is the missing governance layer. The decisive question is not what is in the software, but what actually runs, where it runs, and what permissions make it reachable. That is why supply-chain risk becomes more actionable when build outputs, deployment targets, and runtime behaviour are evaluated together. The practitioner implication is to govern dependency risk as a live pathway problem, not a static catalogue problem.
Code, pipelines, and runtime now form one attack surface. The article correctly shows that modern software delivery collapses old boundaries between development, release, and operation. Once CI/CD systems, containers, and APIs all influence exposure, teams need governance that follows the artifact through its whole lifecycle. The practical conclusion is to evaluate supply-chain controls by exposure path, not by the number of components discovered.
AI-assisted development increases the gap between declared and actual software state. Non-deterministic generation, conditional loading, and rapid branch churn can introduce dependencies without a stable human approval trail. That means traditional review and inventory workflows can record a component without understanding its runtime significance. Teams should assume that any generated or dynamically introduced dependency needs separate reachability and provenance checks.
SBOM programmes need exposure-aware policy, not just reporting. The article’s strongest implication is that supply-chain governance fails when teams stop at compliance artefacts. An SBOM becomes useful only when it feeds decisions about privilege, reachability, and deployment context. Security leaders should judge their programmes by how quickly they can convert inventory into enforcement, not by how many files they can produce.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Execution lineage: security teams should start treating dependency governance as a live path problem, not a static inventory exercise. That means the control objective moves from counting components to proving whether a package is actually reachable in the deployed environment. For teams running pipelines and service identities, that is the difference between reporting and enforcement.
SBOM accuracy now depends on how well organisations connect source, build, artifact, and runtime context. Without that chain, teams can over-prioritise low-impact findings and miss the dependencies that are genuinely on an attack path. The practical signal is simple: if a component cannot be tied to execution, its security priority is probably overstated.
For practitioners
- Correlate SBOMs with runtime exposure Link dependency inventories to deployment state, API reachability, and runtime usage so you can separate present-from-used components from merely listed ones.
- Map dependencies to execution lineage Track how each dependency enters through source, build, artifact, and container stages so the team can see where risk is introduced and propagated.
- Prioritise reachable components over inventory volume Use reachability, public exposure, and privilege context to rank remediation, instead of treating every vulnerable package as equally urgent.
- Review CI/CD permissions as part of SBOM governance Check whether pipeline identities can modify artifacts, inject dependencies, or alter release paths, because that access determines whether an inventory entry becomes an exploitable path.
- Add policy gates for exposure-based release decisions Block or flag dependencies that are both vulnerable and reachable in production, so SBOM data drives enforcement before release rather than after detection.
Key takeaways
- SBOMs are useful for inventory, but they do not by themselves show which dependencies are executed, exposed, or exploitable.
- The real governance gap is execution lineage, which connects source, build, deployment, and runtime behaviour into one risk view.
- Teams that want supply-chain risk reduction need exposure-aware policy and CI/CD context, not just a longer component list.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0002; TA0006; TA0008 — Execution; Credential Access; Lateral Movement | The article discusses how trusted build and dependency paths become attack paths. |
| Recommendation — Map dependency and pipeline abuse to ATT&CK tactics and hunt for execution, credential, and lateral-movement indicators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Pipeline and runtime access determine whether dependencies become exploitable in production. |
| Recommendation — Apply PR.AA-05 to govern who and what can alter artifacts, dependencies, and deployment paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | CI/CD and service identities are part of the delivery surface described in the article. |
| Recommendation — Use CIS-5 to inventory and control accounts that can modify builds, artifacts, and deployment behaviour. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article ties dependency risk to exposed APIs and weak exposure context. |
| Recommendation — Apply API8 to reduce exposed attack paths created by misconfigured or overexposed services. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party package and pipeline trust is central to the supply-chain risk pattern here. |
| Recommendation — Treat third-party dependencies and pipeline identities as NHI trust relationships that need continuous review. | ||
Key terms
- Execution lineage: Execution lineage is the path that shows how a dependency moves from source code or build input into runtime use. It connects inventory to behavior, which is what security teams need when deciding whether a component is merely present or actually capable of creating risk.
- Embedded SBOM: An embedded software bill of materials lists the software components inside a firmware or device image. In practice, it only supports risk management when it is matched to the exact build and deployed version, so teams can tell what is present, vulnerable, and remediated.
- 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.
- Exposure-Aware Policy: Exposure-aware policy is a control approach that ranks software risk by how components are used, exposed, and privileged in production. It turns inventory data into enforcement by combining composition data with runtime and delivery context.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the contexts practitioners need to manage. It is designed for security teams building durable identity controls across modern delivery pipelines.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org