Transitive dependency blind spots are leaving most apps exposed

At a glance

What this is: This is a supply chain security analysis showing that transitive dependency blind spots leave most organisations with incomplete visibility into the nested components inside their applications.

Why it matters: It matters because AppSec, SBOM, and remediation programmes depend on knowing the full dependency graph, and incomplete visibility weakens prioritisation, ownership, and compliance evidence across software teams.

By the numbers:

• Only 28% of respondents feel they have strong insight into their transitive dependency layers.
• 47% of teams spend more than 5 hours per week on supply chain security remediation.
• 84% of healthcare organisations cite legacy systems as their biggest supply chain risk.
• 64% of energy and utility organisations cite legacy systems as their biggest supply chain risk.

Context

Transitive dependencies are the indirect libraries and nested packages that arrive through other components, not the code a development team selected directly. In practice, they create a software supply chain visibility problem because scanning only declared dependencies leaves the underlying risk surface partially hidden. For identity and access practitioners, the intersection is governance: if the software estate cannot be inventoried accurately, neither entitlement, exposure, nor remediation decisions can be fully trusted.

The article argues that most organisations are still operating with an incomplete view of their applications because standard SCA resolves dependency trees at build time rather than maintaining continuous visibility. That gap affects prioritisation, compliance evidence, and incident response, especially where transitive components are numerous, change frequently, or sit inside legacy environments.

The starting position described here is typical rather than exceptional, because the report suggests that incomplete transitive dependency insight is the norm across mid-sized organisations.

Key questions

Q: What breaks when transitive dependency visibility is missing?

A: Teams lose the ability to see most inherited software risk, so scans overstate confidence and understate exposure. Direct dependency checks can look clean while vulnerable transitive packages still ship into production. The result is slower remediation, poor ownership, and a false sense of compliance that collapses when a widely used upstream component is disclosed or compromised.

Q: Why do transitive dependencies create such a large security problem?

A: Because most teams do not install every library directly, they inherit risk through frameworks, plugins, and bundled components they may not know are present. A single vulnerable dependency can therefore affect many services at once, which means visibility into software composition is as important as patching speed.

Q: How do security teams know if dependency controls are actually working?

A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.

Q: Should organisations prioritise transitive dependency mapping or more SCA tools?

A: They should prioritise transitive dependency mapping first. Adding more scanners rarely fixes the core problem if the organisation still cannot see the full graph or keep it current between builds. Better governance comes from complete inventory, continuous monitoring, and clear remediation ownership, not tool sprawl.

Technical breakdown

Why transitive dependencies create a hidden attack surface

A transitive dependency is a package, library, or component that enters an application through another dependency rather than through direct developer selection. The security problem is not simply volume, but opacity: teams usually know the top-level libraries they approved, while nested packages can multiply several layers deep and change independently. That means vulnerability exposure can exist in code no one explicitly reviewed, especially in ecosystems such as npm, Maven, PyPI, and similar package managers. The attack surface is therefore cumulative, not linear. If your inventory stops at direct dependencies, you are governing only the visible edge of the software graph.

Practical implication: build inventory processes that capture the full dependency tree, not just the packages developers added directly.

Why build-time SCA leaves a visibility gap

Software composition analysis is useful, but most implementations check manifests and dependency trees at a specific point in time. That creates a control gap between scans, because a nested component can release a vulnerable version after the build has passed and before the next scan runs. Even when SCA resolves transitive components, point-in-time resolution is not the same as continuous monitoring. The result is a stale view of a live supply chain. For security governance, that means the tool may be accurate at scan time while still failing as an operational control over the full application lifecycle.

Practical implication: treat SCA as a baseline control and add continuous monitoring for newly disclosed vulnerabilities in nested components.

Why reachability analysis matters for nested component risk

Reachability analysis asks whether a vulnerable function inside a dependency is actually called by the application. That matters because not every CVE in a transitive component creates the same operational exposure. Without that context, teams drown in alerts and waste time chasing issues that may never be reachable in production. The article’s reference to higher-maturity teams aligns with a broader pattern: they combine dependency mapping with prioritisation logic, so remediation effort goes toward vulnerabilities that can materially affect the running system rather than every theoretical weakness in the graph.

Practical implication: pair dependency visibility with reachability checks so remediation effort tracks real exposure, not just scan volume.

Threat narrative

Attacker objective: The attacker objective is to exploit hidden software supply chain exposure in nested dependencies or force organisations into reactive remediation that they were not prepared to prioritise.

1. Entry occurs when a nested library or package is introduced through a direct dependency and enters the application without explicit team review.
2. Credential or code-path exposure follows when a newly disclosed flaw appears in a transitive component between scans and remains invisible to teams watching only declared dependencies.
3. Impact emerges when the hidden vulnerable component is exploited or forces emergency remediation across applications that rely on the same dependency chain.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

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 governance control, not a tooling preference. The article shows that teams can have SCA in place and still lack the information needed to make defensible security decisions. That is a control-design problem, not just a scanning problem, because the organisation is making judgments about code it cannot fully enumerate. Practitioners should treat full dependency visibility as a prerequisite for credible supply chain governance.

Standard AppSec programmes overestimate what point-in-time scanning can prove. The central failure mode here is the assumption that resolving a dependency tree once means the supply chain is understood. That assumption breaks when nested components change between builds or disclose new vulnerabilities after the last scan. In operational terms, the control gap is stale evidence, and stale evidence is the same as incomplete evidence when risk decisions are time-sensitive.

Nested dependency opacity creates remediation debt that spreads across the engineering organisation. When teams spend hours each week chasing issues in components they did not know existed, the cost is not only technical. It is a governance drag that absorbs developer capacity, delays releases, and weakens confidence in security findings. The named concept here is dependency graph blindness: the inability to see and prioritise the full set of inherited packages that drive exposure. Practitioners should design around that blind spot, not assume it will disappear with more scanning.

In identity-adjacent supply chain programmes, provenance matters because ownership depends on inventory. If a component is not visible, it cannot be attributed, governed, or remediated with confidence, which is why software supply chain control increasingly intersects with broader identity and asset governance. That connection matters for NHI, because build pipelines and package ecosystems often rely on service accounts, tokens, and automation identities. Practitioners should align inventory, ownership, and remediation workflows across both software and identity governance.

The organisations that perform best are the ones that operationalise visibility continuously. The article’s maturity signal is not more alerts, but better timing and clearer context. Security teams that update their view daily or per pull request reduce surprise and improve response discipline. The practitioner lesson is straightforward: treat visibility as an operating rhythm, not a one-off assessment.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Ultimate Guide to NHIs — Key Research and Survey Results

What this signals

Dependency graph blindness: many teams are still governing the top layer of the software stack while the inherited layers remain opaque. That creates a structural mismatch between what AppSec believes it is protecting and what is actually being shipped, so visibility has to become continuous rather than episodic.

The article’s most useful signal for practitioners is that scanning depth alone is not enough. Teams that want fewer surprises need inventory, freshness, and prioritisation tied together, otherwise every new disclosure in a nested package becomes an emergency rather than a managed workflow. Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

For identity and supply chain programmes, the practical direction is clear: inventory accuracy, provenance, and ownership need to be governed as one control plane. Without that, software supply chain risk remains partially hidden even when the organisation believes its tooling is mature.

For practitioners

• Implement full dependency graph inventory Map direct and transitive components across every package ecosystem in use, then keep the inventory current enough to support vulnerability and compliance decisions.
• Move from build-time scans to continuous monitoring Track newly disclosed vulnerabilities across nested packages between releases so a transitive issue does not sit undiscovered until the next scan cycle.
• Use reachability to prioritise remediation Confirm whether the vulnerable function is actually invoked before escalating work, especially where a transitive issue could generate large alert volumes.
• Define shared remediation ownership Assign clear responsibility between security and engineering for fixing transitive dependency issues so discoveries do not stall in handoff.
• Strengthen SBOM completeness checks Verify that SBOM generation includes nested components and provenance, because a partial SBOM only documents the visible top layer of the application.

Key takeaways

• The article shows that transitive dependency exposure is mainly a visibility problem, not a lack of scanners.
• Kusari’s data indicates that most organisations still cannot see nested package risk clearly enough to govern it well.
• Continuous inventory, reachability-based prioritisation, and clear remediation ownership are the controls that change outcomes.

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.
• Dependency graph: A dependency graph maps the systems, services, and workflows that rely on a non-human identity. It helps responders understand blast radius and operational impact before disabling an identity, which is critical when service accounts or tokens are embedded in production processes.
• 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.
• 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.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader security and supply chain governance.