Transitive dependency risk exposes the software supply chain blind spot

At a glance

What this is: This is an analysis of transitive dependency vulnerabilities, showing that most open-source risk sits beyond direct dependencies and often escapes standard SCA coverage.

Why it matters: It matters because teams responsible for IAM-adjacent security, NHI-enabled build pipelines, and software supply chain governance need recursive visibility to control inherited risk, not just patch declared packages.

By the numbers:

• According to research published by Endor Labs, approximately 95% of open-source vulnerabilities reside in transitive dependencies rather than in directly declared packages.
• Only 28% of respondents said they had strong insight into deeper transitive dependency layers.
• 47% of teams spend more than five hours per week responding to and remediating software supply chain security issues.

👉 Read Kusari's analysis of transitive dependency vulnerability management

Context

Transitive dependency risk is a visibility problem before it is a vulnerability problem. If security teams only inspect direct dependencies, they miss the indirect packages that actually carry most inherited exposure across modern software supply chains. In practice, that means the control gap is not absence of scanning but absence of recursive understanding of what is really in production.

This matters to identity and access governance because software build systems, CI/CD pipelines, and developer tooling increasingly rely on secrets, service accounts, and automated trust relationships to pull in code. When those identities are not tightly governed, transitive risk becomes harder to bound, because compromise can move through both dependency paths and credentialed supply paths.

Kusari's analysis is typical of modern application security programs: the direct dependency picture looks manageable, while the deeper graph reveals a much larger and more dynamic exposure surface.

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 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 can organisations tell whether their SBOM process is actually working?

A: A working SBOM process can generate an SBOM for every release, sign it automatically, let consumers verify it independently, and retrieve the record quickly during an audit or incident. If any one of those steps is inconsistent, the process is only partially controlled.

Q: Who is accountable when a transitive dependency vulnerability reaches production?

A: Accountability should be shared but explicit: engineering owns the component graph, security defines policy and monitoring thresholds, and product or platform teams approve remediation priority. Frameworks such as the NIST Secure Software Development Framework and EU Cyber Resilience Act expectations make it clear that supply chain knowledge cannot be an afterthought.

Technical breakdown

Why transitive dependencies create hidden attack surface

A transitive dependency is a component your project inherits through another package rather than selecting directly. That matters because dependency resolution can pull in hundreds or thousands of additional packages, each with its own vulnerabilities, update cadence, and trust assumptions. Standard SCA often reports what is declared in manifests, but the real runtime graph is deeper and more volatile. The result is a mismatch between what teams believe they control and what the application actually executes.

Practical implication: Map the full dependency graph recursively, not just the manifest file, before you treat a scan as authoritative.

Why SCA findings become noise without reachability analysis

Reachability analysis asks whether vulnerable code is actually invoked by the application. A flaw can exist in a transitive package and still be irrelevant if no code path reaches it at runtime. Without that check, SCA produces alert fatigue, because every theoretical exposure is presented as equally actionable. That is why raw CVSS scoring is a poor prioritisation method for dependency risk on its own. Exploit probability, observed exploitation, and code-path context all matter.

Practical implication: Use reachability analysis to separate theoretical package exposure from vulnerabilities that can actually be exercised in production.

Why recursive SBOMs are the governance baseline

A software bill of materials only helps if it captures the complete dependency chain. Recursive SBOM generation records direct and transitive components, giving security, compliance, and engineering teams a common inventory for audit and remediation. In supply chain governance terms, this shifts the conversation from whether a package is present to whether it is known, owned, and monitored across its full lifecycle. That is the basis for consistent remediation and auditability.

Practical implication: Require recursive SBOM generation in build pipelines so inherited components are visible from introduction through release.

Threat narrative

Attacker objective: Exploit hidden trust in inherited software components to gain execution, persistence, or downstream compromise at scale.

1. Entry begins when a build or application pipeline ingests a vulnerable transitive package through ordinary dependency resolution, often without explicit developer awareness.
2. Escalation occurs when the hidden dependency is reachable at runtime or becomes the path for malicious code introduced upstream, turning inherited trust into an exploitable control gap.
3. Impact is supply chain compromise, where attackers can exploit the unseen package path to trigger code execution, data exposure, or persistent dependency poisoning across downstream consumers.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Recursive visibility is now a supply chain control, not a reporting enhancement. The article makes clear that most open-source vulnerability exposure sits below the direct dependency layer, which means surface scans are structurally incomplete. That is a governance failure, not an analytics gap. For practitioners, the implication is that software inventory must be recursive by design, or it will continue to overstate confidence.

Transitive dependency risk exposes a false assumption of package ownership. Teams often believe they control the libraries they name in manifests, but they do not control the indirect packages pulled in by upstream maintainers. This is where software supply chain governance and identity governance intersect: build systems and CI/CD agents often act with standing secrets and broad tool access, so inherited code risk and credential risk reinforce one another. The practitioner lesson is to govern both dependency graphs and the identities that assemble them.

Reachability analysis is the difference between exposure inventory and usable risk intelligence. A vulnerability buried in an unreachable library is not the same as one on an executed code path, and treating them as equivalent breaks prioritisation. That creates the whack-a-mole pattern the article describes. Security leaders should treat reachability as the control that turns SBOM data into decision-grade remediation.

Deep dependency chains are a good example of inherited governance debt. Legacy systems, large monorepos, and polyglot stacks accumulate unseen components over time, and each layer adds another review burden. The longer teams wait to baseline the graph, the more the program depends on tribal knowledge instead of enforceable inventory. Practitioners should treat dependency debt as an exposure class that compounds until continuously measured.

Supply chain security is increasingly about who and what is allowed to introduce change. The article points toward continuous monitoring and clear ownership across DevSecOps teams, which aligns with how modern identity programs already think about privileged change. In practice, that means locking down pipeline identities, monitoring dependency drift, and forcing accountability for every new component that enters the software graph.

From our research:

• According to The 52 NHI breaches Report, 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• 47% of teams spend more than five hours per week responding to and remediating software supply chain security issues.
• Forward look: The Top 10 NHI Issues resource helps teams connect software supply chain governance to identity and privilege controls across build systems.

What this signals

Transitive dependency management is becoming a policy problem as much as a tooling problem. If your organisation cannot recurse through the full dependency graph, you do not have a reliable inventory for remediation, compliance, or incident response. That is why recursive SBOM coverage and reachability analysis should be treated as baseline controls, not advanced maturity markers.

Inherited trust is the named concept here: every indirect package, pipeline identity, and upstream maintainer relationship extends the trust boundary further than most teams realise. In organisations that rely heavily on automated build workflows, that boundary is often governed less tightly than the code itself. The practical signal is clear: if you cannot explain who can introduce, sign, and consume dependencies, you do not have enough control.

For identity teams, the relevant shift is to treat build and release identities as privileged actors in the software supply chain. Secrets, tokens, and signing credentials used by CI/CD systems should be monitored with the same rigor as other high-risk non-human identities. That linkage between dependency risk and identity governance is where the next reduction in blast radius will come from.

For practitioners

• Implement recursive SBOM generation Require every build to generate a complete Software Bill of Materials that includes direct and transitive components across all package managers in use.
• Prioritise with reachability analysis Use code-path analysis to determine whether a vulnerable transitive function is actually invoked before assigning remediation priority.
• Track blast radius, not just severity Combine CVSS with EPSS and KEV signals so remediation focuses on exploitable dependencies with real downstream impact.
• Govern pipeline identities and secret access Restrict the service accounts, tokens, and signing credentials that can modify dependency graphs, because supply chain risk grows when build identities are over-privileged.
• Continuously monitor dependency drift Automate alerts for newly introduced transitive packages, version shifts, and upstream maintainer changes so exposure is caught before the next release cycle.

Key takeaways

• Surface-level scanning captures only a fraction of modern supply chain exposure because most vulnerabilities sit in transitive dependencies.
• Recursive SBOMs and reachability analysis are the controls that turn dependency data into usable security decisions.
• Governance must extend to the identities that build and release software, because pipeline privilege can amplify inherited package risk.

Key terms

• Transitive Dependency: A transitive dependency is a software component that arrives indirectly through another package rather than being chosen by developers in the project manifest. It expands the real runtime dependency graph and can introduce security risk that standard scans miss unless they recurse through the full chain.
• 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.
• 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.
• 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.

What's in the full article

Kusari's full research covers the operational detail this post intentionally leaves for the source:

• A deeper breakdown of how recursive dependency graph mapping works across npm, Maven, PyPI, and NuGet ecosystems
• Survey data on where teams struggle most in transitive dependency visibility and how that varies by dependency layer
• Practical examples of how reachability analysis changes prioritisation for vulnerable packages
• Discussion of how continuous monitoring reduces the gap between disclosure and remediation

👉 The full Kusari article covers recursive SBOMs, reachability analysis, and dependency graph remediation in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It gives practitioners a structured way to connect identity controls to the broader security programmes they operate.