What do teams get wrong about runtime application security when they treat every detected library as equally exploitable?

Why Teams Misread Reachability as a Binary Finding

runtime application security is most useful when it separates “present in the image or process tree” from “reachable in the execution path.” Teams often flatten those into one severity bucket, but exploitability depends on whether the application actually loads, calls, or exposes the vulnerable code in the current deployment. That distinction matters because runtime findings are about operational exposure, not inventory completeness.

The practical failure is prioritising every detected library as if it sits on the hot path. That creates alert fatigue, wastes engineering time on dormant code, and pushes real reachable flaws down the queue. In application security, reachability is the difference between a theoretical issue and an issue that can actually change runtime behaviour.

For teams that need a baseline control view, NIST Cybersecurity Framework 2.0 is useful for organising governance around identify, protect, detect, respond, and recover, but it does not replace reachability analysis inside the application itself. In practice, many teams discover this only after developers stop trusting the scanner output rather than after a real exploit attempt.

How Reachability Changes the Security Signal

Runtime application security should answer a narrower question than traditional software composition analysis: is this library reachable from the code path, request path, or runtime condition that exists right now? A vulnerable package that is bundled but never invoked may still matter for hygiene, future exposure, or build governance, but it does not carry the same immediate operational risk as a dependency actively handling user input.

That is why runtime tools need execution context. The better signals usually combine:

• call graph or instrumentation data showing whether the code path is executed;
• package and symbol resolution showing where the dependency sits in the runtime;
• request, job, or message flow showing whether an attacker can influence the vulnerable function;
• environment data showing whether the vulnerable component is even enabled in this deployment.

This is also where teams mis-handle prioritisation. A low-numbered CVE in an unreachable helper may be less urgent than a moderate issue in a library that parses attacker-controlled input on every request. If the runtime evidence does not show exposure, the finding should usually be tracked differently from a live exploit path. For application-specific verification of authentication, session handling, and access control that often sit alongside these decisions, OWASP ASVS gives a stronger control lens than package presence alone.

Teams also need to separate “never reachable in this release” from “not reachable yet because the feature flag is off” and “not reachable because a compensating control blocks it.” Those are different operational states with different remediation choices. These controls tend to break down when instrumentation is incomplete, feature flags are reused across environments, or build-time dependency data is treated as proof of live exploitability.

Common Variations and Edge Cases

Tighter runtime filtering often reduces noise, but it also increases the burden on telemetry quality and deployment-specific analysis, so teams have to balance precision against observability cost. The edge cases are where simplistic rules fail most often.

Current guidance suggests treating the following cases separately rather than forcing one severity model across all findings:

• a library present in the container image but not loaded by the application;
• a vulnerable function that is only reachable in admin flows or rare error paths;
• a dependency that is unreachable in one environment but active in another;
• a dormant component that becomes reachable after a feature release or configuration change;
• a vulnerable transitive dependency that is masked by wrapper logic until a specific input pattern appears.

For containerised workloads, runtime reachability should be read alongside image, orchestration, and deployment controls rather than as a replacement for them. NIST SP 800-190 Container Security helps teams keep image, registry, orchestrator, and runtime risk distinct, which is important when a library exists in the artifact but never becomes part of the active attack surface. The common mistake is assuming that one scan result can answer both supply-chain hygiene and live exploitability at the same time.

For prioritisation, runtime evidence should usually override raw inventory volume, but not override architecture knowledge. If a library is dormant today and can become reachable through a planned configuration change, it still deserves a tracked remediation path even if it is not the top runtime exposure now.

Risk and Threat Considerations

The risk is overestimating exposure and underestimating the noise created by undifferentiated findings. That weakens triage, hides truly reachable flaws, and can create a false sense of progress when teams burn effort on dormant dependencies instead of exploitable paths.

Failure mechanism: Scanners and bill-of-materials tools often report what is present, while attackers care about what is reachable, invoked, and influenceable. When teams do not separate those states, they may miss a vulnerable function on the live request path while over-rotating on unused code.

Impact: The practical impact is slower remediation of real attack paths, poorer engineer trust in security findings, and a larger unresolved blast radius in the code that actually processes runtime input.

Practitioner Guidance

What to prioritise: Prioritise findings with proof of execution, attacker influence, or exposure on the active request path before dormant library issues. If a finding cannot be tied to a live code path, track it as hygiene or future risk instead of treating it as an immediate exploit path.

What to verify: Verify whether the vulnerable symbol is loaded, whether the code path is executed in the deployed environment, and whether an attacker can reach it through normal traffic or a state change. If any of those are unknown, the finding is not ready for high-confidence severity ranking.

Decision rule: If the dependency is present but unreachable, lower the urgency unless there is a clear path for it to become reachable through configuration, feature release, or environment drift. If it is reachable and attacker-influenced, treat it as materially more urgent than a dormant CVE with the same score.

Practitioner takeaway: runtime security is about exposure, not mere existence, and the best teams measure exploitability by execution context rather than by how many vulnerable packages a scanner can enumerate.

Related resources from NHI Mgmt Group

• What do security teams get wrong about treating every reported vulnerability as equally urgent?
• What do security teams get wrong when they treat CSPM as enough for application risk?
• What do teams get wrong about application security testing when they depend on one scanning method?
• What do teams get wrong about ASPM when they treat it like another point security tool?