GitLab Next

Problem to solve

Users will be given many different vulnerabilities as part of the different security offerings GitLab provides. These vulnerability results can be potentially long-lived and need to be managed, triaged, and further detailed. Today, this is difficult since vulnerabilities cannot be linked to GitLab issues and cannot be accessed or viewed in all the places that users wish to interact with vulnerabilities.

Intended users

• Security operators
• App Managers
• Software Developers

Further details

Proposal

The MVC of first-class vulnerabilities is the first step towards vulnerabilities being a first-class object that can be interacted with in GitLab. The MVC is focused on introducing the concept of vulnerabilities as a standalone entity to augment Issues and an initial workflow for interacting with them.

Minimal

1. Security scans produce Finding objects which can be promoted to a Vulnerability object (!20734 (merged))
   1. Note that is primarily a back-end, implementation concern & does not need to be exposed to the user.
2. Vulnerability objects are a standalone object type in GitLab that can be created and interacted with.
   1. Allow individual Vulnerability objects to be linked to directly with a URL
      1. Individual vulnerabilities should be viewable on a standalone page
   2. Vulnerability objects are confidential by default (backstage implementation: (#34430 (closed)))
   3. Vulnerability objects can interacted with like they are an Epic
      1. UPDATE: This was primarily intended to allow linking multiple related issues to the vulnerability, which is removed from the MVC.
   • Detail the specific fields of this if we need to break it down
   1. Vulnerability objects have a status associated with them that users can change.
3. Allow Issue and Vulnerability objects to be linked to each other with a one-to-one relationship for MVC (will be many-to-many in the future)(backstage implementation: (#34564 (closed)))
4. New screen added under Security & Compliance for vulnerabilities
   1. Screen presents a list of all vulnerabilities for all branches.
   2. UPDATE: The security dashboard vulnerability listing will be used here instead of a new screen.

Where possible, work will be done behind the first_class_vulnerabilities feature flag.

Extra beyond MVC

1. Vulnerability list screen has the ability to filter based on branch
   • Consider difference between MR flow & asset management flow
2. Vulnerability list screen has ability to display all Finding items
3. Vulnerability screen can separately display Findings & Vulnerability lists
4. Vulnerabilities can be made public

Design proposal

⏯ Prototype

Quick instructions:

• The scope is within one vulnerability, nav is disabled here.
• To start over at any time refresh the page.
• You can add/edit and delete comments in this prototype but some of the micro-interactions are not prototyped (like resetting the text, etc)
• Some language isn't finalized but it's close. That work is in progress.
• Colors and styling are an approximation like I said earlier; this is more of a functional prototype

Screens

Dashboards

Default state	Hover on vuln

Hover state examples

Vulnerability page states

Default "detected"	Confirmed	Dismissed	Resolved

Vulnerability cases

With solution	With issue created

Vulnerability commenting flow

Status without comment	Commenting initiated	Comment typed	Comment added

Modal designs

Modal changes

Development log

Status

backend

• Backstage implementation: part 1, part 2
• Push the first_class_vulnerabilities to the frontend from the Projects::Security::DashboardController
• Filter the Vulnerabilities by status
• API endpoint and action to fetch all Vulnerabilities for a Group
• TODO: support for counts of Vulnerabilities by severity

frontend

Please see the issue board for the most up-to-date status.

Decisions

N/A

Permissions and Security

TBD

Documentation

All visual and functional changes to the existing vulnerability/findings interactions need to be captured. Consider updating existing documentation if this still seems like the appropriate place. It may be best to add additional sub-sections to explain the new/changed functionality and with which version of GitLab it was released.

The main area of focus will be the new standalone vulnerabilities page (and removal of existing modal behavior). Be sure to also note the change to the vulnerability states (new "resolved" state).

Testing

TBD

What does success look like, and how can we measure that?

Number of Findings promoted to Vulnerability on GitLab.com by all users within 30 days from release => Target: 1000

• We want to ensure that the capability is being used

Number of Vulnerability objects linked to an Issue on GitLab.com by all users within 30 days from release => Target: 250

• We want to ensure that the capability is being used

What is the type of buyer?

GitLab Ultimate

Links / references

• UX discovery & designs in #11568 (closed)

/label feature