TL;DR: SBOMs are becoming operational controls rather than compliance artefacts, according to JupiterOne, because deep dependency visibility, in-place scanning, and EPSS-based prioritisation can cut investigation time from hours to seconds when packages like log4j-core appear in production. The real shift is that software supply chain governance now depends on searchable, current inventory, not static documentation.
At a glance
What this is: This is an analysis of how SBOMs in modern pipelines move software supply chain risk management from static documentation to searchable operational control.
Why it matters: It matters because security, platform, and IAM teams increasingly need inventory, ownership, and prioritisation data that can support fast remediation across build and runtime environments.
Context
Software bill of materials programs only become useful when they are current, searchable, and connected to operational workflows. A static inventory does not tell teams which container images, packages, or transitive dependencies are actually live in production, so triage still depends on manual correlation.
The governance gap is visibility across the software supply chain, not the absence of documentation. Where application delivery depends on registries, CI/CD, and third-party packages, the control problem becomes one of knowing what exists, where it runs, and who owns it before a vulnerability turns into an incident.
Key questions
Q: How should organisations use SBOMs to improve software supply chain governance?
A: Treat SBOMs as a live control input. Connect them to vulnerability management, licence review, build approvals, and supplier assurance so they drive action across the product lifecycle. That approach turns inventory into governance and exposes where third-party dependencies create unacceptable risk.
Q: Why do transitive dependencies create more exposure than top-level package scans show?
A: Transitive dependencies often carry the vulnerable code that defenders do not see in a simple package list. If inventory stops at the first layer, teams miss the component actually pulled into production through a chain of other packages. Deep dependency mapping closes that gap and makes risk decisions based on what is truly in use.
Q: What are the signs that SBOM data is too stale to support response?
A: The warning signs are manual lookup, unclear ownership, and long delays when a vulnerability appears in a commonly used component. If teams still have to dig through spreadsheets or repos to find affected images and environments, the SBOM is not operational enough to support incident response or prioritisation.
Q: Should organisations prioritise EPSS or CVSS when fixing supply chain vulnerabilities?
A: They should use both, but not as equals. CVSS tells you how severe a flaw may be, while EPSS helps identify what is most likely to be exploited soon. In a crowded dependency estate, exploit likelihood is often the better trigger for first-line remediation, especially when exposure spans multiple images and modules.
Technical breakdown
Why pipeline-native SBOMs matter for inventory control
An SBOM is only operational when it reflects the software actually moving through build and deployment systems. That means the inventory must include container images, packages, and transitive dependencies, not just top-level components. When SBOM data is tied to connected registries and updated as builds change, teams can answer exposure questions without leaving the pipeline. That turns dependency knowledge into a live control surface instead of a document produced for audit season.
Practical implication: treat SBOM generation as a pipeline control, not a reporting task.
How deep dependency visibility changes vulnerability triage
Top-level package scanning misses the hidden dependencies that often carry the exploitable risk. Deep dependency mapping links a vulnerable library to the images, modules, and environments that consume it, which is what makes response efficient. EPSS adds a second layer by ranking what is most likely to be exploited in the wild, so teams are not forced to rely on CVSS alone for prioritisation.
Practical implication: connect dependency maps to prioritisation signals so remediation starts with the most exploitable exposure.
What in-place registry scanning changes about software supply chain trust
Scanning in place avoids shipping code or images to a third party just to analyse them, which reduces an avoidable exposure path. In supply chain terms, that keeps the inspection step close to the source of truth and preserves provenance context. It also fits better with high-velocity delivery, where security checks have to keep pace with frequent builds and registry updates.
Practical implication: prefer source-adjacent inspection models that minimise movement of build artefacts and preserve delivery speed.
Threat narrative
Attacker objective: Exploit hidden or untracked software dependencies before defenders can identify where the vulnerable component is running.
- Entry occurs through packages, images, and transitive dependencies that enter the pipeline as ordinary build inputs but may contain unknown or vulnerable code.
- Credential or control loss is not the main mechanism here; the risk comes from incomplete inventory and delayed visibility that leave attackers' dependencies undiscovered.
- Impact is delayed remediation, longer exposure windows, and slower containment when vulnerable components are already present in production.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
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
SBOM visibility is now a control problem, not a documentation problem. The important question is no longer whether teams can generate a list of components, but whether that list stays connected to live registries, build outputs, and ownership data. Static inventories do not support fast decisions when a dependency vulnerability drops into production. Practitioners should treat SBOM data as a governed operational asset, not a compliance attachment.
Dependency blind spots create the same governance failure that identity sprawl does in IAM. When teams cannot trace what is running, who owns it, and which transitive packages are present, they lose the ability to scope exposure quickly. That is especially relevant in modern pipelines where software supply chain risk behaves like an inventory and lifecycle problem, not only a vulnerability management problem. The lesson for security programmes is to collapse discovery and response into one control plane.
Pipeline-native inventory: this article points to a useful concept for practitioners, where SBOM generation, registry scanning, and prioritisation are bound to delivery rather than bolted on after release. That model reduces the gap between build-time truth and runtime risk. For teams managing software supply chain exposure, the control objective is to keep component knowledge current enough to drive action.
EPSS-backed triage is more useful than pure severity scoring for supply chain response. CVSS describes potential severity, but supply chain teams need to know what is likely to be exploited first. Prioritisation becomes a governance decision about where to spend scarce remediation time, especially when transitive dependencies multiply exposure. Security teams should align vulnerability response to exploit likelihood, not just to score inflation.
Modern pipeline security increasingly depends on searchable ownership, not just package detection. Knowing that a vulnerable library exists is only the first step. Teams still need to know which images, environments, and owners are attached so they can route remediation without delay. Practitioners should make ownership and environment mapping part of the SBOM workflow itself, or the inventory will not translate into control.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Software supply chain visibility fails when inventory is detached from delivery. SBOMs only change security outcomes when they remain current across every build and registry, otherwise teams are still responding to stale component data. The practical shift is from paper inventory to governed runtime truth, which is the only state that supports fast containment.
Deep dependency mapping is the difference between seeing a package and understanding exposure. If security teams can trace transitive dependencies to owned images and environments, they can cut response time dramatically. That is the governance lesson for practitioners: detection is not enough unless it resolves to accountable remediation.
EPSS makes the control more operational by turning vulnerability response into an exploit-likelihood decision. When teams are flooded with findings, prioritisation has to reflect what attackers are most likely to use first, not just what scores highest on paper. For supply chain programmes, that means integrating inventory, ownership, and exploitability into one workflow.
For practitioners
- Implement SBOM generation in CI/CD Generate SBOMs as part of the build so every release produces an updated inventory of images, packages, and transitive dependencies.
- Scan registry images in place Point scanning to connected registries and inspect images where they already live, rather than exporting artefacts into separate analysis workflows.
- Map transitive dependencies to owners Link code modules and container images to the teams and environments that run them so response does not stall at discovery.
- Use EPSS in prioritisation workflows Combine exploit likelihood with inventory data so remediation focuses on packages and images most likely to be targeted first.
- Start with production workloads Prioritise the most critical production images first, then expand coverage so the highest-impact exposure is addressed before broadening scope.
Key takeaways
- Software supply chain risk becomes harder to control when teams cannot see transitive dependencies inside the images and packages they deploy.
- The most useful SBOMs are current, searchable, and tied to ownership, registry data, and exploit-prioritisation signals.
- Practitioners should move SBOM generation into CI/CD and use it to drive faster triage, not just satisfy audit requirements.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0009;TA0010 — Collection; Exfiltration | Supply chain compromise often exposes software artefacts and dependency data before defenders can react. |
| Recommendation — Map supply chain findings to collection and exfiltration paths, then hunt for exposed build artefacts and dependency leakage. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | The article is fundamentally about keeping a live inventory of software components and environments. |
| Recommendation — Extend inventory discipline to software artefacts so SBOM data stays current and actionable across the pipeline. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | SBOM visibility is an application of software asset inventory and control in delivery pipelines. |
| Recommendation — Use software asset inventory controls to maintain a searchable SBOM for every build and release. | ||
| SLSA | L2 — Build integrity | The article emphasises keeping supply chain inspection close to the source and tied to build provenance. |
| Recommendation — Adopt build provenance controls so dependency visibility is coupled to trusted software delivery. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The core failure is losing track of what components and environments are actually present. |
| Recommendation — Apply inventory management discipline to the software supply chain so hidden dependencies are not missed. | ||
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.
- 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.
- Exploit Prediction Scoring System: A daily-updated score that estimates the likelihood a vulnerability will be exploited in the near term. It does not replace severity scoring, but it adds probability context that helps teams order work before exploitation becomes widespread.
- 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.
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 for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org