How can security teams tell whether an application dependency is actually reachable?

Why This Matters for Security Teams

Reachability is the difference between a dependency that merely exists in a codebase and one that can actually be invoked from a running service path. Package scans miss that distinction, which is why teams can overprioritise dormant versions while missing the applications, APIs, and environments that truly expose the vulnerable code. NHI Management Group’s research on the Ultimate Guide to NHIs shows how visibility gaps compound real risk: only 5.7% of organisations report full visibility into service accounts, and that same blind spot often extends to service-to-service reachability.

This matters most when dependencies sit behind internal APIs, job workers, or CI/CD runners that are assumed to be “safe” because they are not internet-facing. In practice, attackers do not care whether a vulnerable package is installed everywhere; they care whether a reachable path exists from a compromised host, token, or workflow. Security teams should treat reachability as an exposure question, not a software inventory question, and combine dependency data with service maps, routing, and trust boundaries. The State of Non-Human Identity Security reinforces why this view matters: visibility gaps are common across non-human access paths, and those same gaps undermine prioritisation. In practice, many security teams discover reachable dependencies only after an exploit path has already been exercised in production.

How It Works in Practice

The useful workflow starts with service-level inventory, then traces where each application is deployed, which routes or listeners it exposes, and what identities can invoke it. That means correlating build artifacts, runtime inventories, ingress rules, service meshes, and cloud security groups with dependency manifests. A package may appear in dozens of services, but only a subset will be reachable from external users, partner networks, or other internal workloads with broad blast radius.

Teams often use a layered approach:

• Map the vulnerable dependency to deployed services, not just repositories.
• Identify reachable entry points such as public routes, internal APIs, queues, and scheduled jobs.
• Confirm whether the service accepts traffic from outside the trusted network or from broadly trusted service accounts.
• Check whether the vulnerable code path is callable in the service’s normal runtime configuration, not just present in the image.
• Use policy and telemetry to distinguish exposed production paths from dormant test, staging, or disabled features.

This is where NIST SP 800-53 Rev 5 Security and Privacy Controls is useful operationally: inventory, configuration management, and boundary enforcement controls help prove whether a dependency is reachable in a given environment. For practitioners, reachability becomes a runtime question answered by deployment state, network path, and authentication context, not by dependency metadata alone. Current guidance also aligns with the broader principle in NIST-led asset and control discipline, even though there is no universal standard for reachability scoring yet. These controls tend to break down in highly dynamic container platforms with ephemeral services and permissive east-west networking because the service map changes faster than scanning cycles.

Common Variations and Edge Cases

Tighter reachability analysis often increases operational overhead, requiring organisations to balance faster triage against the cost of maintaining accurate runtime context. That tradeoff is especially visible in multi-tenant platforms, service mesh environments, and event-driven systems where a dependency may be dormant in one path and exploitable in another.

One common edge case is a package that is only reachable through authenticated internal calls. That does not make it safe, but it does change the exposure model: the issue may depend on compromised credentials, overly broad service permissions, or lateral movement rather than direct internet access. Another edge case is feature-flagged code, where a vulnerable dependency appears unreachable until a flag flips during incident response or a rollout.

Security teams should also be careful with container and serverless workloads. A function or image can appear unreachable from the outside while still being callable by orchestration events, queue messages, or CI/CD automation. The LiteLLM PyPI package breach is a reminder that supply-chain exposure often becomes practical only when runtime trust and secret handling intersect. Best practice is evolving toward combining SBOM data, runtime telemetry, and policy evaluation, because there is no universal standard for reachability validation across all deployment models yet. In the hardest environments, stale inventory and shared credentials make a dependency look unreachable right up until a real request path proves otherwise.

Related resources from NHI Mgmt Group

• How can security teams tell whether an AI agent compromise is actually contained?
• How can security teams know whether n8n-style exposure is actually dangerous?
• How do security teams know whether remote access edge devices are actually protected?
• How can security teams tell whether a container escape risk is really a host-kernel problem?