Reachability, Re-Imagined

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.

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.

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.

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 97%.