Topic starter
02/08/2026 11:32 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “Why AppSec Teams Need a Multi-Dependency Graph”.
By the numbers:
- OXSecurity says there are 30+ disclosures and 10+ CVEs to explore in this new dependency-management reality.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Transitive dependencies can hide real application risk even when direct manifests appear clean, because vulnerable code often enters through nested package relationships.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:47 pm
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.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Multi-dependency graphs expose hidden AppSec risk in transitive dependencies