Transitive dependency risk exposes the software supply chain blind spot

At a glance

What this is: This is an analysis of transitive dependency risk in software supply chains, with the central finding that direct-dependency scanning misses most exposure hidden in recursive package trees.

Why it matters: It matters because DevSecOps and security teams need complete dependency visibility, not just cleaner scan dashboards, to govern inherited risk and prioritise what is actually reachable.

By the numbers:

• According to Endor Labs research cited by Kusari, roughly 95% of open-source vulnerabilities reside in transitive dependencies rather than directly declared packages.

Context

Transitive dependency risk is the gap between what teams think they have scanned and what actually ships in production. When tools stop at direct dependencies, the resulting view of risk is incomplete because the full software bill of materials includes inherited components several layers deep.

That gap matters for software supply chain governance because hidden packages can introduce exploitable flaws, compliance blind spots, and noisy remediation queues. The identity angle is indirect but real: build pipelines, package registries, and dependency owners act as control points for who can introduce and inherit software trust.

Most organisations still treat dependency scanning as a point-in-time hygiene check rather than a continuously governed lifecycle. That starting position is common, but it is no longer adequate when transitive exposure dominates the real attack surface.

Key questions

Q: What breaks when transitive dependencies are not fully inventoried?

A: Teams lose sight of the software they actually ship. Direct-dependency scanning can look clean while inherited packages introduce vulnerable code, untracked compliance gaps, and delayed incident response when exposure is discovered later. The practical failure is not just missing one flaw. It is operating with an incomplete trust map for the entire application.

Q: Why do transitive dependencies create more remediation complexity in application security programs?

A: Transitive dependencies complicate remediation because the vulnerable code is not always imported directly by the application. Teams may need to inspect several layers of packages, identify the direct dependency that introduced the risk, and determine whether upgrading or replacing that parent package will remove exposure. Without that context, prioritization becomes manual, slow, and error prone.

Q: How do you know if dependency governance is actually working?

A: You know it is working when risky upgrades are caught before deployment, automated changes correlate with successful tests, and engineering teams stop discovering hidden breakage only after release. Strong governance produces fewer surprise failures and more predictable upgrade decisions across the software supply chain.

Q: Should teams prioritise recursive SBOMs before automated remediation?

A: Yes, because automation built on an incomplete inventory simply accelerates bad decisions. A recursive SBOM establishes the software truth set, while remediation automation acts on that truth. Without the complete graph first, teams may patch the wrong packages or miss transitive exposure entirely.

Technical breakdown

Why direct-dependency scanning misses the real attack surface

Direct dependencies are the packages developers intentionally declare, but modern applications resolve many more components through those packages. Each nested layer adds new code, new maintainers, and new trust relationships that standard Software Composition Analysis often does not model well. The result is a shallow inventory that looks complete on the dashboard while leaving the actual runtime composition partially unknown. In software supply chain terms, the issue is not just vulnerability detection. It is whether the organisation can reconstruct the full dependency graph with enough fidelity to understand inherited exposure.

Practical implication: Treat dependency visibility as a graph problem, not a manifest-file problem, and require recursive resolution for every build.

Why recursive SBOMs and reachability analysis belong together

A complete SBOM is necessary because it records the full set of components in the dependency tree, including transitive ones. But completeness alone is not enough, because not every vulnerable package is reachable from application code at runtime. Reachability analysis adds the missing context by checking whether a vulnerable function is actually invoked. That combination reduces false positives, improves prioritisation, and stops teams from spending time on flaws that exist only in theory. It also turns SBOMs from compliance artefacts into operational decision tools.

Practical implication: Pair recursive SBOM generation with reachability checks before assigning remediation priority.

How blast radius changes transitive risk prioritisation

The most useful transitive dependency programmes do not rank findings by CVSS alone. They weigh reachability, exploitability signals such as EPSS, and exposure indicators such as KEV to estimate blast radius. That matters because a critical issue in an unreachable library may be less urgent than a moderate flaw in a widely invoked component. This is a governance problem as much as a technical one: without ownership, continuous monitoring, and agreed escalation rules, dependency risk becomes a recurring firefight instead of a managed control domain.

Practical implication: Build prioritisation rules that combine exploitability, reachability, and business exposure before opening remediation work.

Threat narrative

Attacker objective: Exploit inherited trust in nested dependencies to introduce or activate vulnerable code inside production software without immediate detection.

1. Entry occurs through a transitive component that is pulled into the application without being explicitly chosen or reviewed by developers.
2. Credential or code abuse is enabled when an upstream package or maintainer compromise lands inside a nested dependency chain that ordinary scans do not fully inspect.
3. Impact follows when teams cannot quickly prove whether the vulnerable path is reachable, delaying containment and leaving hidden software supply chain exposure in production.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.

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

Transitive dependency visibility is now a supply chain governance problem, not a tooling gap. The article shows that scanning direct dependencies leaves most inherited risk outside the control boundary. In practice, the failure is not the absence of alerts but the absence of a complete object model for what the software actually contains. Practitioners should treat recursive dependency inventory as a governance control, not an optional enhancement.

Recursive SBOM accuracy is the named control gap behind this blind spot. A flat bill of materials tells you what was declared, while a recursive SBOM tells you what was actually inherited through resolution chains. That distinction matters because compliance checks built on incomplete inventories create false confidence. Practitioners should require dependency records that map the full graph, not just the top level.

Reachability analysis changes vulnerability management from enumeration to exposure assessment. The article makes clear that raw SCA output is too noisy to guide remediation on its own. When a vulnerable function is not invoked, the issue is different from an active runtime path that can be exploited immediately. Practitioners should use reachability to separate theoretical inventory risk from executable attack surface.

Software supply chain teams need blast-radius thinking, not CVE counting. Transitive risk becomes operationally meaningful only when organisations know which inherited components are reachable, who owns them, and how quickly they can be updated. That moves the discipline toward continuous assurance across build systems, package managers, and release pipelines. Practitioners should align dependency governance with actual exposure rather than severity scores alone.

Ownership across DevSecOps is the overlooked control in transitive dependency management. The article points to frequent checks and continuous monitoring as differentiators, but those only work when accountability is explicit. In mature programmes, developers, security teams, and platform owners share a dependency hygiene model instead of treating it as a one-time scan result. Practitioners should define ownership for inherited components before the next vulnerability lands.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Recursive dependency visibility will become a baseline expectation for software supply chain programmes. Teams that still rely on manifest-level scanning will keep discovering that their clean dashboards do not match runtime reality. The operational shift is toward dependency governance at build time, where inherited risk is identified before it lands in release artefacts.

Transitive dependency risk is also an identity and trust problem in the supply chain. Package registries, maintainers, and build pipelines all act as trust intermediaries, which means ownership and provenance matter as much as vulnerability counts. Security teams should align dependency controls with supply chain trust boundaries, not only with traditional application security checks.

Blast-radius prioritisation is the practical response to software supply chain noise. A transitive vulnerability that is unreachable and isolated is not the same as one that is invoked in a high-value path. Programmes that combine recursive SBOMs, reachability, and exploitability signals will spend less time chasing false urgency and more time containing real exposure.

For practitioners

• Generate recursive SBOMs for every build Capture the full dependency graph, including nested packages inherited through package manager resolution, so the inventory matches what ships to production.
• Add reachability analysis to SCA triage Check whether a vulnerable function is actually invoked by application code before escalating remediation, especially for deeply nested libraries.
• Prioritise by blast radius, EPSS, and KEV Use exploitability and exposure context to decide what gets fixed first, instead of treating every flagged transitive component as equally urgent.
• Assign ownership for inherited dependencies Make DevSecOps teams responsible for named dependency domains so transitive findings do not fall between platform, application, and security ownership.
• Monitor dependency graphs continuously Re-run dependency resolution on pull requests and release changes so newly disclosed transitive vulnerabilities are detected close to introduction.

Key takeaways

• Transitive dependency blind spots can make a clean scan misleading because the majority of inherited risk sits beyond direct package lists.
• The most defensible response is recursive SBOM coverage paired with reachability analysis, so teams can separate true exposure from inventory noise.
• Mature software supply chain governance depends on continuous monitoring, explicit ownership, and prioritisation by blast radius rather than CVSS alone.

Key terms

• 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.
• 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.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It is designed for practitioners who need stronger identity control across the systems and pipelines their programmes depend on.