TL;DR: Transitive dependencies can hide vulnerable components until they propagate across repositories, manifests, and build systems, and OXSecurity argues that a multi-dependency graph helps teams uncover those blind spots, correlate exposure, and prioritise remediation across large codebases. The governance challenge is less about more alerts and more about knowing which dependencies can actually affect runtime risk.
At a glance
What this is: This analysis says transitive dependencies can conceal vulnerability paths across complex codebases, and that multi-dependency graphs improve visibility into where risk can propagate.
Why it matters: AppSec and platform teams need to know which dependency chains actually change runtime exposure, especially in monorepos and multi-language builds where direct manifests are incomplete.
By the numbers:
- OXSecurity says there are 30+ disclosures and 10+ CVEs to explore in this new dependency-management reality.
Context
Modern application risk is no longer limited to the packages developers can name directly. Transitive dependencies, build scripts, and language-specific resolution rules can hide vulnerable components deep in the software graph, which leaves AppSec teams with incomplete visibility and delayed remediation decisions.
The identity angle is indirect but real: software supply chains increasingly depend on service credentials, CI permissions, signing keys, and deployment access to move code into production. When dependency visibility is poor, governance over those non-human identities and build privileges becomes harder to enforce, especially in monorepos and multi-repository estates.
Key questions
Q: What fails when AppSec teams only review direct dependencies?
A: They miss the nested packages, shared modules, and build-time relationships that actually carry risk into production. A direct package list can look clean while a transitive dependency still introduces a vulnerable code path. Effective governance requires relationship-level visibility, not just manifest review.
Q: Why does runtime reachability matter more than package inventory?
A: Because a vulnerability only changes operational risk if the affected code path can actually be executed in the environment. Package inventory tells you what exists, but reachability tells you what can matter. That distinction is what turns triage into prioritisation.
Q: What are the signs that dependency visibility is failing in a software estate?
A: Frequent surprise findings, repeated false positives, inconsistent dependency data across repositories, and slow answers about whether a vulnerable component is actually in use. Those symptoms usually mean teams are looking at disconnected manifests instead of a unified dependency graph.
Q: How should security teams govern transitive dependency risk in monorepos?
A: They should treat shared libraries, build scripts, and package resolution rules as part of the control surface. In monorepos, one dependency change can affect many services, so governance needs graph-based visibility, release coordination, and prioritisation based on downstream impact.
Technical breakdown
Why transitive dependencies create blind spots in AppSec
A direct dependency is explicitly declared in a manifest, while a transitive dependency arrives through another package, library, or module. Security tools that only inspect top-level manifests can miss those deeper relationships, especially when package managers resolve dependencies differently across ecosystems. That creates a structural blind spot: the vulnerable component exists in the build or runtime path, but not in the simple inventory AppSec teams use for triage. In large estates, this gap is amplified by multiple repositories, shared libraries, and inconsistent metadata quality.
Practical implication: inventory dependency paths at build time, not just declared packages, or hidden vulnerable components will stay outside triage.
How multi-dependency graphs correlate manifests, files, and build scripts
A multi-dependency graph is a relationship model that links software components across manifests, configuration files, repositories, and package ecosystems. Instead of treating each file as an isolated list, it maps how one dependency selection influences the broader application graph. That matters because a single component can appear harmless in one repository but become risky when combined with another package or when a shared module is reused across services. The graph turns fragmented dependency data into a system view that security teams can reason about.
Practical implication: use graph-based dependency modelling to unify security decisions across repositories, languages, and shared modules.
Why runtime exposure matters more than package counts
Finding a vulnerable package is not the same as proving exploitability. Runtime exposure depends on whether the code path is actually invoked, whether the vulnerable component is reachable, and whether surrounding controls limit impact. The article’s central governance point is that teams need correlation, not just enumeration, so they can distinguish theoretical presence from operational risk. In practice, that moves AppSec closer to risk-based prioritisation and away from static dependency counting.
Practical implication: prioritise dependency findings by reachability and runtime context rather than by raw count alone.
Threat narrative
Attacker objective: Exploit hidden dependency paths to reach vulnerable code or propagate supply chain compromise into production systems.
- Entry begins when a vulnerable transitive dependency is introduced through a direct package selection or shared module chain.
- Credential or code execution risk increases when that component is built into applications, pipelines, or monorepo projects without full dependency visibility.
- Impact occurs when the vulnerable path is reachable at runtime and security teams have not correlated it back to the originating dependency chain.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
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 has become a software supply chain governance problem, not just an AppSec reporting problem. The article shows that direct manifests are insufficient when risk travels through nested packages, shared modules, and build logic. That means governance has to follow the dependency path, not the top-level package list. Practitioner conclusion: treat dependency visibility as an operational control, not a static inventory exercise.
Hidden dependency risk is a form of posture management debt. When teams cannot trace component relationships across languages and repositories, they accumulate unknown exposure that cannot be triaged accurately. This is especially acute in monorepos, where one change can affect multiple services. Practitioner conclusion: reduce structural blind spots before they become remediation backlog.
Supply chain security and identity governance intersect at build trust. Multi-dependency graphs help show what software enters the pipeline, but they do not by themselves govern who or what is allowed to move that software forward. CI credentials, signing keys, and deployment permissions remain the control layer that determines whether a discovered dependency risk can become an actual release risk. Practitioner conclusion: pair dependency mapping with tight governance over build and release identities.
Runtime reachability is the decisive concept here, because not every vulnerable dependency is operationally relevant. Security teams need a named concept for this gap: dependency reachability blind spots: the cases where a vulnerable component exists in the graph but cannot be tied to executable exposure quickly enough to guide action. Practitioner conclusion: optimise triage for reachability, not for raw alert volume.
Traditional AppSec tooling will keep missing the same class of issue until dependency relationships are treated as first-class security data. The article points to a broader market shift toward contextualised software risk analysis, where component relationships, runtime impact, and remediation priority are evaluated together. Practitioner conclusion: build workflows that join SBOM-style visibility, graph context, and change control.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Multi-Agent and A2A Security Guide
What this signals
Dependency reachability blind spots are now a material AppSec governance issue because teams cannot prioritise what they cannot trace across manifests, build logic, and runtime paths. The practical response is to shift from package-level review to relationship-level control, so exposure is assessed where code can actually execute.
Monorepos make this problem more visible because a single shared component can affect multiple applications at once. That means dependency intelligence should sit alongside release governance and CI identity controls, not as a separate inventory exercise.
Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs, which is a useful reminder that build and release authority often remains less governed than the software it moves.
For practitioners
- Map transitive dependency paths across all build inputs Include manifests, lockfiles, build scripts, and shared libraries so the security team can see the full dependency chain rather than only direct packages.
- Prioritise findings by runtime reachability Use application context to separate packages that are merely present from those that can actually execute or affect production behaviour.
- Correlate dependency data across repositories and languages Unify package intelligence into one graph view so duplicate components and cross-project propagation are visible during triage.
- Tighten release authority for build and deployment identities Limit which CI service accounts, signing keys, and deployment tokens can promote code after a vulnerable dependency is identified.
Key takeaways
- Transitive dependencies can hide real application risk even when direct manifests appear clean, because vulnerable code often enters through nested package relationships.
- Multi-dependency graphs matter because they connect files, repositories, and languages into one view that improves triage and exposure analysis.
- The practical control question is no longer how many dependencies exist, but which dependency paths can actually affect runtime and release trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Dependency graphs address incomplete inventory of software components and their relationships. |
| Recommendation — Build a complete dependency inventory across manifests, repositories, and package managers. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | The article is fundamentally about inventorying software components before risk can be managed. |
| Recommendation — Extend asset inventory practices to software dependency relationships and build inputs. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | The article’s central concern is secure software supply chain management and visibility. |
| Recommendation — Track and govern software supply chain components with continuous visibility and prioritised remediation. | ||
| SLSA | L2 — Build integrity | The article intersects with build provenance and dependency integrity in the software supply chain. |
| Recommendation — Verify build provenance so transitive dependency risk cannot silently enter release pipelines. | ||
| MITRE ATT&CK | TA0007;TA0010 — Discovery; Exfiltration | Hidden dependency risk can be exploited after discovery and lead to downstream impact. |
| Recommendation — Map exposed dependency paths to discovery and exfiltration tactics in detection engineering. | ||
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.
- Multi-Dependency Graph: A multi-dependency graph is a visual model that maps relationships across files, repositories, build artefacts, and nested packages. It helps security teams understand how software components connect, where risk enters, and how a flaw in one part of the chain can propagate into others.
- Runtime Reach: The total set of identities, repositories, tools, memory paths, and services an autonomous system can actually access while executing a task. It is broader than the workflow that was originally approved, and it determines the real governance boundary for agent behaviour.
- Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to govern build and release trust. It helps security teams connect identity controls to the software supply chain decisions that affect delivery risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org