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

Why This Matters for Security Teams

A package can be vulnerable on paper and still be irrelevant in production, but AppSec teams cannot assume that distinction without evidence. Static inventory tools tell you what is present; they do not prove whether the dangerous code path is reachable, whether runtime inputs trigger it, or whether compensating controls block abuse. That gap creates noisy triage, wasted fixes, and false confidence.

The practical question is not simply “Is the dependency vulnerable?” but “Can this service actually execute the vulnerable function under real traffic and real context?” Runtime proof matters because exploitability is shaped by request paths, feature flags, deployment topology, and the service’s own invocation patterns. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for evidence-based monitoring and control validation, not assumption-based risk acceptance. NHIMG’s Ultimate Guide to NHIs shows the scale of identity and secret exposure that makes blind trust in inventories especially risky. In practice, many security teams encounter exploitability only after an incident review, rather than through intentional runtime verification.

How It Works in Practice

Proving exploitability requires joining dependency intelligence with runtime telemetry. The most useful evidence is a call stack or equivalent execution trace that shows the vulnerable method being invoked in production, the request or job that triggered it, and the service instance where it occurred. That shifts the discussion from theoretical exposure to observed execution.

A workable process usually includes:

• Identify the vulnerable library and the specific function or class affected.
• Instrument the service to capture stack traces, spans, logs, or eBPF-based runtime signals when that code path executes.
• Correlate the event with the request ID, deployment version, and workload identity.
• Check whether the vulnerable path is reachable from external input, internal jobs, or only test traffic.
• Determine whether mitigations such as input validation, sandboxing, or network controls reduce practical exploitability.

This is where runtime observability complements SBOM and dependency scanning. The 52 NHI Breaches Analysis highlights how often attackers exploit weak operational controls rather than merely “known bad” components. For code-level validation, teams can map findings against the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially monitoring and vulnerability management expectations. The operational goal is to prove reachability with evidence, then classify the issue as exploitable, conditionally exploitable, or not currently reachable.

This guidance breaks down when services are heavily distributed, instrumented inconsistently, or run in short-lived serverless environments where the vulnerable call path cannot be captured reliably.

Common Variations and Edge Cases

Tighter proof of exploitability often increases telemetry overhead, so teams must balance precision against performance and storage cost. That tradeoff becomes sharper in high-throughput systems, polyglot microservices, and legacy applications where full stack tracing is incomplete.

There is no universal standard for this yet, but current guidance suggests treating the following cases differently:

• A vulnerable dependency is loaded but the affected function is never invoked in production.

• The function is reachable only in administrative workflows, batch jobs, or rare error-handling branches.

• A control such as WAF filtering, feature gating, or sanitisation reduces exploitability but does not eliminate it.

• Recompilation, vendoring, or dynamic loading changes whether static results match runtime reality.

Teams should be careful not to confuse “no observed calls yet” with “safe.” The better conclusion is often “not proven exploitable at current telemetry coverage.” That is materially different from a clean bill of health. NHIMG’s LiteLLM PyPI package breach is a reminder that package risk can move quickly from dependency metadata to real operational impact once a vulnerable path is reachable. For gaps in runtime evidence, best practice is evolving toward layered validation that combines scanning, tracing, and targeted testing rather than relying on a single signal.

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?