Dependency reachability is the question of whether a vulnerable library or function can actually be invoked in the deployed application path. It matters because not every disclosed package flaw creates equal risk. Teams use it to separate theoretical exposure from issues that can be exploited in practice.
Expanded Definition
Dependency reachability extends beyond package-level vulnerability scanning by asking whether a vulnerable dependency is actually present in the runtime call path of the deployed application. In NHI and Agentic AI environments, that distinction matters because a flaw in a transitive library, plugin, or tool wrapper only becomes actionable if the code path can be invoked under real execution conditions.
The term is often used alongside software composition analysis, but it is narrower and more operational: it focuses on exploitability in context, not just the existence of a CVE or advisory. Guidance varies across vendors on how much dynamic evidence is required, and no single standard governs this yet. Some teams treat static import graphs as sufficient, while others require runtime traces, test coverage, or environment-specific execution proof. For governance purposes, dependency reachability is a control signal for prioritisation, not a replacement for patching or secure build practices.
The most common misapplication is treating every vulnerable dependency as equally urgent, which occurs when teams ignore whether the code path is actually reachable in the deployed configuration.
Examples and Use Cases
Implementing dependency reachability rigorously often introduces analysis overhead and build complexity, requiring organisations to weigh triage precision against scan latency and engineering effort. That tradeoff is worthwhile when modern supply chain incidents show how package compromise can spread through widely reused components, as seen in the LiteLLM PyPI package breach.
- A service imports a vulnerable library only in a disabled admin feature, so the finding is deprioritised until that feature is enabled in production.
- An AI agent framework bundles a tool adapter with a known flaw, but telemetry shows the adapter is never called in the deployed workflow.
- A transitive dependency is reachable only in integration tests, not in the production container, so remediation is scheduled with lower urgency.
- A security team uses NIST Cybersecurity Framework 2.0 style risk prioritisation to focus on reachable exposure rather than raw vulnerability counts.
- NHI governance teams correlate dependency reachability with secret exposure paths to determine whether a compromised component could touch API keys or service account tokens.
Why It Matters in NHI Security
Dependency reachability is important in NHI security because non-human systems often rely on dense dependency trees, automated build pipelines, and reusable agent toolchains. When reachability is ignored, teams can waste effort patching unused code while missing the components that actually handle credentials, tokens, certificates, or external API calls. That leads to weak remediation prioritisation, overbroad alerts, and a false sense of safety in environments where machines execute far more of the workflow than humans do.
NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. In practice, a vulnerable dependency becomes most dangerous when it sits inside a secret-handling path, an agent tool invocation, or an automation chain with privileged access. reachability analysis helps teams determine whether a package flaw is merely present or actually exploitable in a live NHI workflow. It also supports more disciplined decision-making when organisations must distinguish a noisy advisory feed from a real exposure that can be abused. Organisations typically encounter the operational significance of dependency reachability only after a breach investigation shows the vulnerable library was callable from the path that handled secrets, at which point the concept becomes unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Reachability helps separate exploitable dependency exposure from theoretical package risk. |
| NIST CSF 2.0 | ID.RA-5 | Risk analysis should consider whether a weakness is actually exploitable in context. |
| NIST AI RMF | AI systems require context-aware risk identification for code paths and tool use. |
Prioritise only reachable vulnerable dependencies in NHI pipelines and remediate those in active execution paths first.
Related resources from NHI Mgmt Group
- When does a dependency compromise become an identity incident?
- How should teams slow down malicious dependency updates without breaking delivery?
- What is the difference between automating dependency updates and granting them blind trust?
- Should organisations allow pull_request_target for automated dependency workflows?
