### Problem to solve <!-- What problem do we 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 <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> * Security operators * App Managers * Software Developers ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> 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) 1. Note that is primarily a back-end, implementation concern & does not need to be exposed to the user. 1. `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 1. `Vulnerability` objects are confidential by default (~backstage implementation: (#34430)) 1. ~~`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. - [x] 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. 1. 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)) 1. ~~New screen added under `Security & Compliance` for vulnerabilities~~ 1. Screen presents a list of all vulnerabilities for all branches. 1. 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 1. Vulnerability list screen has ability to display all `Finding` items 1. Vulnerability screen can separately display Findings & Vulnerability lists 1. Vulnerabilities can be made public ### Design proposal :play_pause: [**Prototype**](https://eyi6la.axshare.com/#id=lzxinh&p=default_&c=1) 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](https://gitlab.com/gitlab-org/gitlab/issues/10242#vulnerabilities-and-findings), [part 2](https://gitlab.com/gitlab-org/gitlab/issues/10242#vulnerabilities-and-issues-vulnerability-attributes) - [ ] 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](https://gitlab.com/groups/gitlab-org/-/boards/1254300?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=12.8&label_name[]=frontend&label_name[]=vulnerability%20interaction&label_name[]=devops%3A%3Adefend) for the most up-to-date status. #### Decisions N/A ### Permissions and Security TBD <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ### Documentation All visual and functional changes to the existing vulnerability/findings interactions need to be captured. Consider updating [existing documentation](https://docs.gitlab.com/ee/user/application_security/#interacting-with-the-vulnerabilities) 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 risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> 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? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ~"GitLab Ultimate" ### Links / references * UX discovery & designs in https://gitlab.com/gitlab-org/gitlab/issues/11568