Reachability Analysis

Here's everything you need to know about Debricked’s Reachability Analysis.

The current version of Reachability Analysis is a pre-release. Results may be less accurate than expected and not all types of projects are yet supported. The data gathered will be used for upcoming improvements. We currently only support the feature for Java, but after the main release, we’re looking into adding support for more languages.

Debricked’s Reachability Analysis is all about automating the work needed to know if your project, using a vulnerable library, is susceptible to a vulnerability or not. To perform the analysis, we need to know what parts of the library are vulnerable and whether you are using those parts or not. To make this connection, we need to know in which way your open source dependencies are being used. We get this information from generating a call graph through the CLI for your project. For information on how to generate the required call graph, see how to set up Reachability Analysis.

How do we know what parts of the library are vulnerable?

We start by fetching the latest vulnerable version and the first fixed version from our database. We then narrow this down to the smallest change we can find, using information from various sources, until we settle on two versions of the code, one vulnerable and one fixed. These versions can be released versions, git tags, git commits, or similar.

Since whatever changed between these two versions fixed the vulnerability, the vulnerability must be contained in these changes. We therefore download the code for these two versions, compute the difference and translate that into functions, classes, and other code symbols, and store this in our database. Now we know, for a given vulnerability, what parts of the library are vulnerable. We call these parts the vulnerable symbols for a given vulnerability affecting a given dependency.

Am I using the vulnerable parts?

To figure out if you use the vulnerable parts of the library, we need to know what parts you use. We do this by generating a call graph for your program and its libraries. This call graph is then uploaded alongside your dependency files, and scanned to see if it contains the vulnerable symbols we found in the previous step. If we find those symbols, we know you are using the parts that changed when the vulnerability was fixed in the library, and are likely affected by the vulnerability. If your call graph does not contain the vulnerable symbols, you are most likely not using the vulnerable parts, and probably not affected by the vulnerability.

Keep in mind that call graphs do not have perfect recall or accuracy, as they might include calls that can't happen or lack calls that could happen. For this reason you should never assume you are perfectly safe even if we say you are not using the vulnerable function. You should still upgrade the dependency, though it might not be as high in priority as it would have been if we found that you use the vulnerable symbols.

Examples

A project using netty with a version between 4.1.0 and 4.1.43 will (based on information from Debricked's public vulnerability database) be affected by, among others:

• CVE-2019-20444

• CVE-2019-20445

• CVE-2020-11612

However, this is not necessarily the case as CVE-2019-20444 and CVE-2019-20445 both affect the webserver part of netty while CVE-2020-11612 affects decompression. As such, if one does not use netty for decompression, CVE-2020-11612 has no effect on the safety of the project and the user only has to upgrade to version 4.1.44 instead of 4.1.46. If one also does not use the webserver part of netty, upgrading is not strictly needed at all, saving lots of time and resources. As previously mentioned, we still recommend that you upgrade the dependency to a safe version, though the priority will be lower than if we found that you actually use the vulnerable symbols.

Normally this would have to be determined by manual investigation, requiring in-depth knowledge about not only your own project but also netty, and spending time reading through CVE specifications to determine what parts of netty are affected by a given CVE. With Debricked's Reachability Analysis, this is all automated.