Reachability Analysis Re-Imagined: From Static Analysis to Runtime Insight

Imagination plays a major part with every technological advancement. It is not about making the existing reality a little better, it is about making it marginally better by thinking about it from a completely different point of view.

Reachability gave us a glimpse of a better future but until we ignored everything we know and allowed ourselves to re-imagine what reachability truly means, we did not enjoy its full promise.

This article explains what reachability analysis is, the two main approaches, and why the distinction between using vulnerable code and executing it changes how security teams prioritize risk.

Key Takeaways

• What reachability analysis is: Reachability analysis is a security technique that determines whether a vulnerability in a dependency is actually reachable and exploitable in a running application, rather than simply present on disk.
• Why it matters: Security teams face thousands of CVE findings and can remediate only a fraction each month, so reachability analysis helps separate findings that require action from those that can be deprioritized.
• Static reachability: Static reachability analyzes code paths before execution and identifies dependencies that could theoretically be called, but it cannot confirm what actually runs in production.
• Runtime reachability: Runtime reachability observes actual execution in production and confirms which vulnerable functions are called live, eliminating false positives from components that are installed but never loaded.
• The core distinction: Static reachability asks, “Are we using vulnerable code?” Runtime reachability asks, “Are we executing vulnerable code?” The second question is the one that determines real risk.

What Makes a Vulnerability Reachable?

Reachability analysis is a security technique used to determine whether a vulnerability in a software component or open-source dependency is accessible and exploitable from within a running application.

Not all vulnerabilities create the same level of risk. A vulnerability may exist in an installed library, but if the affected function is never loaded, called, or exposed through an executable path, it does not present the same exploitability risk as vulnerable code that is actively running in production.

This distinction matters because traditional package scanning can flag every installed dependency associated with a CVE, producing thousands of findings that development and security teams cannot realistically address. Reachability analysis improves prioritization by helping teams focus on vulnerabilities connected to code paths that could matter to the application.

There are two primary approaches to reachability analysis. Static reachability evaluates potential code paths before the application executes, while runtime reachability observes the code and functions that actually execute in production.

Why SCA Alone Was Not Enough

Take cars as an example. A car is built around the internal combustion (IC) engine. All the parts - fuel tank, fuel pump, air intake, gas exhaust, drive-train, and more, are built around the IC engine. When electric engines became usable, the first iteration of cars leveraging them lacked imagination. They combined the electric engine with an IC engine in a hybrid car. Only when car designers re-imagined cars without constraining themselves with an IC engine, the electric cars were born - a simple design, much easier to maintain and with zero emission.

SCA started in a static world. The tools of those days scanned the repository for used packages and then matched them to known vulnerabilities. In the old days, before the explosion of thousands of new CVEs each month, it was enough. Though, when the development teams could no longer keep up, they started asking questions, or more precisely, a specific question: Is this CVE relevant to how we use this library? So, instead of fixing vulnerabilities, they invested time verifying each CVE relevancy and the results were not in the AppSec team’s favor.

This is how reachability was born. Instead of making the engineers verify if their code is vulnerable, let the tool do it for you. Similarly to cars, the first iteration trying to add reachability to the mix lacked imagination. It asked, can we answer the engineers’ question of reachability during the static scan. Hence was born static reachability. Similar to hybrid cars, it had the complexity of having two engines but lacked the full potential of the new tech.

The car analogy establishes the mental model, but the more important question is what this evolution means for how security teams assess vulnerability risk in production. Readers looking for a technical comparison can explore static vs runtime reachability⁠.

Why Executing Beats Using: Function-Level Runtime Reachability

Reachability re-imagined asks a little bit of a different question. Instead of asking “are we USING vulnerable code”, it asks: “Are we EXECUTING vulnerable code”?. That simple change sets a different stage where the true solution lives. As “using” refers to code, “executing” refers to code at runtime. With that in mind, true reachability analysis can only live in runtime.

Function-level runtime reachability traces application execution to the specific function within a library, rather than stopping at the package or library level. This confirms whether the vulnerable code path is actually invoked in production, regardless of how complex the dependency tree is or whether the component is loaded only under certain conditions. By filtering findings down to the components and functions that execute, this approach can deprioritize 97-99% of CVE findings. Developers no longer need to manually determine whether a feature, dependency, or vulnerable function is used because runtime observation answers the question directly.

At Raven, we had the luxury of imagining reachability with no constraints. We built a true runtime reachability solution from the ground up. The result? A simple solution, 5 minute installation, no instrumentation, minimal overhead, that can reduce your traditional SCA noise by 99%.

Runtime reachability is not an iteration of static SCA. It asks a fundamentally different question that can only be answered by observing actual execution.

See how Raven brings true runtime reachability to your vulnerability program.⁠