Design: Vulnerability container in issues for bulk add
Problem to solve
Users require the ability to add multiple vulnerabilities to a single issue. Coming from internal and external research, participants said they add multiple vulnerabilities with the same (or similar) remediation action to an issue, which reduces noise for the engineer, and helps to cultivate the AppSec - Engineer relationship.
As part of Design: Enhanced bulk actions we took creating a new issue from 2+ (two or more) vulnerabilities out of scope because of the complexities that arose in the design explorations. When a user creates an issue from 1 vulnerability, the details of that vulnerability populate the Description of the new issue (see screenshot below), however, this isn't scalable; imagine an issue created with 10, 20, or even 50 vulnerabilities associated with it. How might we include the information from these vulnerabilities, and the unique links to them, in a scalable way?
History (NOT current design proposals)
The following were design explorations from Design: Enhanced bulk actions (they have since been archived in that issue).
Bulk selection on the Vulnerability Report | Issue - vulns under a collapsible header | Issue created | Uncollapsed |
---|---|---|---|
Comments on the designs:
from @andyvolpe
You may want to break this out of the bulk actions work and take some more time identifying a solution. Consider how other objects (related MRs/Related issues etc) are attached to and organized in an issue. I did some work a while back for the vuln management vision that touched on this concept. It might also be a good idea to collaborate with the plan team on this, if I remember correctly they were working on the display of object in issues at one point this past year.
It is good to be thinking about the MVC, but don't let that dictate the design too much. You want to use this time as an opportunity to design the entirety of the solution that will be broken down with your team into MVCs. These designs aren't attaching 58 vulns to an issue, rather they are referencing 58 vulns in an issue. Consider the UX of having 58 links that are numerical stings for the user to have to parse. I would advise breaking this down further and addressing attaching multiple vulns to an issue in collaboration with the Plan team.
from @matt_wilson:
In addition to how to best show the relationship of multiple vulnerabilities in a single issue, the other challenge will be what to put in the issue description. A few members of the team and I did discuss this briefly (not sure where the recording is just yet) and had a few ideas. Nothing seemed to be a clear favorite but here were some suggestions on how to populate the new issue's description:
- Use the description of the first vulnerability in the selected list (based on display/sort order)
- Use the vulnerability with the highest severity (if there are multiple of the same severity...pick one?)
- Let the user chose which vulnerability to copy
- Copy all descriptions from all selected vulnerabilities (this was the least favorite as it will be problematic from both a UX and a performance perspective)
from @jmandell
Hey Matt, you bringing up the severity made me think that it might be cool (and here comes some scope creep!) to show a table with some stats of the attached vulns:
Critical | High | Med | Low | Info | Unknown |
---|---|---|---|---|---|
2 | 0 | 0 | 10 | 0 | 10 |
And then maybe, clicking on the number could bring you to a new page (tab) that uses our Vuln table view to show those specific ones clicked. Or maybe for greater simplicity, it shows all of the vulns in this issue? Just spitballing here...
Intended users
User experience goal
Proposal
See design section. In addition, a vulnerability should receive a system note when added as related. See: #247890
An MVC version, if needed, can add an activity note to the issue, until we have the vulnerability container:
Questions
Should/ can we also include this related vulns container in the vulnerability modal that triggers when clicking on a vuln from the security widget in an MR? Related issue: #247889
Further details
Documentation
What does success look like, and how can we measure that?
Is this a cross-stage feature?
Yes, collaboration needed with the Plan team
/cc @uhlexsis @hollyreynolds @badnewsblair
Links / references
/cc @gitlab-com/gitlab-ux/secure-protect-ux