# Security examples
# Solve a vulnerability manually
Here, we show how to list all vulnerabilities for a repository and how to go about and solve them.
To see the list of all vulnerabilities for a repository, click the repository name in the "Repositories" view.
In this case, a single vulnerability is detected, with a high severity score of 9.8. Click on the name of the vulnerability, "CVE-2018-18074", to see details about the vulnerability.
- Through analysis , we conclude that our application is indeed affected by this vulnerability. We mark this by clicking on "Flag as vulnerable".
- Next, we need to take action to solve the issue. Click "Suggested fix" to view a possible solution.
The next step is to update the dependency file.
- Update the package via the package manager, in this case pip:
pip install 'requests>=2.20.0'
- Upload the new commit containing the change
- Using integrations, just commit and push the updates
- Using manual upload, see below
Once scanning is completed, the repository should no longer have a vulnerability, marked by a 0 in the tab "Total Vulnerabilities".
Good job! You made it.
# Manual upload
To manually create a new commit for a repository and apply the corresponding dependency file, perform the following.
- Under the "Manage" tab, click "Manage dependency files"
- Choose the updated dependency file
- Apply it to the repository
- Apply it to a new commit
- Wait for analysis to complete
# Solve vulnerabilities using PRs
Assume we have a repository with loads of vulnerabilities. It will take time to go through each and everyone of them and potentially fix them. Luckily, Debricked offers the ability to open a pull request where it tries to solve as many vulnerabilities as possible in a single pull-request.
In a repository, click on "Generate pull request" to let the tool update your dependencies, in order to solve vulnerabilities, and create a pull request for you.
When the pull request is created, you can view in by clicking "View generated fix".
When the pull request is merged, we can see in the tool that the number of vulnerabilities has decreased, from 42 to 29 in this case.
# Vulnfunc 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:
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.
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.
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.