Skip to content

Vulnerability triage process

Keeping on top of security vulnerabilities is no small feat. This process lays out a simple process for keeping on top of them by prioritizing the highest severities.

GitLab's Vulnerability Reports

This process relies on the Vulnerability Report feature from GitLab. A Vulnerability Report provides information on vulnerabilities detected during scans of the default branch. The report links to individual pages containing a summary of each of those vulnerabilities. These pages are called a Vulnerability Page. A report is available at a project or group level. They can be found under "Secure" >> "Vulnerability report". For more information on vulnerability reports see GitLab's own documentation on reports and vulnerability pages.

Note

This is an example vulnerability report and not one of our live services.

Image of an example vulnerability report in GitLab

What's the process?

To summarize, the process is to review all "critical" and "high" severity vulnerabilities, evaluate their likelihood of occurrence, decide appropriate actions, and repeat this every sprint.

These are the steps:

  • Create a vulnerability review ticket for the coming sprint using the issue template.
  • Review all "critical" vulnerabilities using vulnerability report within GitLab.

For each vulnerability:

  • Try to answer, or get a sense of, the following:
    • What is the vulnerability?
    • What is the source of the vulnerability/which package contains the vulnerability?
    • Whether it is likely to affect us within the context of the project?
  • Usually the Vulnerability Page contains useful links which might help to answer these questions.
  • Within the Vulnerability Page decide to either "confirm", i.e. decide to take action fix the vulnerability, or "dismiss" the vulnerability. Update the status accordingly, e.g. "Confirmed", "Dismiss -> Acceptable risk"
    • If dismissing, add a brief comment about why, e.g. that the vulnerability is in the DevOps base image and will be fixed when the base images are updated.
    • If confirming, use the "create issue" button which will create an issue containing all the information in the vulnerability report. By default, these tickets do not get any labels so you may want to add some. Move these issues into the current sprint with a high priority. See Fixing a vulnerability for what to do when picking up these tickets.

Once all "critical" vulnerabilities have been actioned and time permits, repeat the process for "high" severity vulnerabilities. Finish by creating a vulnerability report review ticket for the next sprint.

Fixing a vulnerability

These are the steps to complete when picking up one of these vulnerability tickets:

  • Raise a merge request (MR) which fixes the vulnerability. This may be as simple as updating some dependencies.
  • Confirm the changes fix the expected vulnerability. You can do this by checking the security scanning findings displayed in the MR. This lists all fixed and any newly introduced vulnerabilities as a consequence of the changes.
  • Once the MR has been merged, navigate back to the original Vulnerability Page. Verify that a "resolved" banner appears which confirms the vulnerability has been resolved on the default branch.
  • Add a comment to the Vulnerability Page linking back to the MR and update the status to "Resolved".