The 95% Problem: Why Transitive Dependencies Are Your Biggest Software Supply Chain Blind Spot in 2026

Your security team just finished a vulnerability scan. The dashboard looks clean—direct dependencies patched, known CVEs addressed, compliance boxes checked. But there's a catch: that scan only covered about 5% of your actual risk surface.

Key Insights

• The 95% Transitive Dependency Problem: The overwhelming majority (approximately 95% of open-source vulnerabilities) do not reside in a project's direct dependencies, but in the transitive dependencies (indirect components) they pull in. This creates the single largest software supply chain blind spot for organizations relying on surface-level scanning.
• Visibility Gap is the Core Risk: Traditional Software Composition Analysis (SCA) tools often fail to provide adequate visibility into deeper dependency layers. A typical enterprise application may have only dozens of direct dependencies but hundreds or thousands of invisible transitive components, drastically expanding the attack surface and leading to remediation efforts described as a "whack-a-mole" scenario.
• Complete SBOMs are Non-Negotiable: Effective transitive dependency vulnerability management must start with generating a complete, recursive Software Bill of Materials (SBOM). An accurate SBOM must capture every component in the full dependency graph, not just the top-level packages, to prevent compliance gaps and untracked inherited risk.
• Contextual Analysis for Prioritization: To overcome alert fatigue, security teams must move beyond raw SCA output and implement reachability analysis. This capability determines if a vulnerable function is actually invoked by the application's code, allowing for contextual risk assessment and helping teams prioritize remediation based on blast radius and exploit probability (leveraging data like EPSS and KEV) rather than just a high CVSS score.
• Shift to Proactive Governance: Mature software supply chain security requires continuous, automated monitoring of the dependency graph and clear ownership across DevSecOps teams. This proactive approach shifts the security posture from simply firefighting inherited risks to informed governance, enabling organizations to catch newly disclosed transitive dependency vulnerabilities closer to the point of introduction.
• Kusari’s Solution for Deep Visibility: Platforms like Kusari, which maintain the GUAC (Graph for Understanding Artifact Composition), are essential for gaining actionable visibility into deeply nested dependencies. They automatically map complex relationships, apply reachability analysis, and provide the business context needed to effectively remediate exposure within the modern software supply chain.

‍

Transitive dependency vulnerabilities are security flaws that live in the indirect components your software inherits through its direct dependencies. They sit two, three, or ten layers deep in your dependency graph, and most organizations have almost no visibility into them. According to research from Endor Labs, roughly 95% of open-source vulnerabilities reside in these transitive components—not in the packages your developers deliberately selected.

This article explains what transitive dependency vulnerabilities are, why they represent the single largest blind spot in modern software supply chains, how to detect and prioritize them, and what practical steps DevSecOps teams can take to close the gap. It is written for CISOs, security engineers, and DevSecOps leads at mid-sized organizations who need to move beyond surface-level scanning and build real supply chain visibility.

‍

What Are Transitive Dependencies, and Why Do They Create Security Blind Spots?

A transitive dependency is any software component that your application inherits indirectly. When your project depends on Library A, and Library A depends on Library B, which in turn depends on Library C—Libraries B and C are transitive dependencies. Your developers never chose them. They may not even know they exist.

This distinction matters because modern applications are mostly assembled rather than written from scratch. A typical enterprise project might declare 20 or 30 direct dependencies, but the full dependency graph can easily contain hundreds or even thousands of transitive components. One Kusari customer, for example, discovered over 18,000 components in their dependency tree after tracking only direct dependencies.

The problem compounds quickly. Each transitive layer inherits its own dependencies, creating a deeply nested structure that expands your attack surface in ways traditional scanning tools rarely capture. This is what the industry calls indirect dependency security—and it's where most hidden vulnerabilities actually live.

‍

The Visibility Gap: Most Teams Can't See Their Real Attack Surface

Survey data from Kusari's Application Security in Practice report paints a stark picture. Only 28% of respondents said they had strong insight into their deeper transitive dependency layers. Meanwhile, 56% reported being "highly aware" of their direct dependencies. That's a massive awareness gap between what teams think they control and what actually runs in production.

This gap creates what practitioners often describe as a "whack-a-mole" scenario. A team remediates a vulnerability in one component, only to discover that the same flaw (or a related one) surfaces again through a different transitive path they didn't know about. Without a complete dependency graph, remediation becomes an endless game of chasing symptoms instead of root causes.

The consequences are measurable. According to the same report, nearly half of teams (47%) spend more than five hours per week responding to and remediating software supply chain security issues. That's developer time diverted from building features—spent instead on firefighting problems that could have been prevented with better visibility.

‍

Why Traditional SCA Tools Miss Transitive Dependency Vulnerabilities

Software Composition Analysis (SCA) tools have been the default approach to dependency security for years. They scan your project manifest files, cross-reference known vulnerabilities in databases like the CVE or National Vulnerability Database (NVD), and flag matches.

The limitation? Most SCA tools focus primarily on direct dependencies—the packages explicitly declared in your package.json, pom.xml, or requirements.txt. They may list transitive components, but they rarely provide the context needed to act on them. Which transitive paths actually lead to your application's runtime? Is a flagged vulnerability even reachable through your code? What's the blast radius if it's exploited?

Without reachability analysis, SCA tools generate noise. They report vulnerabilities that may exist in your dependency tree but can't tell you whether those flaws are actually exploitable in your specific context. This leads to alert fatigue—security teams drowning in findings they can't prioritize, and developers losing trust in the tooling altogether.

What organizations need is not just detection but a remediation workflow that accounts for the full dependency graph, assesses actual exposure, and helps teams focus on what matters. That shift—from raw scanning to contextual risk analysis—is where transitive dependency vulnerability management starts to mature.

‍

How Supply Chain Blind Spots Turn Into Real-World Breaches

The Log4Shell vulnerability (CVE-2021-44228) remains the textbook case for transitive dependency risk. Log4j, a widely used Java logging library, was rarely declared as a direct dependency. Instead, it was pulled in transitively through frameworks like Apache Struts, Spring Boot, and dozens of other libraries. When the critical flaw was disclosed in December 2021, organizations scrambled to determine whether they were even exposed—many couldn't answer that question for days or weeks.

More recently, the xz Utils backdoor (CVE-2024-3094) revealed how a compromised maintainer could inject malicious code into a deeply nested component. The attack targeted a compression library that most developers would never interact with directly but that sat in the transitive dependency chain of critical Linux distributions.

These aren't isolated events. The pattern is consistent: attackers target components that are widely used but poorly monitored. Transitive dependencies are ideal targets precisely because they exist in the supply chain blind spots that most organizations haven't addressed.

Legacy systems compound this risk. Kusari's report found that 59% of respondents cited legacy systems as the most significant source of inherited risk in their software supply chain. Healthcare organizations were particularly exposed, with 84% flagging legacy systems as their biggest concern. Older codebases tend to have longer, less maintained dependency chains where transitive vulnerability accumulation goes unchecked.

‍

Direct vs. Transitive Dependencies: A Comparison

Understanding the difference between direct and transitive dependencies is foundational to closing the visibility gap.

This table highlights why relying solely on direct dependency management leaves the majority of your SBOM accuracy unverified. A complete picture requires mapping the entire dependency tree, including every transitive path.

‍

Five Steps to Improve Transitive Dependency Visibility

Closing the transitive dependency visibility gap doesn't require ripping out existing tooling overnight. It does require a deliberate, layered approach.

Step 1: Generate a complete, recursive SBOM. Your Software Bill of Materials should capture every component in your dependency graph—not just the top layer. Tools that perform recursive resolution across package managers like npm, Maven, PyPI, and NuGet are essential.

Step 2: Map the full dependency graph. A flat list of components isn't enough. You need to understand the relationships between them—which packages pull in which, through what paths, and at what versions. Dependency graph visualization makes it possible to trace transitive dependency vulnerabilities back to their source.

Step 3: Apply reachability analysis. Not every vulnerability in your dependency tree is exploitable. Reachability analysis determines whether a vulnerable function is actually called by your application code, dramatically reducing false positives and helping your team focus on risks that matter.

Step 4: Prioritize using blast radius, not just CVSS scores. A critical-severity CVE in a deeply nested, unreachable library is less urgent than a moderate-severity flaw in a transitive component that's actively invoked at runtime. Combine CVSS with EPSS (Exploit Prediction Scoring System) and KEV (Known Exploited Vulnerabilities) data for smarter vulnerability prioritization.

Step 5: Automate continuous monitoring. Dependencies change constantly. New versions are released, maintainers shift, and previously safe components get compromised. Continuous monitoring of your dependency graph ensures that newly disclosed transitive dependency vulnerabilities are caught early—not weeks later during a scheduled scan.

‍

When Transitive Dependency Monitoring Falls Short

No approach works universally, and it's worth being upfront about the limitations.

Transitive dependency analysis is less effective when applied to vendored code—projects where dependencies are copied directly into the repository rather than resolved through a package manager. Without a manifest file to parse, automated tools can't reconstruct the dependency tree reliably.

Polyglot environments present another challenge. An application that spans three or four programming languages (say, a Java backend with a Python ML service and a Node.js frontend) requires different dependency resolution strategies for each ecosystem. Most tools handle one or two ecosystems well; few handle all of them equally.

Organizations with very large monorepos may also face performance constraints. Mapping the complete dependency graph for a monorepo with millions of lines of code and thousands of packages takes compute time and can generate dependency trees so large they're difficult to interpret without purpose-built tooling.

Finally, transitive dependency visibility doesn't replace other security practices. It's one layer in a defense-in-depth strategy that should also include code review, build integrity verification (via frameworks like SLSA and in-toto), and runtime monitoring.

‍

What Mature Transitive Dependency Management Looks Like

Organizations in the top quartile of Kusari's survey—those that understand their transitive dependencies "to a great extent"—consistently report better security outcomes. They check their security posture more frequently, respond to vulnerabilities faster, and experience fewer unexpected incidents.

These teams share a few common characteristics. They treat transitive dependency visibility as a foundational capability, not an advanced add-on. They run automated SCA and SBOM generation on every pull request, not just at release milestones. And they've established clear ownership of dependency hygiene across development and security teams—avoiding the fragmented responsibility that slows remediation at most organizations.

The data also shows a correlation between checking frequency and outcomes. Organizations that assess security daily (19% of respondents) report 40% fewer monthly vulnerability discoveries than those that check only at release milestones. Earlier, more frequent checks catch issues closer to the point of introduction, reducing downstream remediation costs.

Transitive dependency vulnerability management, done well, shifts the security posture from reactive to proactive—from firefighting inherited risks to understanding and governing them before they reach production.

‍

Closing the Gap with Kusari

Kusari helps organizations gain actionable visibility into both direct and transitive dependencies across the software supply chain. Our data and analysis go deeper to automatically maps nested dependency relationships, identifies inherited risk, and provides the context needed for effective remediation—without manual configuration or guesswork about dependencies. We're not reverse engineering to get to a solution, we've done the hard work to provide source information about the software you have now to the new libraries and AI-generated code that's being pulled into your enterprise.

Rather than generating another flood of alerts, Kusari surfaces findings with business context: which transitive paths are reachable, what the blast radius of a vulnerability looks like, and where to focus remediation efforts. This approach helps DevSecOps teams move from reactive scanning to informed, continuous supply chain security.

Request a demo to see how Kusari closes the visibility gap for transitive dependencies.

‍

Frequently Asked Questions

What are transitive dependency vulnerabilities? Transitive dependency vulnerabilities are security flaws found in indirect software components—the packages your application inherits through its declared dependencies rather than ones your developers explicitly selected. Because these components are pulled in automatically during dependency resolution, they often escape routine security scans and create hidden risk in the software supply chain.

Why are transitive dependencies harder to detect than direct dependencies? Transitive dependencies are harder to detect because they don't appear in standard manifest files and can sit multiple layers deep in the dependency graph. Traditional SCA tools primarily focus on direct dependencies, and without recursive resolution and reachability analysis, security teams may not know these components exist—let alone whether they contain exploitable flaws.

What percentage of open-source vulnerabilities are found in transitive dependencies? According to research published by Endor Labs, approximately 95% of open-source vulnerabilities reside in transitive dependencies rather than in directly declared packages. This statistic underscores why organizations that only scan direct dependencies are missing the vast majority of their actual risk surface.

How can organizations improve visibility into transitive dependency vulnerabilities? Organizations can improve visibility into transitive dependencies by generating recursive SBOMs that capture the full dependency tree, mapping dependency graphs to understand component relationships, applying reachability analysis to assess exploitability, and implementing continuous monitoring to catch newly disclosed flaws. Prioritization should combine CVSS, EPSS, and KEV data rather than relying solely on severity scores.

What is the difference between a direct and a transitive dependency? A direct dependency is a software package that developers explicitly include in their project configuration. A transitive dependency is inherited indirectly—it's a dependency of a dependency. For example, if your project uses Library A, which requires Library B, then Library B is a transitive dependency. Most applications contain far more transitive dependencies than direct ones.

How does SBOM accuracy relate to transitive dependency security? SBOM accuracy depends directly on whether the Software Bill of Materials captures transitive components. An SBOM that lists only direct dependencies misrepresents the software's true composition, creating compliance gaps and leaving hidden vulnerabilities untracked. A complete, recursive SBOM is the foundation for effective transitive dependency vulnerability management.

What tools help with managing transitive dependency vulnerabilities? Transitive dependency vulnerability management typically requires advanced SCA tools with recursive dependency resolution, SBOM generation platforms, dependency graph visualization, and reachability analysis capabilities. Platforms like Kusari combine these capabilities with continuous monitoring and contextual risk assessment to help teams prioritize remediation based on actual exposure rather than raw severity scores.

‍