# Security examples

# 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.

# 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.

Vuln use case pull request

When the pull request is created, you can view in by clicking "View generated fix".

Vuln use case pull request done

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.

Vuln use case result

# Using the API

Endpoints:

  • /api/{version}/open/repository/{repositoryId}/pull-request/branch/{branchId}/{notify}/{includeUnaffected}
  • /api/{version}/open/repository/{repositoryId}/get-branches

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 get-branches endpoint.

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

Repo view anim

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.

Suggested fix anim

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

Once scanning is completed, the repository should no longer have a vulnerability, marked by a 0 in the tab "Total Vulnerabilities".

No vulnerabilities

Good job! You made it.

# Vulnerable functionality

Note

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.

For information about how to enable Vulnerable Functionality for your repository, see this page. For an explanation on how it all works, see this page.

The Vulnerable Functionality feature is visible when browsing a specific repository as shown below, highlighted in yellow. UsesVulnFunc 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. UsesVulnFuncToggle

The column will have one of three values; Yes, No or Unknown.

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.

UsesVulnFuncCveModalAnim

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.

UsesVulnFuncCveModal

In this example the file Worker.java calls java.lang.Thread.currentThread() on row 320. This, through a series of other function calls, leads to executing the vulnerable function jdk.internal.ref.CleanerImple.run(). 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.

# 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.

# 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.

# Admin settings for snoozing vulnerabilities

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.

# Disable snoozing for vulnerabilities in admin tools

To disable the snoozing functionality on a company-wide basis, go to admin tools > user permissions. At the bottom of the page you can find the toggle “Allow snooze for vulnerabilities”. Note that all vulnerabilities with the snooze review status will be set to unexamined if you confirm your action, and removing the status from currently snoozed vulnerabilities is irreversible.

# Enable snoozing for vulnerabilities in admin tools

To enable the snoozing functionality for all users go to admin tools > user permissions. Find the disabled toggle “Allow snooze for vulnerabilities” and click it to enable snoozing.