# Vulnerable functionality feature

Solving every vulnerability in one's project can be both time-consuming and cause unforeseen challenges. Debricked is aiming to help you with both of these aspects. You may have already learned how simple it can be to solve a vulnerability with Debricked. What if we could save you even more time and resources? Here we are introducing Debricked's vulnerable functionality feature.

# Vulnerable Functionality in short

Just because you are using a package with a vulnerability does not necessarily mean you are affected by the vulnerability in question, that requires actually using the vulnerable parts. By using Debricked's Vulnerable Functionality feature you can quickly assess whether or not you are, significantly speeding up triage of vulnerabilities.

This feature is visible when browsing a specific repository as shown below, highlighted in yellow. UsesVulnFunc Due to the not all users having this feature enabled and it not being applicable to all users this column is hidden by default, to enable it select it as shown below. UsesVulnFuncToggle

# Tech stacks supported

Currently, this feature is only supported for Java Maven projects using GitHub actions. We have plans to add support for other integrations as well as for other languages and dependency management systems.

# Enabling Vulnerable Functionality for your repository

Once you have set up an integration using GitHub actions adding Vulnerable Functionality analysis is easy. Simply add a line using the Vulnerable Functionality action, as below.

name: Vulnerability scan

on: [push, pull_request]

jobs:
  vulnerabilities-scan:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - uses: debricked/vulnerable-functionality/java/maven@v8
    - uses: debricked/actions/scan@v1
      env:
        DEBRICKED_TOKEN: ${{ secrets.DEBRICKED_TOKEN }}

Please note that you need to add the Vulnerable Functionality step after a checkout step, but before the scan step.

# Configuring Vulnerable Functionality

By default Vulnerable Functionality will assume your root pom.xml file is in the base repository directory. If this is not the case you need to let us know where it is, as shown below.

name: Vulnerability scan

on: [push, pull_request]

jobs:
  vulnerabilities-scan:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - uses: debricked/vulnerable-functionality/java/maven@v8
      with:
        root-pom-directory: 'path/to/directory/with/root/pom'
    - uses: debricked/actions/scan@v1
      env:
        DEBRICKED_TOKEN: ${{ secrets.DEBRICKED_TOKEN }}

# 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, (opens new window) be affected by among others CVEs 2019-20444 (opens new window), 2019-20445 (opens new window) and 2020-11612 (opens new window). 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, one does not need to upgrade at all, saving lots of time and resources.

# Technical explanation

First we must determine what parts of the library is vulnerable. This is done by fetching the last vulnerable and first fixed versions, and comparing the difference between the two. These versions can be one or a set of commits, or two released versions. Secondly, we generate a call graph of your code and the library, to see what parts of the library are actually used. Finally we check to see if the parts changed in fixing the vulnerability are present in your program. If so, there is a significant likelihood that you are using the parts of the library affected by the vulnerability.

# Interpreting the results

There are 3 cases possible in the relevant table:

  • Yes:

    The call graph contains parts of the library changed in fixing the vulnerability. This means you are likely to be affected by the vulnerability. In this case Debricked recommends solving the vulnerability as soon as possible.

  • No:

    The call graph does not contain parts of the library changed in fixing the vulnerability. This means you are likely not affected by the vulnerability, but there is no guarantee. In this case Debricked still recommends solving the vulnerability, but it does not have to be top priority.

  • Unknown:

    We either cannot determine what change fixed the vulnerability, or the vulnerability is in a language that is not yet supported. In this case Debricked recommends assuming that you are vulnerable while conducting an investigation to assess the impact of the vulnerability and then continuing with the corresponding of the two previous cases.

# Future additions

In the near future there will be more information available in the vulnerability view relating to what the vulnerable functionality in use is, where the vulnerable functionality is used in your code, and the call trace to the vulnerable function.