Reachability Predicts. Runtime Proves.

Reachability answers one question: can this code execute. Exploitability answers a different one: can an attacker actually use it. For most of 2025, the AppSec industry treated these as the same question. In the first half of 2026, that stopped being true, and almost every vendor in the category noticed at once.

Checkmarx published a piece in March arguing that "reachability is not exploitability" and introduced Attackability, an AI-driven triage layer that traces attacker-controlled input from ingress points to a candidate sink. Endor Labs shipped AURI to catch vulnerable code inside coding assistants before it ships. Aikido added container-level reachability, mapping network routes to running workloads. Three companies, three different products, one shared conclusion: knowing a vulnerable function sits on a call path is not enough.

They are right that reachability alone is not enough. Where the field still splits is on what closes the gap. Most of it is smarter tracing of source code. A smaller number of platforms, Kodem among them, close the gap by watching the process run.

What reachability actually measures

Reachability analysis exists in three flavors, and they answer three different questions.

Code-level reachability walks the call graph: is there a static path from your entry points to the vulnerable function? It is fast and broad, and it is also the noisiest signal in the stack, because a path existing in source does not mean anything ever walks it in production.

Container-level reachability checks what shipped: is the vulnerable package present in the image that actually deployed? Better than a manifest, still blind to whether the process loaded it.

Runtime reachability checks execution: did the process load the library, and did it call the specific vulnerable function. This is the only one of the three that observes rather than infers.

Checkmarx's Attackability improves the first category. It is a real improvement over plain reachability, five steps of static analysis that trace attacker-controlled input, validate preconditions, and check whether a control on the path already breaks the chain. But every step in that chain is still inference from source and configuration. It is a better model of what might happen. It is not a record of what did.

Reachable and executed are not the same fact

Here is where the gap actually lives, worked through two concrete cases from production traffic.

CVE-2025-29927 was a Next.js authentication bypass triggered by manipulating the x-middleware-subrequest header. To infrastructure monitoring and to static tracing, the request looks like normal HTTP: a header, a socket write, ordinary memory activity. Nothing about the request shape screams exploit. What distinguishes an attack from a false positive is whether the middleware function it hits behaves differently than its baseline, whether the header actually flips the code down the unauthenticated path. That is an execution fact, not a source fact. Static tracing can flag the header as attacker-controlled input and stop there; observing the function's actual execution is what tells you the bypass fired.

Spring Cloud Function's reflection-based injection is a sharper version of the same problem. An attacker sends a spring.cloud.function.routing-expression header carrying a SpEL payload that reaches Runtime.exec(...). A legitimate process spawn and a malicious one produce the identical syscall trail: app code to ProcessBuilder to execve. The only way to tell them apart is the call stack that got there, SpEL evaluator to Method.invoke to Runtime.exec, which is a runtime fact, not something visible in a dependency graph or a header inspection pass.

Both cases share a structure. The vulnerable code is reachable by every definition above. Static tracing, even excellent static tracing, can tell you the shape of the risk. Only observing the function actually execute, with the actual call stack that got it there, tells you whether this specific request was the exploit or a coincidence.

Runtime is the only layer that observes instead of infers

Kodem's runtime sensors (the Kortex family: Komon, Kolibri, Koltan, Komet, Kompanion) sit inside the customer's own environment and use eBPF kernel instrumentation plus memory forensics to answer a narrower, harder question than reachability tools ask: not "could this run," but "did this run, and which function, and in what call stack." The distinction Kodem draws between reachable (present in source and on an executable path) and exploitable (a proof-of-concept condition actually fires) is the same distinction the field is now converging on under different names. Attackability is a static approximation of it. Runtime observation is the fact itself.

This is not a claim that static tracing is worthless. Attackability and its equivalents narrow the funnel before code ships, which is real and valuable. It is a claim that narrowing is not the same operation as confirming, and a security team that treats a well-traced static verdict as equivalent to an execution-confirmed one is trading one kind of noise for a quieter, more convincing kind of noise.

What changes when execution is the evidence

Once a finding carries execution evidence instead of a static verdict, three things change. Triage stops being an argument about assumptions, because the platform can show the specific function call and the specific stack, not a probability. Remediation gets easier to sequence with Kodem's runtime-powered SCA, because a team can tell the difference between "reachable everywhere" and "executed here, under this condition, from this ingress point." And revalidation becomes continuous rather than a one-time judgment call: a finding that is not exploitable today under current conditions gets re-checked automatically when the application's runtime behavior changes, rather than staying silently deprioritized forever, the same principle behind Kodem's ADR detecting the start of an exploit rather than just its aftermath.

The industry will keep inventing new words for the gap between theoretical and real risk. Attackability this year, something else next year. The fact underneath the vocabulary does not move: a vulnerability only matters if it executes, and the only way to know that it executed is to watch it happen.

Frequently asked questions

Is reachability analysis useless?

No. Reachability, at any of its three layers, is a legitimate and useful pre-deployment filter. It narrows a large finding set to a smaller, more plausible one. It is a prediction, and predictions are worth having. They are just not proof.

Is Attackability the same thing as runtime validation?

No. Attackability, as Checkmarx describes it, traces attacker-controlled input through source code and configuration to a candidate sink using AI-assisted static analysis. It does not observe the running application. It is a more sophisticated prediction, not an observation.

What does Kodem observe that static tools cannot?

Function-level execution: which libraries actually loaded, which functions actually ran, and the actual call stack that reached them, collected via eBPF and memory forensics from inside the customer's own environment, never by inferring from source code alone.

References

• Kodem Security. (2024, December 4). A comparative study of reachability analysis in application security. Kodem. kodemsecurity.com
• Latio Pulse. (2024). Comparing static and runtime reachability. Latio. pulse.latio.tech
• Oligo Security. (2024). Loaded vs. executed libraries. Oligo. oligo.security
• Spiegel, R. (2026, March 24). Attackability: Why context, not reachability, should drive remediation. Checkmarx Blog. checkmarx.com