Design: Related vulnerabilities container post-MVC

Overview

In Enhanced Bulk Actions for the Vulnerability Report we added a "Related vulnerabilities" container in the issue created from a vulnerability (or vulnerabilities). Screenshot from example here:

Screenshot 2025-06-03 at 11.43.31 AM.png

This was a great addition! However, we can extend this to further improve usability.

Problems to solve

  • When a user clicks on one of the related vulnerabilities, they're taken to the vulnerability detail page. From this page, I wouldn't know that there are related vulnerabilities unless I went into the related issue.
  • There's no way to unlink a vulnerability to an issue. I can close an issue, but now with multiple vulnerabilities relating to one issue, it's possible that I just want to unrelate one of them, but not close the issue entirely.
  • I can't update all related vulns at once from one convenient place. Say that in the issue, it's determined that these vulns represent critical risk true positives. I want to be able to mark all associated vulns as "Critical" and put them into a "Confirmed" state without having to go and find them individually in the Vulnerability Report.

Note: If we can do this in one Post-MVC, great! I only split them into 1.0 and 2.0 based on my guess of technical complexity.

Post-MVC: 1.0 Proposal

  • Add the Related vulnerabilities container to the vulnerability detail page, under Related issues

image.png

Post-MVC - 2.0 Proposal

  • Add bulk functionality into the Related vulnerabilities container (here and on the issues page) so users can change the status or severity of all related vulns at one time.
  • Add ability to x a vulnerability which would remove and unrelate it.

image.png

We could also expand this functionality into the MR which would solve the problems captured in Provide visual feedback to the user that the vu... (&14883).

Post-MVC - 3.0 Proposal

Add more content into this container, such as:

  • Detected date
  • Report type/ scanner type
  • Identifier(s)
  • Ref

Vision Discussion

As was covered in the User Journey Workshop at the Sec Section Offsite, we could extend this even further and address another 2 pain points:

a) Users can't see how similar vulnerabilities were triaged in the past. If GitLab could identify related vulnerabilities (based on CWE, for example), users could see how those vulnerabilities were triaged and remediated. Were they dismissed? Were they resolved - if so, how? Can they use the same resolution to speed up the time investigating a remediation? This would be relevant to SAST vulns, but not Dependency or Container Scanning (where the only remediation is an update).

b) Users don't want to find related vulnerabilities on their own. We're the experts and our tool should be offering efficiencies to our users. Could we help them identify related vulns to relate to one issue (that corresponds with one fix) so they don't end up having to manually relate multiple vulns? This is probably better suited on the Vulnerability Report view (perhaps by offering a grouping by CVE) rather than from within a vulnerability detail page, but it would be valuable to include from this view as well.

Related: Collaborative remediation (#9139)

Proposal TBD

Edited by Becka Lippert