MVC Standalone Vulnerability objects (Vulnerability Management)
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
- Security scans produce
Finding
objects which can be promoted to aVulnerability
object (!20734 (merged))- Note that is primarily a back-end, implementation concern & does not need to be exposed to the user.
-
Vulnerability
objects are a standalone object type in GitLab that can becreated andinteracted with.- Allow individual
Vulnerability
objects to be linked to directly with a URL- Individual vulnerabilities should be viewable on a standalone page
-
Vulnerability
objects are confidential by default (~backstage implementation: (#34430 (closed))) -
Vulnerability
objects can interacted with like they are an Epic- 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
-
Vulnerability
objects have a status associated with them that users can change.
- Allow individual
- Allow
Issue
andVulnerability
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))) -
New screen added underSecurity & Compliance
for vulnerabilities- Screen presents a list of all vulnerabilities for all branches.
- 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
- Vulnerability list screen has the ability to filter based on branch
- Consider difference between MR flow & asset management flow
- Vulnerability list screen has ability to display all
Finding
items - Vulnerability screen can separately display Findings & Vulnerability lists
- Vulnerabilities can be made public
Design proposal
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
-
Backstage implementation: part 1, part 2 -
Push the first_class_vulnerabilities
to the frontend from theProjects::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
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?
Links / references
- UX discovery & designs in #11568 (closed)