Proposal: Vulnerabilities are the primary vulnerability management lifecycle record

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem to solve

It is difficult to collaborate on vulnerabilities in GitLab today. Instead of a vulnerabilities being a SSOT for a detected vulnerability, users are creating issues for vulnerabilities to track the lifecycle of triaging, assigning engineers, performing analysis & impact assessment, mitigation and remediation. Once a vulnerability has been remediated and the vulnerability is no longer detected, both the tracking issue and vulnerability needs to be manually closed, in addition to any other issues which were created to track engineering work such as updating dependencies or base images. This leads to a duplication of effort, and a blurring of tracking a detected vulnerability and the engineering work which may be required or created either during or after remediation of the vulnerability. It also leads to an unclear separation of duties when there are different teams or individuals responsible for vulnerability triage, analysis & any remediation efforts.

Proposal

Extend vulnerabilities as presented as part of the Vulnerability Report to be able to represent necessary vulnerability detail and lifecycle events required for modeling a vulnerability management process end to end.

Currently, the typical workflow for managing a vulnerability in GitLab looks like -

  1. A security scanner runs in a CI pipeline or a vulnerability is manually created
  2. Security findings reported by the scanner are recorded, alongside details reported by the scanner
  3. Vulnerabilities are created in GitLab for these findings, using a subset of detail about the finding
  4. These vulnerabilities are shown in the Vulnerability Report
  5. Triage is performed from this report, and vulnerabilities can be confirmed or dismissed with a supplied reason
  6. Confirmed vulnerabilities can then have an issue created using the Create Issue button
  7. The remainder of the Vulnerability Management lifecycle is then tracked in an issue
  8. Once remediated or mitigated, the vulnerability is resolved either via a newer security scan, or manually in GitLab

Whilst this approach can be used to build a vulnerability management process, there are a number of challenges with this approach which could be improved:

  • Vulnerabilities do not allow for collaboration or discussion of the vulnerability, i.e. via comments, making it difficult to record research, analysis and discussions around approaching mitigating and resolving a vulnerability
  • Vulnerabilities can not be assigned, making it difficult to manage more complex triage or analysis
  • Vulnerabilities can not be annotated (i.e. with Labels), making it difficult to augment or annotate vulnerabilities with potentially useful information as part of a workflow

These limitations are worked around by creating a tracking issue using the "Create Issue" button, however this approach has the following limitations:

  • The discussion around triage and the approach to mitigating the vulnerability is invisible to someone viewing the vulnerability itself
  • Strict naming or process rules are required to make it clear which linked issue is being used to track discussion of a vulnerability, triage, impact and possible mitigation and resolution
  • Vulnerability tracking issues can pollute engineering planning tools in GitLab and generally pollute an engineering backlog, when no engineering work may be required for a specific vulnerability
  • Issues are perfectly suited to modelling engineering work related to vulnerabilities, as modelling engineering work is their intended purpose, however using them outside of their intended purpose creates an additional level of organizational abstraction above the goal of managing a vulnerability
  • Issues duplicate information, weakening the Vulnerability as a SSOT
  • Creating an issue makes the user switch context (to a new page, a different interface, and requires submitting a form)

The following parts of the vulnerability management lifecycle however are perfectly suitable as issues linked to a vulnerability -

  • Short-term engineering effort related to mitigating a vulnerability such as updating a dependency or removing a secret as a distinct issue which can be tracked and expedited as part of engineering cycles & appropriately prioritized
  • Longer-term goals like removing a dependency from an image altogether, or refactoring secrets management in a project, which additionally may outlive the vulnerability in the vulnerability report but still make sense to track after the vulnerability is mitigated.
  • Engineering issues which also end up mitigating or resolving multiple vulnerabilities or vulnerability classes, which might be linked to the vulnerability but should not be confused with a vulnerability tracking issue.

To address these limitations, I am proposing we implement the following features for vulnerabilities -

  1. The ability to add labels (project or group scoped) to vulnerabilities
  2. The ability to assign vulnerabilities to users
  3. The ability to comment (ideally with discussion threads, the same as issues) on Vulnerabilities
  4. The ability to be notified as new vulnerabilities are opened and closed in the same fashion as issues (either via Todos or email)

I believe this would obviate the need to use issues for tracking the vulnerability management lifecycle portions of a vulnerability, allowing issues to be used to track solely any engineering effort, which is the intended purpose of an issue.

With these features in place, a new, more transparency & streamlined vulnerability management process is possible:

  1. A security scanner runs in a CI pipeline or a vulnerability is manually created
  2. Security findings reported by the scanner are recorded, alongside details reported by the scanner
  3. Vulnerabilities are created in GitLab for these findings, using a subset of detail about the finding
  4. These vulnerabilities are shown in the Vulnerability Report
  5. An owner for a vulnerability is assigned, and triage & analysis are performed, the outcomes and discussion recorded on the vulnerability
  6. Any workflow labels can be applied either via quick actions in a comment or manually via the UI
  7. Issues are created with direct, actionable engineering work required to mitigate the vulnerability
  8. Any follow-up issues can be created for larger engineering work related to this class of vulnerability or dependency
  9. Once remediated or mitigated, the vulnerability can be resolved with comments

This process allows a engineering work to be tracked more neatly, improves transparency around vulnerabilities & their lifecycle, prevents engineering backlogs and reports from being cluttered by vulnerability tracking issues, and promotes a better separation of duties for teams with distinct security and engineering teams.

A related discussion around state transitions & comments which I think would compliment this proposal very well is #388985 (closed)

Edited by 🤖 GitLab Bot 🤖