The current support for the Vulnerable Functionality is in an experimental state and we're using it to gather data for upcoming improvements. We currently only support the feature for Java, but we’re looking into adding more languages in the future.
In order to perform Vulnerable Functionality analysis, we need to know what parts of the library are vulnerable, and we need to know whether you are using those parts.
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. So, we 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?
In order 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 we check 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 in fixing the vulnerability, 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 might not include all calls that could happen, or they could include calls that can't happen. For this reason you should never assume you are perfectly safe even if we say you are not using the vulnerable functionality. You should still upgrade the dependency, though it's not as high priority as it would have been if we found that you use the vulnerable symbols.
An example
A project using netty version 4.1.43 or older will (based on the information from Vulnerability databases such as Debricked's public vulnerability database) be affected by, among others, CVEs 2019-20444, 2019-20445, and 2020-11612. However, this is not necessarily the case as CVE-2019-20444 and CVE-2019-20445 affect the webserver part of netty (HTTP Request Smuggling), and CVE-2020-11612 affects decompression (Uncontrolled Resource Consumption due to not limiting size). 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 needed at all, saving lots of time and resources.
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 Vulnerable Functionality feature, this is all automated.