Reachability vs Exploitability

Severity and reachability alone still leave the wrong list

Static analysis surfaces every vulnerability it can find. Reachability analysis narrows that list to functions that sit on a possible code path. Both are useful. Neither tells you whether the vulnerable code actually ran where an attacker could touch it.

So teams inherit a queue ordered by CVSS or by "reachable," and most of it never executes in production. The work feels endless because the list was never the right list. The problem was never a lack of findings. It was a lack of context about which findings matter.

Three signals get used interchangeably. They answer different questions.

Reachability is a prediction. Reachability analysis uses call-graph analysis to determine that a vulnerable function can be reached from your code. It is a strong static signal, and it is now standard across the category. A reachable function is not necessarily a loaded, executed, or exposed one.

EPSS and CVSS are probability and severity. EPSS estimates the likelihood a CVE is exploited somewhere in the wild. CVSS scores theoretical severity. Both are population-level signals. Neither knows anything about what is running in your specific environment.

Exploitability, confirmed at runtime, is evidence. Kodem observes the live application to confirm whether the vulnerable component was opened, read, loaded into memory, and invoked during execution. That is the difference between a finding that might matter and one that demonstrably does. Reachability and EPSS narrow the field. Runtime evidence settles it.

Reachability vs exploitability, side by side

How Kodem confirms exploitability

1. Collect across code, container, and runtime. Kodem C.O.R.E. maps dependencies and call graphs from source, inspects container images, and uses an eBPF sensor to observe runtime behavior with low overhead and no code instrumentation or application restarts.
2. Correlate static findings with live behavior. Findings from code and dependencies are tied to what the running application actually does, so a theoretical risk and a live one are no longer treated the same.
3. Confirm via memory analysis. Kodem validates whether the vulnerable file was opened or read, whether the vulnerable function was loaded into memory, and whether it was invoked during execution. That is the evidence that turns a maybe into a yes.
4. Act on the few that matter. Teams remediate the confirmed-exploitable set, prioritized with Kai, and detect the first malicious action at runtime where it is needed instead of waiting for a downstream symptom.

What this looks like in practice

At Rapyd, the AppSec team shifted from chasing volume to proving impact by prioritizing only vulnerabilities with runtime evidence of execution, not static predictions. Focusing on what actually ran cut AppSec triage time by 40% and confirmed that 90% of scanner-detected CVEs were not exploitable in their environment, work that used to sit on an engineering backlog by default.

"Most security tools are gym memberships. Kodem is the personal trainer actually helping us get fit." Nir Rothenberg, CISO, Rapyd.

The full mechanics of how memory analysis turns kernel-level signals into function-level proof are in From Reachability to Reality. For teams building a prioritization workflow around this distinction, see automating vulnerability management with runtime evidence.

Frequently asked questions

Is reachability the same as exploitability?

No. Reachability means a vulnerable function can be reached along a code path. Exploitability means that function actually loaded into memory and executed in your running application, where an attacker could trigger it. Reachability is a prediction. Exploitability is evidence.

Does reachability analysis replace runtime evidence?

No. Reachability is a valuable static filter. Runtime evidence confirms what the static filter can only predict, which is why the two are strongest together.

How is exploitability confirmed without instrumenting my code?

Kodem uses an eBPF-based sensor and memory analysis to observe execution from the kernel level, without code changes or application restarts.

What should we fix first, the reachable list or the exploitable list?

Start with the set that is reachable, executed, and exposed. It is smaller than either a severity-ranked or a reachability-ranked queue, and every item on it has evidence behind it instead of a prediction.