# Security examples
# Solve vulnerabilities using PRs
Assume we have a repository with loads of vulnerabilities. It will take time to go through each one 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 at once.
Currently, we only support pull requests for certain package managers and integrations using the GitHub app or GitLab. For information regarding the support of your package manager, check out our language support.
# Using the UI
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.
# Using the API
We can generate a new bulk pull request for the repository, with ID 15707 in this case (shown in the URL).
We can find the branch ID using the
Example: First, we get the branch ID
curl -X 'GET' \ 'https://debricked.com/api/1.0/open/repository/15707/get-branches' \ -H 'accept: */*' \ -H 'Authorization: Bearer <token>
then, we create a new pull request on branch ID 2, enabling notification, not including unaffected dependencies in the PR.
curl -X 'GET' \ 'https://debricked.com/api/1.0/open/repository/15707/pull-request/branch/2/1/0' \ -H 'accept: */*' \ -H 'Authorization: Bearer <token>
# Solve a single vulnerability using PRs
It is possible to solve a specific vulnerability in a repository using pull requests, instead of multiple CVEs at once as in the example above.
These are the steps for solving a specific vulnerability:
- In a repository, click on the specific vulnerability you wish to remediate.
- In the CVE view, click the "Open pull request" button. You can see the vulnerable version(s) and the proposed change.
- Click on confirm to execute the changes.
# 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, using pip in this case:
pip install 'requests>=2.20.0'
- Upload the new commit containing the change
- Using integrations, just commit and push the updates
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.
# Vulnerable functionality
Vulnerable Functionality is currently in beta. Results may be less accurate than expected, and not all types of projects are yet supported.
Solving every vulnerability in one's project can be both time-consuming and difficult. 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 the triaging of vulnerabilities.
The Vulnerable Functionality feature is visible when browsing a specific repository as shown below, highlighted in yellow.
By default, the column is shown if at least one vulnerability has a value other than
Unknown, and hidden otherwise.
You can override this using the cogwheel menu, as shown below.
The column will have one of three values;
Yes means that your code uses parts of the library that was changed when the vulnerability was fixed.
This means you are likely to be affected by the vulnerability, and you should solve the vulnerability as soon as possible.
No means that we have not found parts of the library changed in fixing the vulnerability in your code.
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 means that we either cannot determine what change fixed the vulnerability, or we were unable to analyse your code.
In this case Debricked recommends assuming that you are vulnerable while conducting an investigation to manually assess whether you are, and then continuing with the corresponding of the two previous cases.
If the results show that you do use the vulnerable functionality related to a vulnerability, you can see more details by opening the view for the vulnerability in question, and hitting the "Vulnerable Functionality" button, as shown below.
This view shows how you use the vulnerable functionality, if you do. The view is divided by the files in your repository, each file has its own section. Each entry in the section is an instance of your code calling dependency code that eventually calls a vulnerable function. Clicking a row expands it, and shows you the chain of calls leading to the eventual execution of vulnerable code. If there are more than 20 steps between your code and the vulnerable code we will not show all steps, only the first 2 and last 18.
In this example the file
java.lang.Thread.currentThread() on row 320.
This, through a series of other function calls, leads to executing the vulnerable function
Additionally, on row 356 we call
io.netty.buffer.WrapperByteBuf.nioBufferCount(), eventually leading to executing the same vulnerable code.
If you are unable to fix the vulnerability by upgrading the dependency, perhaps because a fixed version is not yet released or contains breaking changes you are unable to address, you can use the information in this modal to instead change your code to not use the vulnerable parts. In the long run you will want to upgrade your dependency in order to actually address the vulnerability though.
# Supported tech stacks
Currently, vulnerable functionality analysis is only supported for Java projects using GitHub actions. We have plans to add support for other integrations as well as for other languages. Here is information on how to set up vulnerable functionality for your repository.
# Set a review status
For each vulnerability we alert you with, you can assign a status. You can choose to mark the vulnerability as unaffected, or vulnerable or you can choose to snooze or pause. All the vulnerabilities have a default status of unexamined until you decide to change it.
To set a review status, go to Repositories (opens new window) on the left sidebar, click on the repo’s name to go into the view, and then click on your choice of CVE. You’ll see the Actions section (see image below) with the available status choices:
- Unaffected: you can mark a CVE as “unaffected” to choice ignore the vulnerability.
- Vulnerable: you can flag a CVE as “vulnerable” to ensure it’s on your radar.
- Pause rule triggering: this means you can wait to take action and pause automation triggering. There are two options you can choose, either snoozing or pausing. When you flag as snoozed, you can define a period of time (1 week, 1 month, etc). When you flag as paused, you can pause until a new fix is available. Pausing is only supported for the Github app.
- Unexamined: this is the default status before choosing one.
# Use Automation to set a review status
Our automation engine can help you remove manual work, by setting review statuses. You can use automation to flag CVEs as unaffected or vulnerable. For example, you can create a rule that when a dependency contains a vulnerability where CVSS is low (0.0-3.9), then mark the vulnerabilities as “unaffected”. Visit our section about automation examples for more information.
# Snooze review status
You can flag a vulnerability as snoozed for a set amount of time. By doing so, the specific vulnerability will not be triggered in any automation rules for the specific repository. After the chosen snooze duration expires, your automation rules will again take the before snoozed vulnerability into account and respective actions will be triggered again. Be aware: This could result in unnoticed security issues because the vulnerability will not show up in your existing automations. Therefore use this feature only if you need to and are aware of the consequences.
# Snooze a vulnerability for a set amount of time
To snooze a vulnerability, go to the desired repository and vulnerability to pause. Next choose “Pause rule triggering” in the Action section. Select “Snooze for a set time period” in the newly opened dialog and your desired snooze period in the shown dropdown. Click “Save” to confirm your selection and snooze the automation rules for the vulnerability.
You can see the activated snooze being shown as review status under Action. Snoozing the vulnerability is also reflected in the Activity section at the bottom of the page.
Note: Setting the vulnerability to snoozed is only available on a per-repository basis. If you want to snooze the same vulnerability for another repository, you’ll have to repeat the same steps for that one.
Even though any user is able to choose "snoozed" as review status by default, as an admin, you can disable this feature for all users in your company. See our user management section for more information.
# Manually remove a snooze from a vulnerability
You can manually stop snoozing a vulnerability at any time before it resumes automatically. To do so, go to the vulnerability you want to resume, click “Snoozed for time left” and confirm that you want to stop snoozing the vulnerability in the displayed dialog. Be aware that this will enable automation rules to be triggered for this vulnerability again.
# Pause review status
You can flag a vulnerability as paused in a specific repository. The vulnerability will stay paused until we find a fix that, if applied, resolves the vulnerability in your repository. In that case, the paused status will be removed automatically and the vulnerability resumes to being unexamined.
Note: The pause could potentially be indefinite when a fix is never found. On that account, you are obligated to choose a maximum pause time when setting this review status. If the pause duration expires before we are able to find a fix, your automation rules will resume taking the vulnerability into account, similarly to how snoozing a vulnerability works.
# Pause a vulnerability until a fix is available
To pause a vulnerability until a fix is available, go to the desired repository and vulnerability to pause. Next choose “Pause rule triggering” in the Action section. Select “Pause until a fix is available” in the opening dialog and choose an appropriate max pause time in the dropdown. Click “Save” to confirm your selection and pause automation rules for the vulnerability.
You can see the activated pause being shown as review status under Action. Pausing the vulnerability is also reflected in the Activity section at the bottom of the page.
Note: Setting the vulnerability to paused until a fix is available is only on a per-repository basis. If you want to pause the same vulnerability for another repository, you’ll have to repeat the same steps for that one.
# Manually remove a pause until a fix is available from a vulnerability
You can manually stop pausing a vulnerability at any time before a fix is found or the max pause time has expired. To do so, go to the vulnerability you want to resume, click “Paused until fix” and confirm that you want to stop pausing the vulnerability in the displayed dialog. Be aware that this will enable automation rules to be triggered for this vulnerability again.