How should AppSec teams prove whether a vulnerable dependency is actually exploitable in production?

Why Runtime Evidence Matters More Than a Vulnerability Flag

A dependency being present in a bill of materials or scanner output only proves exposure in the abstract. AppSec teams need to know whether the vulnerable code path is reachable in the real production path, because that changes the operational meaning of the finding from “possible” to “likely exploitable.” Static presence checks create noise when teams assume every CVE has the same urgency. Runtime evidence, by contrast, ties the finding to an executed function, a live service, and a concrete request path.

That distinction matters because exploitability is shaped by context: input reachability, authentication boundaries, service exposure, and whether the vulnerable routine is even exercised under normal traffic. The right evidence reduces false positives, improves remediation priority, and gives engineering leaders a defensible basis for scheduling fixes. For a control-oriented baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful when teams want to anchor evidence handling and monitoring expectations in a broader governance model. In practice, many security teams discover a vulnerable dependency only after production telemetry has already shown whether the code path was active.

What Counts as Proof in Production

Proof is strongest when it shows a real execution chain, not merely an installed package. A call stack, trace, or runtime instrumentation record can show that a vulnerable function was actually reached, which service reached it, and what triggered the call. That makes the finding operationally different from an inventory item that may never be exercised. Teams should treat the question as one of reachability and execution context, not version matching alone.

Useful evidence usually comes from production observability rather than from the dependency scanner itself. Examples include application traces, exception telemetry, request logs with function-level correlation, eBPF or APM instrumentation, and targeted reproductions in a controlled environment when production evidence is incomplete. A strong proof chain typically answers three questions:

• Was the vulnerable function invoked?
• Was the invocation reachable from a production request or job?
• Was the invocation on a code path that could plausibly be influenced by untrusted input or attacker-controlled state?

That last question is where many assessments break down. A vulnerable library can be present but unreachable because the code path is disabled, gated, or reserved for maintenance workflows. Conversely, a function can be reachable yet still not materially exploitable if the necessary preconditions are absent. AppSec teams should also distinguish direct exploitation evidence from indirect indicators such as dependency presence, because presence alone does not prove runtime exposure. The guidance breaks down when instrumentation is missing, traces are not retained long enough, or the team cannot correlate execution data back to the exact service build in production.

When Reachability Is Clear and When It Is Not

Tighter proof standards often increase operational effort, requiring organisations to balance faster triage against stronger confidence in the result.

There is no single consensus method that fits every stack. Some teams use dynamic tracing to validate invocation, while others rely on request-level telemetry, code coverage from production-like replay, or security testing in a mirrored environment. The key judgement is whether the evidence demonstrates actual execution in the production path, not whether the library could theoretically be triggered. If the team cannot show a call path, the finding should usually remain “potentially exploitable” rather than “confirmed exploitable.”

Edge cases matter. A vulnerable dependency may sit behind feature flags, admin-only routes, background jobs, or asynchronous workers. In those cases, the question is not simply whether the package is loaded, but whether the vulnerable branch is reachable under normal operating conditions. In high-throughput systems, teams may need to sample traces rather than capture every request. In regulated or high-assurance environments, teams may need stronger evidentiary standards before accepting residual risk, because the burden of proof shifts from curiosity to accountability. If the dependency is invoked only in non-production test flows, or the service is isolated from attacker influence, exploitability may remain theoretical even though the vulnerability is real.

Practitioner Guidance

What to prioritise: Start with evidence that ties the vulnerable function to a live production execution path, then use that evidence to rank remediation above findings that are only inventory-based. Presence alone should not drive the same urgency as confirmed reachability.

What to verify: Confirm that the trace, stack, or telemetry maps to the exact deployed build and not to a lab instance, stale log line, or unrelated service. Verify both invocation and context, because a function call without a reachable attacker-controlled path is a weaker signal than a call that sits on an internet-facing or untrusted-input path.

Decision rule: Treat the dependency as confirmed exploitable when production evidence shows the vulnerable routine is executed in a path that can be influenced by real traffic, jobs, or external input. Treat it as unconfirmed when you only have version data, package inventory, or a static scan finding.

Practitioner takeaway: The most defensible exploitability judgement comes from linking the vulnerable code to a real production execution path, not from proving that the package exists somewhere in the estate.

Related resources from NHI Mgmt Group

• How do security teams know whether a vulnerable React package is actually exploitable?
• How do teams know whether a vulnerable dependency is actually risky?
• How do teams prove whether a candidate issue is actually exploitable?
• How do security teams know whether a framework deserialization issue is actually exploitable in production?