Software supply chain risk needs SBOM visibility in modern pipelines

At a glance

What this is: This is a JupiterOne analysis of how SBOM visibility, dependency mapping, and EPSS scoring change software supply chain risk management.

Why it matters: It matters because security and IAM teams increasingly need trustworthy inventory and ownership data to triage exposed software, map blast radius, and connect component risk to operational accountability.

👉 Read JupiterOne's analysis of SBOM-driven software supply chain risk

Context

Software supply chain risk is no longer confined to source code review. It now extends to container images, transitive dependencies, and the speed at which teams can answer basic exposure questions when a vulnerability or malicious package lands in production.

For IAM and platform teams, the intersection is ownership and accountability. An SBOM is not identity governance in the strict sense, but it becomes an access and dependency control surface when teams need to know which service owns a component, where it is deployed, and who can act on it. That makes SBOM quality a practical part of broader security governance, not just a developer convenience.

Key questions

Q: How should security teams operationalise SBOMs in software delivery pipelines?

A: Security teams should generate SBOMs as part of build and registry workflows, then keep them searchable next to the images and components they describe. That makes inventory useful during triage, because responders can connect a vulnerable package to the right environment and owner without rebuilding the picture from scratch. Current, queryable data is the control objective.

Q: Why do transitive dependencies create more software supply chain risk than direct packages alone?

A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews. If defenders only track direct components, they can miss the code attackers are most likely to exploit. A dependency-aware inventory reduces that blind spot and gives teams a realistic view of what is actually present in production.

Q: How do teams know if SBOM-based prioritisation is working?

A: It is working when remediation queues track exploit likelihood, ownership, and deployment reach rather than just raw severity counts. If teams can consistently identify which vulnerable components are both present and likely to be targeted, they are using SBOM data for decision-making instead of filing it away as documentation.

Q: Who should own remediation when a vulnerable package appears across multiple environments?

A: Ownership should follow the service or platform team that can actually change the affected component, with security coordinating the risk decision and verification. SBOMs help by linking the package to owners and environments, which reduces the time lost to internal handoffs and makes accountability clearer.

Technical breakdown

SBOM visibility in the build and registry path

An SBOM is a machine-readable inventory of software components, including packages, images, and transitive dependencies. When generated at build time or scanned directly in registries, it gives security teams a current map of what exists before deployment drift makes the inventory stale. The main advantage is not paperwork. It is that the organisation can query exposure against living artefacts instead of reverse-engineering environments after an alert arrives. Practical teams should treat SBOM generation as part of the delivery pipeline, not a separate reporting task.

Practical implication: generate SBOMs where software is built or stored so the inventory stays current enough to support incident response.

Why transitive dependency mapping matters for software supply chain risk

Top-level package lists miss the hidden libraries that often carry the actual exposure. Transitive dependency mapping traces nested components all the way down the chain, so a vulnerable library buried several layers deep is still visible to defenders. This matters because attackers do not care whether the risky code is direct or indirect. If it is present in a shipped image, it is reachable somewhere in the estate. Security teams should therefore prioritise tools that preserve dependency relationships rather than flattening them into a simple bill of materials.

Practical implication: use dependency-aware inventory to find inherited exposure that basic package scans would miss.

EPSS versus CVSS for vulnerability prioritisation

CVSS measures severity, but not how likely a flaw is to be exploited right now. EPSS, the Exploit Prediction Scoring System, adds a probability lens by estimating the chance that a vulnerability will be used in the wild. For modern pipelines, that distinction is critical because thousands of findings can overwhelm responders if everything is treated as equally urgent. The operational win is a triage queue shaped by current exploitation risk, not just theoretical impact. That helps teams focus on vulnerable software that is both present and plausibly actionable by attackers.

Practical implication: pair SBOM data with exploit-likelihood scoring so remediation effort tracks real-world attack pressure.

Threat narrative

Attacker objective: The attacker objective is to exploit widely deployed software components before defenders can identify where the vulnerable package exists and who must fix it.

1. Entry occurs when attackers look for exposed packages, vulnerable libraries, or compromised dependencies inside software supply chains and registries.
2. Escalation follows when the vulnerable component is present in production images or transitive dependencies that defenders did not fully inventory.
3. Impact comes when teams cannot rapidly map the affected package to owners, environments, and blast radius, delaying containment and remediation.

NHI Mgmt Group analysis

Software supply chain visibility is now a governance problem, not just a DevSecOps concern. When teams cannot answer what is in a container image or which dependencies are deployed, they cannot govern exposure in a meaningful way. SBOMs become a control layer for accountability because they link software composition to operational ownership and remediation. Practitioners should treat inventory quality as part of risk governance, not as a compliance artefact.

Transitive dependency blindness creates hidden risk that attackers routinely exploit. Security programmes often focus on direct packages while ignoring the nested libraries that carry the real exposure. That gap matters because modern application risk is inherited as often as it is introduced. A precise dependency map is therefore a prerequisite for defensible triage and for any credible software supply chain control model.

Prioritisation must move beyond severity scoring alone. CVSS remains useful, but it is too static to govern fast-moving supply chain exposure on its own. EPSS-style likelihood signals help identify which vulnerable components are most likely to be targeted in the wild, which is a better fit for crowded remediation queues. Practitioners should align remediation policy to exploitability, not just to headline severity.

SBOMs create a practical ownership bridge between engineering and security operations. The value is not merely knowing what exists, but knowing who owns it, where it runs, and how quickly it can be fixed. That bridge matters when a vulnerable package appears in multiple environments and teams need a coordinated response. Security leaders should use SBOM workflows to reduce handoff delays and sharpen accountability.

Software inventory is becoming part of the identity of the application estate. In mixed environments, asset ownership, deployment location, and dependency lineage are the evidence needed to make control decisions. That makes SBOMs adjacent to broader governance disciplines, including IAM and access review, because response depends on knowing which teams can act on which systems. Practitioners should connect software inventory to ownership and access workflows, not leave it isolated in a tooling silo.

What this signals

Dependency inventory is becoming a governance signal. As software estates grow more dynamic, teams will be judged less on whether they have an SBOM and more on whether they can query it fast enough to support response. The programme signal is clear: make component ownership, deployment location, and exploitability visible in the same workflow.

The next maturity step is connecting inventory to action. If security teams still rely on static exports, spreadsheets, or delayed reporting, they will continue to absorb the same time cost during every major dependency event, which is exactly when attackers benefit from confusion.

For practitioners

• Generate SBOMs at build and registry time Produce SBOMs where software is created or stored so the inventory reflects what is actually deployable, not a stale post-hoc snapshot. Keep the output queryable alongside images and environments so responders can trace exposure quickly.
• Track transitive dependencies as first-class risk items Do not limit review to direct packages. Preserve nested dependency relationships so a vulnerable library buried several layers deep still appears in search and reporting workflows.
• Prioritise by exploitability, not severity alone Use EPSS or a similar likelihood signal alongside SBOM findings to rank remediation by real-world attack pressure. This helps teams avoid treating all critical-looking findings as equally urgent.
• Map vulnerable components to owners and environments Make sure every high-risk package can be traced to a service owner, production environment, and response path. That ownership mapping shortens triage and reduces time lost to internal discovery.
• Automate production-first coverage Start with the workloads that matter most, then extend coverage across registries and build pipelines so no critical image depends on manual review or spreadsheet tracking.

Key takeaways

• Software supply chain risk is increasingly about inventory quality, not just vulnerability count.
• SBOMs become materially useful when they are current, queryable, and linked to ownership and deployment context.
• Exploitability-aware prioritisation helps teams focus remediation on the components attackers are most likely to use.

Key terms

• Software Bill Of Materials: A Software Bill of Materials is a structured inventory of the components that make up an application or container image. It lists packages, versions, and dependency relationships so teams can identify exposure, track ownership, and respond quickly when a vulnerable library appears in production.
• Transitive Dependency: A transitive dependency is a component pulled in indirectly by another package rather than chosen explicitly by the development team. These hidden layers often carry the highest risk because they can introduce vulnerabilities that are easy to miss in manual reviews but still end up in shipped software.
• Exploit Prediction Scoring System: Exploit Prediction Scoring System, or EPSS, estimates how likely a vulnerability is to be exploited in the wild. It adds a probability lens to severity scoring, helping defenders prioritise fixes based on attack likelihood instead of treating every serious vulnerability as equally urgent.
• Dependency Visibility: Dependency visibility is the ability to see every package, library, and nested component that exists in a software artefact. It is a practical control because security teams cannot remediate what they cannot locate, especially when vulnerable code sits several layers deep in the supply chain.

What's in the full article

JupiterOne's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step SBOM workflow examples for registry-scanned container images and connected GitHub sources
• Query logic for finding vulnerable components, affected images, owners, and environments in one pass
• Practical guidance on using EPSS data to rank remediation across crowded vulnerability queues
• Implementation guidance for keeping SBOMs current with every build instead of relying on manual refreshes

👉 JupiterOne's full post covers registry scanning, dependency visibility, and EPSS-based prioritisation detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners responsible for identity risk. It gives security teams a structured way to connect identity controls to broader security operations and governance.