Reachability Analysis

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

We currently support the Reachability Analysis feature for Java and Go.

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 for Java.

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.

What are the different statuses of Debricked Reachability Analysis?

In the tool, a vulnerability can be flagged with the one of the following Reachability Analysis statuses:

• Found: Indicates that the vulnerable functionality was found to be reachable through the user's code

• Not Found: Indicates that the vulnerable functionality was not found to be reachable through the user's code. As mentioned above, keep in mind that call graphs do not have perfect recall or accuracy, so our recommendation is still to upgrade the dependency at some point.

• Missing data: Indicates that the vulnerability does not have enough information required to determine if the vulnerable functionality was reachable or not through the user's code

• Unknown: Indicates that the analysis was not run for this commit and vulnerability