Does Reachability Matter?
The Heart of Reachability
A while ago, I wrote an article called “5 types of reachability analysis” with Endor Labs. In that article, I talked about the 5 types of reachability, which I summarized as:
At the heart of these types of reachability analysis is a simple goal: determining the likelihood that you’re actually vulnerable to something. Function level reachability says, “hey, you’re calling the function from the CVE, there’s a pretty high chance you’re vulnerable.” Package baselining says, “you’re calling this vulnerable function at the runtime.” Internet reachability says, “this function (or package) is accessible via the API.” Dependency level reachability let’s you know that the package containing the vulnerability is imported. Package used in image tells you that the package is indeed installed (yes this offers the least value!)
In this article, I’ll address why reachability has become the flavor of the moment, where it’s helpful, and why it’s not the complete solution.
Table of Contents
Why is this so prevalent?
It’s easy marketing
Reachability is super complicated - I gave 5 definitions in that article, but since then I’ve even come across 2 additional types thanks to Backlash. Namely, SAST reachability analysis, and Phantom Package reachability. Backslash ties SAST findings back to the internet, and finds used libraries that aren’t directly called out in the package.json.
The only 7-layered evaluation an AppSec team is doing during a sales process is of the 7-layer nachos the sales team bought them at the conference. This confusion is helpful for marketing teams, because it’s so easy to honestly say “we do reachability!” and “we do it in a way that’s better than they do!”
It’s essentially the CNAPP problem - pick a very specific slice of the pie, and then pitch that in sales and marketing as some massive differentiator, when whether it is or not is really ambiguous. For example, function level reachability is lightyears more valuable than detecting only if the package installed, but that looks very similar to runtime detection from a high level. Only by diving deeply into the difference can teams sort through the noise.
It’s the problem of the moment
If AppSec has a rallying cry, it’s this:
The main problem with SCA tools is that I legitimately don’t know if I’ve ever seen a true positive. CVEs are scored on a worse case basis, and CVEs often use software in weird ways, leading to a huge number of high severity false positives. Any product that can make the numbers go down instead of endlessly up is what people are looking for.
It’s the intuitive solution
This video lays out the problem with the latest 10/10 Rust CVE - no one uses Rust like this, but if they did, yes it would be critical. Reachability promises to address this issue: you don’t even use that function from Rust, so you’re not vulnerable. Below is the typical AppSec workflow:
Now that our CVE discovery scanners have gotten pretty good, vendors are moving on to the next question, “how can we help teams determine if they’re actually vulnerable and if they need to patch?”
Is Reachability Helpful or Hurtful?
Helpful: The lack of true positives is a real problem
When you setup a tool, it shouldn’t take years before you see a true positive come out of it. Especially with zero day threats, it’s extremely helpful to know right away if you’re vulnerable or not.
Helpful: Context
A lot of vendors are focusing on one or two types of reachability, but some, like Ox, combine multiple of them to create a more holistic view of the application, and bring together multiple forms of reachability analysis. Not only is it more information to help prioritize, it’s also helpful to know where to go to fix things.
Hurtful: Reachability has a false negative problem
While it’s awesome to tune out stuff, there are a lot of edge cases in CVEs that will eventually come back around, where you might still be vulnerable to something pretty critical, even if it doesn’t show up as a “reachable function.” Sometimes, tools don’t have access to the full context of the application, and might think a data flow isn’t happening, but it’s really happening upstream in another project. As a note, this is only a risk to the vendors not really dedicating the effort to reachability it needs; most of the ones focusing on it are very aware of trying not to do this.
Hurtful: Reachability has a data problem
Oftentimes CVEs don’t include the vulnerable function data. Many vendors have gotten around this in interesting ways, such as looking at the linked git commits and what they fixed, or creating their own internal databases. However, it can be really unclear how reliable a vendor’s conception of reachability is in terms of dependencies on well written CVE descriptions. This is incredibly difficult for teams to evaluate without creating specialized environments thoroughly testing multiple CVEs.
Reachability isn’t the end goal, it’s patching
Recently while recording a podcast with Opus, an analogy struck that I was really helped by. When patch Tuesday rolled around for Windows machines, no one took the time to analyze their impact, or if the vulnerabilities were true positives or not. Instead, they just patched them.
In AppSec, because there’s not a single vendor, we’ve allowed the difficulty of patching to flip the way we think of vulnerabilities, and this has been to our detriment. Instead of, “are we vulnerable?” our first thought needs to be “can we patch this?”
Rebuilding an image or patching a patch version is not always less time than doing reachability analysis. Sometimes, patching is a major project that requires insight like that offered by Code Fixers to create patches for you. However, tools should help people identify that level of effort before focusing on the “are we really vulnerable?” question.
Reachability is still helpful - a lot of times patches aren’t available, or would require an unrealistic lift, in which case you’d do reachability analysis. It’s just not the outcome of first importance.
See more in the Video with Backlash: https://youtu.be/ViZpLKfLtJA
Latio List v1.12
Added Leen to Boundary Breakers - a unified API for vulnerability data
Added Tracebit to Boundary Breakers - Honeypot infrastructure for your cloud
Added Turbot to Cloud Identity, Secret Scanning, IaC, and CSPM - guard rails and enforcement on top of querying cloud data
Added Cremit to Secrets Scanning - Secrets scanning + real time monitoring
Added Pillar to LLM - Library based application detection and protection
Added OpenRefactory to SAST - focusing on building an amazing SAST engine above all else