Why does code reachability matter more than package presence?

Why This Matters for Security Teams

Package presence is a supply-chain signal, but it is not a runtime risk signal. Security teams care about reachability because exploitation depends on whether production code paths can actually invoke the vulnerable function, method, or transitive dependency. That distinction changes triage: a library may be installed in many services, yet only one service may expose the vulnerable path. Guidance in the NIST Cybersecurity Framework 2.0 reinforces the need to identify, prioritize, and respond based on real asset and exposure context, not inventory alone.

This is especially important where package sprawl is high and dependency graphs are deep. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means a broad inventory often overstates practical exposure while still missing the paths that matter most. A reachable vulnerable package in a production service is a materially different problem from a dormant package in a test-only module. In practice, many security teams discover the difference only after a scanner flood has already buried the few exploitable findings that actually matter.

How It Works in Practice

Reachability analysis traces whether vulnerable code can be invoked from an application’s runtime entry points. That usually means combining package inventories, call graphs, build metadata, and runtime context to determine whether a given flaw sits on an executable path. In mature programs, teams use this to rank findings so that remediation targets live services first, while lower-priority issues remain tracked until they become reachable.

Operationally, the workflow is straightforward:

• Inventory dependencies and map them to the services, containers, or functions that actually ship.
• Trace code paths from public or internal entry points to the vulnerable function or class.
• Confirm whether the triggering condition is reachable in the deployed configuration, not just in source.
• Pair reachability with exploitability context such as auth requirements, network exposure, and privilege level.
• Use policy and ticketing rules to escalate only reachable issues that sit on production paths.

That workflow aligns with broader software assurance practice in the NIST Cybersecurity Framework 2.0, where asset context and risk-based response drive prioritisation. It also helps teams interpret real incidents more accurately, including the LiteLLM PyPI package breach, where package-level compromise and downstream usage need to be understood separately. NHIMG’s Ultimate Guide to NHIs is useful here because runtime reachability often intersects with non-human identities, secrets, and service-to-service permissions. These controls tend to break down when applications rely on dynamic plugin loading, reflection, or heavily customized CI/CD builds because static analysis cannot always prove which paths are truly invoked.

Common Variations and Edge Cases

Tighter reachability analysis often increases engineering and tooling overhead, requiring organisations to balance faster triage against the cost of deeper inspection. Current guidance suggests treating reachability as a prioritisation layer, not a replacement for dependency hygiene, because some risks remain important even when a path is not obviously exercised.

There are several edge cases. A package may appear unreachable in one deployment but become reachable through feature flags, tenant-specific configuration, or future code changes. A library may also be dormant in production yet still matter if it is loaded by admin tooling, batch jobs, or agent-driven automation that runs with elevated access. This is why best practice is evolving toward combining package presence, reachability, and runtime telemetry rather than relying on a single score.

Reachability is also harder in polyglot services, generated code, and serverless environments where the execution graph is fragmented. In those cases, teams should treat “not proven reachable” as a temporary assessment, not a permanent exemption. NHIMG research on the LiteLLM PyPI package breach underscores why this nuance matters: package exposure alone does not tell the whole story, but neither does a narrow static view when deployment patterns change quickly.

Related resources from NHI Mgmt Group

• Why does identity matter more when vulnerabilities are discovered faster than they can be patched?
• Why do still-valid secrets matter after public disclosure?
• How should teams reduce risk from malicious npm package installs?
• Why do code reachability and false-positive triage matter in AppSec programmes?