### Problem to solve Users require the ability to view vulnerabilities in groupings of type of asset in order to find similar vulns which will help to 1. identify high-level data ("how many OWASP Top 10 vulns are in my Vulnerability Report?"), 2. spot patterns ("how many of my critical vulns are SAST?"), and 3. use bulk actions to dismiss, create issue, etc. Armed with this capability, users can optimize their triage tasks by utilizing the bulk actions on groups, thus reducing the need to manually identify and select similar vulnerabilities to take action. Bonus win: they can see how many vulnerabilities match that category by the number shown within each group; e.g. how many OWASP Top 10 vulns there are. Grouping is related to and will be used in tandem with [Design: Customizable views for triage and monitoring](https://gitlab.com/gitlab-org/gitlab/-/issues/267572) to allow for maximum flexibility in how users want to view vulnerabilities on the Vulnerability Report. ### Intended users - [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### User experience goal Users should be able to efficiently prioritize and triage vulnerabilities arranged by property similarity. Users should be able to take action on vulnerabilities with similar properties at one time. Properties include, but aren't limited to: #### MVC Group by: - Status - Severity - Tool - OWASP Top 10 #### Post-MVC (future issue) Future group by possibilities in the future (need validation): - Identifier (possible second step to group by CVE, CWE Top 25, or type e.g. XXS) - ~~Location~~ File path (possible second step to group by file or folder) - Analyzer (e.g. Brakeman for SAST) - Dismissal _type_ - Activity type - Group by same resolution (e.g. upgrade Rails) or same/similar vulnerability occurrences in different branches which all map to the same vulnerability in the default branch. We need to uncover the key 1:many and many:1 relationships between these entities to make vulnerability management more efficient and flexible. See https://gitlab.com/gitlab-org/gitlab/-/issues/205638+ for more details. Applies only to container scanning (per [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/267588#note_828793104)) - Group by container name - Group by tag - Group by lock file Applies only to dependency scanning - (we'll most likely move this to the dependency list) - Group by root dependency (per [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/267588#note_815914791)) - Group by introduced dependency (per [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/267588#note_828793104)) - Group by vulnerable dependency (per [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/267588#note_828793104)) ### Additional requirements * Provide a dropdown button for users to view groups of vulnerabilities with the same property. * Whenever a grouping is applied, the column headers are moved below the group titles. * If an entire group is selected and spans across pages, all vulnerabilities within the group should be selected across pages. * If a vulnerability applies to more than one group, it should be shown more than once. In other words, it should be included (duplicated) within every group it applies to. However, the number in the single stat should only count it once. * If there are vulnerabilities that don't fall into any of the groupings (e.g. OWASP Top 10 and CWE Top 25), there should be a `Non-{group_name}` group at the end of the list. ### Problem validation: Problem validated in [this issue](https://gitlab.com/gitlab-org/ux-research/-/issues/1295#%EF%B8%8F-results-and-key-insights). #### Kano results | Kano category | Dissatisfaction w/o | Satisfaction w/ | Importance | Cost of delay | | ------ | ------ | ------ | ------ | ------ | | **Attractive** | 1.3 | 2.8 | 7.3 | 9.6 | ### Documentation <!-- See the Feature Change Documentation Workflow [https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change](https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change) - Add all known Documentation Requirements in this section. See [https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements](https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements) - If this feature requires changing permissions, update the permissions document. See [https://docs.gitlab.com/ee/user/permissions.html](https://docs.gitlab.com/ee/user/permissions.html) --> Documentation needed ### Links / references Future question: - How important is subgrouping and how does sorting (and subsorting?) come into play? - Note: even without subgroups, a secondary sort might be needed, or maybe better filtering. Related issue: [Secondary Sorting of Vulnerability List in Security Dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/13672) ### Solution validation Completed in https://gitlab.com/gitlab-org/ux-research/-/issues/2322+. ### Steps * [x] Design explorations * [x] Solution validation | [Participant list & notes](https://docs.google.com/spreadsheets/d/1fywqCbw6VFJRsMQUpc9RWTfur4mL6xLyN7fD9R3cWjY/edit?usp=sharing) * [x] Design updates, if needed * [x] Share research results * [x] Finalize all design states * [x] Design complete. Change workflow label from ~"workflow::design" to ~"workflow::planning breakdown"