Why 72% of Organizations Can't See Their Real Attack Surface: Solving the Transitive Dependency Visibility Gap

Most security leaders think they have a handle on their attack surface. They run SCA tools, generate SBOMs, and track the libraries their developers pull into production. 

But there's a problem with that confidence: according to Kusari's Application Security in Practice report, only 28% of respondents feel they have strong insight into their transitive dependency layers. That means roughly 72% of organizations are making security decisions based on an incomplete picture of their own transitive dependency attack surface.

That gap carries real business consequences, and it lands squarely on the CISO's desk.

Key Insights: What You Need to Know About the Transitive Dependency Attack Surface

• The transitive dependency attack surface describes the cumulative security exposure from indirect, nested software components your team didn't choose and probably isn't tracking. These hidden layers represent the largest unmonitored segment of most software supply chains.
• Only 28% of organizations have strong visibility into their transitive dependency layers, according to Kusari's Application Security in Practice report. That leaves roughly 72% making security decisions with an incomplete picture of what's actually in their software.
• SCA tools alone don't close the gap. Most software composition analysis scans focus on declared direct dependencies and resolve the dependency tree only at build time, missing newly disclosed vulnerabilities in deeply nested components between scans.
• Inherited risk from transitive dependencies drains developer time. The Kusari report found that 47% of teams spend more than 5 hours per week on supply chain security remediation, largely because poor visibility forces reactive patching rather than proactive prevention.
• Dependency mapping maturity predicts security outcomes. Organizations in the top quartile for transitive dependency visibility check security posture more frequently, respond to vulnerabilities faster, and experience fewer surprise incidents (Kusari, Application Security in Practice).
• Healthcare and energy sectors face acute blind spots. Legacy systems, cited as the top supply chain risk by 84% of healthcare organizations and 64% of energy/utility organizations, are especially opaque when it comes to identifying nested transitive components.
• Closing the transitive dependency attack-surface gap requires comprehensive SBOM generation, continuous monitoring across the full dependency graph, reachability analysis for prioritization, and well-defined remediation workflows.

What Is a Transitive Dependency Attack Surface?

When your team adds a library to an application, that library almost certainly depends on other libraries, which depend on still more libraries. Those second- and third-order components are transitive dependencies, also known as indirect or nested dependencies. Your developers didn't choose them, probably don't know they exist, and almost certainly aren't monitoring them for vulnerabilities.

The transitive dependency attack surface is the total risk exposure created by all of those indirect components. In a typical modern application built with npm, Maven, or PyPI packages, transitive dependencies can outnumber direct dependencies by a factor of ten or more. One Kusari customer, for example, discovered over 18,000 components in their software when they had previously been tracking only direct dependencies.

And that kind of sprawl is common.

Why Most Organizations Are Flying Blind

The Kusari Application Security in Practice report surveyed software developers and security professionals at mid-sized organizations. The findings paint a clear picture of a widespread visibility gap.

While 56% of respondents said they were highly aware of their direct dependencies, only 28% could say the same about transitive dependencies. Another 61% reported being only "somewhat aware," and 11% weren't sure at all. Compare that to direct dependency awareness, where 56% said "highly aware" and just 6% said "not at all aware."

That disparity matters. Direct dependencies are the ones your team chose. Transitive dependencies are the ones that came along for the ride, and they're the ones most likely to harbor vulnerabilities that nobody's watching.

The problem is worse in certain sectors. In healthcare, 84% of organizations cited legacy systems as their biggest supply chain risk. Legacy systems are often opaque, making it hard to know what transitive components they contain. Energy and utility organizations showed similar concerns, with 64% flagging legacy risk.

The Business Cost of Not Seeing Your Transitive Dependency Attack Surface

Security leaders tend to think in terms of vulnerabilities found and patched. But the real cost of poor visibility into transitive dependencies shows up in other ways.

Wasted developer time. Nearly half of teams (47%) spend more than five hours per week responding to and remediating software supply chain security issues, according to the Kusari report. Two-thirds of teams spend up to 20 hours per week. That's time not spent building features, and it's driven largely by reactive firefighting rather than proactive prevention.

Endless whack-a-mole. Without visibility into the full dependency graph, teams fix a vulnerability only to have it resurface in a transitive component they didn't know about. The report describes this as a "whack-a-mole" scenario where issues emerge in dependencies nobody realized they had. That pattern burns through goodwill with engineering teams and erodes confidence in the security function.

Inherited risk from open source. Open-source code ranked lower than expected as a perceived supply chain risk (only 36% flagged it), likely because developers are so accustomed to using it that they downplay the risk. But transitive dependencies are overwhelmingly open-source, and they bring licensing issues, abandoned-maintainer risk, and unpatched vulnerabilities along with them.

Regulatory exposure. Requirements such as the EU Cyber Resilience Act (CRA), the NIST Secure Software Development Framework (SSDF), and FDA 524B are increasingly demanding that organizations demonstrate knowledge of their entire software supply chain. You can't comply with SBOM requirements you don't understand, and an SBOM that only lists direct dependencies is incomplete by definition.

Why Standard SCA Tools Aren't Enough

Software composition analysis tools are essential to any application security program. But most SCA tools have a fundamental limitation: they focus on what's been declared rather than on what's actually running.

A typical SCA scan starts from a manifest file (package.json, pom.xml, requirements.txt). It identifies the direct dependencies listed there and checks them against vulnerability databases like the CVE database, CVSS scores, and the CISA Known Exploited Vulnerabilities (KEV) catalog. Some tools go a step further and resolve the dependency tree to include transitive components.

But "resolving the tree" and "maintaining continuous visibility" are very different things. Dependency resolution happens at build time. Between builds, a transitive dependency might release a new version with a known vulnerability, and nobody would know until the next scan, if the next scan even catches it.

The gap between what SCA tools show you and what's actually in your software is where the risk lives. For 72% of organizations without strong visibility into transitive dependencies, that gap can be enormous.

What Mature Organizations Do Differently

The Kusari report found a clear correlation between the visibility of transitive dependencies and supply chain security maturity. Among organizations that systematically track dependencies, the top quartile (those that understand their transitive dependencies to a great extent) consistently report better outcomes across the board.

They check security posture more frequently. They respond to vulnerabilities faster. They experience fewer unexpected security incidents.

What separates them from the rest? A few common practices:

They treat dependency mapping as foundational rather than optional. Mature organizations don't view transitive dependency tracking as an advanced add-on to their SCA program. It's a baseline capability, like having a fire alarm. You wouldn't run a building without one; you shouldn't run software without knowing what's in it.

They automate security checks at high frequency. The report found that organizations with the best outcomes check security daily or on every pull request. That cadence catches issues earlier and reduces the blast radius of any single vulnerability. Waiting for a quarterly scan is like checking your smoke detectors once a year and hoping nothing catches fire in between.

They've adopted shared ownership models. Security teams largely "own" AppSec and supply chain reviews at most organizations, but this model often leads to delays and workflow friction. Mature organizations push day-to-day responsibility closer to development while security teams focus on standards, monitoring, and escalations.

They consolidate tools. Rather than layering on more scanners, the most effective organizations use two or three focused, well-integrated tools that work cleanly through common interfaces like PR comments, SBOMs, or shared pipelines.

‍

‍

How to Map Your Transitive Dependency Attack Surface

Closing the visibility gap doesn't require a total overhaul. But it does require deliberate steps that go beyond what most teams are currently doing.

Step 1: Audit your current dependency visibility

Start with an honest assessment. Do your SCA tools resolve transitive dependencies? How many layers deep? Are the results current or stale? Do they cover all package ecosystems your team uses (npm, Maven, PyPI, NuGet, Gradle, cargo, pip)?

If you can't answer these questions, you already know where the gaps are.

Step 2: Generate comprehensive SBOMs

An SBOM that only includes direct dependencies is incomplete. Your SBOM generation process needs to capture the full dependency graph, including transitive components, their versions, and their provenance. This is foundational for dependency mapping and for meeting regulatory requirements.

Step 3: Implement continuous monitoring

Point-in-time scans are not enough. You need ongoing monitoring that watches for newly disclosed vulnerabilities across your entire dependency tree, including the transitive layers. When a new CVE drops for a deeply nested component, you need to know within hours, not weeks.

Step 4: Prioritize with context

Not every vulnerability in a transitive dependency is equally dangerous. Reachability analysis helps determine whether a vulnerable function is actually called in your application. EPSS (Exploit Prediction Scoring System) scores can help prioritize based on real-world exploitation likelihood. This kind of context prevents teams from drowning in low-priority alerts.

Step 5: Establish a remediation workflow

When a transitive dependency vulnerability is confirmed as a real risk, your team needs a clear path to fix it. That might mean updating a direct dependency to pull in a patched transitive component, replacing a library entirely, or applying a workaround until a fix is available. Document this workflow so it's repeatable.

Transitive Dependency Visibility as a Competitive Advantage

Here's something the Kusari report makes clear: visibility into transitive dependencies is one of the strongest predictors of how well an organization handles supply chain security across the board.

Organizations with strong visibility into their transitive dependency attack surface spend less time on reactive remediation, catch problems before they reach production, and operate with confidence that they can respond to the next Log4Shell-type event without panic.

For CISOs, that translates to measurable outcomes: lower mean time to remediate, fewer emergency incidents, reduced developer friction, and a defensible compliance posture.

For organizations still in the 72% without that visibility? Every week of delay is another week where vulnerabilities sit in components nobody's watching.

Limitations and When This Approach Needs Adjustment

Full transitive dependency mapping is valuable, but it's not a universal fix. There are situations where this approach needs adaptation.

Organizations with large legacy codebases may find that some components are so deeply intertwined that mapping transitive dependencies is impractical without first modernizing the build system. In these cases, it makes more sense to start with the most critical applications and expand coverage gradually.

Monorepo environments can introduce complexity because a single dependency change can cascade across dozens of internal packages. The tooling needs to handle that scale without creating noise.

Teams using vendor-provided binaries or proprietary SDKs often can't see inside those packages at all. In those cases, vendor SBOMs and contractual security requirements become the primary risk management tools.

And for very small teams with limited security budgets, a full continuous monitoring setup may be more than they need right away. Targeted dependency audits on a regular cadence can still reduce the transitive dependency attack surface compared to doing nothing.

‍

See How Kusari Closes the Transitive Dependency Visibility Gap

Kusari, the creator and maintainer of the OpenSSF's GUAC project, helps organizations gain clear, actionable visibility into both direct and transitive dependencies across the software supply chain. By automatically mapping deeply nested dependency relationships and continuously monitoring them, Kusari eliminates the blind spots that lead to reactive, whack-a-mole remediation.

Whether you're a CISO building a defensible security program or a VP of Engineering trying to give your developers their time back, Kusari can help you understand your full transitive-attack-surface and act on it.

Request a demo at kusari.dev/demo

‍

Frequently Asked Questions

What is a transitive dependency attack surface?

A transitive dependency attack surface is the total security exposure created by indirect software components that are pulled into an application through its direct dependencies. Unlike direct dependencies, which developers consciously select, transitive dependencies are inherited automatically and often extend several layers deep into the dependency graph. Most organizations lack visibility into these components, leaving vulnerabilities undetected for months.

Why can't most organizations see their full attack surface?

Most organizations can't see their full attack surface because their tooling focuses on direct dependencies, overlooking transitive dependencies. According to Kusari's Application Security in Practice report, only 28% of respondents have strong insight into their transitive dependency layers. Standard SCA tools often resolve dependencies only at build time and may not continuously monitor nested components for newly disclosed vulnerabilities.

How do transitive dependencies create inherited risk?

Transitive dependencies create inherited risk because they bring along code that your team didn't choose, review, or vet. If a transitive component three layers deep contains a vulnerability, your application is exposed even though your developers never explicitly added that library. This inherited risk is particularly dangerous because it often goes undetected until an incident occurs.

What's the difference between direct and transitive dependency visibility?

Direct dependency visibility means knowing which libraries your team has explicitly added to your project. Transitive dependency visibility goes further, covering all the downstream components those libraries rely on. The gap between the two is substantial: the Kusari report found that 56% of organizations feel highly aware of their direct dependencies but only 28% can say the same about transitive ones.

How does poor dependency visibility affect developer productivity?

Poor dependency visibility affects developer productivity by forcing teams into a reactive cycle of emergency patching. The Kusari report found that 47% of teams spend more than five hours per week responding to supply chain security issues. Without visibility into where vulnerabilities actually live in the dependency graph, developers waste time chasing false leads and fixing issues that resurface elsewhere.

What role do SBOMs play in the visibility of transitive dependencies?

SBOMs (Software Bills of Materials) are central to visibility into transitive dependencies because they provide a complete inventory of all software components, including nested ones. However, an SBOM is only as useful as it is complete. An SBOM that lists only direct dependencies gives a false sense of security. Accurate SBOM generation that captures the full dependency graph is foundational for effective dependency mapping and regulatory compliance.

Which industries are most affected by transitive dependency blind spots?

Healthcare and energy/utility organizations are among the most affected by transitive dependency blind spots, given their heavy reliance on legacy systems. The Kusari report found that 84% of healthcare organizations and 64% of energy/utility organizations cite legacy systems as their biggest software supply chain risk. These legacy environments are often opaque, making it especially difficult to identify nested dependencies.

How can CISOs start closing the transitive dependency visibility gap?

CISOs can start closing the transitive dependency visibility gap by first auditing their current SCA tool coverage to understand which dependencies are and aren't being tracked. From there, the next steps include generating comprehensive SBOMs that include transitive components, implementing continuous monitoring across the full dependency tree, and establishing clear remediation workflows. Prioritizing applications with the highest business impact is a practical starting point.