Dependency Reachability

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.

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?