Why does runtime reachability matter more than package inventory?

Why runtime reachability changes the triage model

Runtime reachability answers a different question from package inventory: not “what is present?” but “what can actually be invoked in this environment?” That matters because exposure is only operational when the vulnerable code path is reachable by the running application, service, or workload. In practice, reachability turns a long list of theoretical findings into a smaller set of issues that deserve immediate attention.

Package inventory is still useful as a discovery baseline, but it is a weak prioritisation signal on its own. A dependency may be installed yet unused, loaded but not exercised, or present only in a code path that the deployment never takes. Reachability analysis helps separate latent risk from active risk, which is why it is more useful for remediation order and decision-making.

When the subject is runtime exposure, the control question becomes whether the vulnerable component sits on an execution path that matters to the deployed application. That distinction is especially important in containerised and service-oriented environments, where image content, transitive dependencies, and runtime behaviour often diverge. For that reason, runtime-focused guidance such as NIST SP 800-190 Container Security is a better fit than a flat inventory view when teams need to understand how package presence translates into actual exposure.

What package inventory misses about real exposure

Inventory produces breadth, not context. It can tell you that a library exists in a build artifact, but it does not tell you whether the vulnerable function is called, whether the vulnerable code is behind a feature flag, or whether the package is only present for compatibility and never executed. That is why inventory often overstates the number of urgent findings and creates triage noise.

Reachability narrows that field by testing whether the vulnerable symbol, method, route, or execution path can be triggered from the deployed application state. In other words, it connects static presence to dynamic use. For teams dealing with software supply chain exposure, this is a more decision-useful view of risk than dependency counting alone, which is also why supply chain guidance from projects like OpenSSF tends to emphasise integrity and provenance alongside dependency awareness.

This distinction becomes even clearer in package-breach scenarios. A package incident can be serious even before a vulnerable function is reached, but operational prioritisation still depends on whether the affected component sits on a path that the workload can actually use. The LiteLLM PyPI package breach is a good example of why package presence alone is not enough: inventory may show exposure, but runtime assessment is what tells you whether a deployed service can be impacted through the live attack surface.

How to use reachability without losing visibility

Reachability should not replace inventory, it should refine it. Inventory gives coverage, reachability gives prioritisation, and the two together give a practical remediation queue. The best workflow is to keep the complete package view for governance and auditability, then layer runtime or code-path evidence on top so engineers can focus on findings that affect live services first.

That approach is strongest when combined with environment context. A package might be reachable in one deployment, but not in another because of different flags, routes, permissions, or service composition. Teams that treat every finding as equally urgent usually waste effort chasing dormant exposure, while teams that ignore inventory entirely risk missing the broader asset picture. The right answer is to use inventory for completeness and reachability for operational consequence.

The same principle appears in broader identity and access hygiene work, where visibility is necessary but not sufficient. For example, the NHI lifecycle and issue-management guidance in NHI Lifecycle Management Guide and Top 10 NHI Issues show the same pattern: inventory identifies what exists, but lifecycle and exposure analysis determine what is actually risky enough to act on now.

Practitioner Guidance

What to prioritise: Prioritise findings that are both vulnerable and reachable in the deployed runtime, then push “present but unreachable” issues into a lower remediation queue unless another control makes them material. That keeps engineering effort aligned with actual attack surface.

What to verify: Verify that the reachability signal is tied to the same build, image, and deployment configuration you are assessing. A stale analysis on the wrong artifact can be worse than no reachability data at all because it creates false confidence.

Common mistake: Do not treat package inventory as a severity model. It is a discovery mechanism, not a proof of exploitability, and it should not be used to rank work without runtime evidence.

Practitioner takeaway: The useful question is not how many vulnerable packages exist, but which ones can actually influence the running system, because only those findings change real operational risk.

Related resources from NHI Mgmt Group

• Why does code reachability matter more than package presence?
• Why do runtime reachability and cloud exposure matter more than static severity scores?
• Why do runtime and build-time reachability signals matter for vulnerable code?
• Why do runtime checks matter more than package inventories for this flaw?