Product discovery for inline vulnerability management
Problem to solve
Today, when a user wants to see more information on a vulnerability, they have no option but to view it in a modal. This is not an optimal experience since it makes viewing information of multiple vulnerabilities in one session tedious and time-consuming.
Proposal
Implement an inline solution that expands and collapses the 'more information section' of a vulnerability.
Goals and guardrails:
- This has to be a better experience with more affordances than we have with modals today.
- The solution has to be scalable
- The solution has to consider all places in the application where users might interact with vulnerabilities
- Should be device agnostic.
- The first iteration or MVC should be implementable from the onset.
Design
MR initial view | MR with vulnerability selected |
---|---|
GSD initial view | GSD with vulnerability selected |
---|---|
Design details
Examples by Report Type
SAST | DAST | Dependency scanning | Container scanning |
---|---|---|---|
Edge cases
All sections collapsed | Scrolling detail | Loading detail |
---|---|---|
Action Area
The action area houses the main actions a user can take regarding the vulnerability.
Vulnerability has been dismissed | Issue has been created | Dismissed with issue |
---|---|---|
Dismissing with a comment
We will retain the ability for the user to add a comment while dismissing the vulnerability. When the user adds their comment:
- Vulnerability becomes dismissed
- Dismissed status banner appears
- Dismissed activity added to the activity area
- Comment added in the activity area
- Dismiss button changed to
Undo dismiss
Initial state | Dismiss with comment | Error state |
---|---|---|
Status banners
Status banners are shown at the top of the drawer just below the action area. They serve as a quick view of the status of the vulnerability so the user doesn't have to spend time trying to figure out what the last action performed on the vulnerability was.
Stackable status banners
Order of stackable banners:
Add-on status banners
Add-on banners can be added to the stackable status banners and always appear below them. Only the most recent issue
event or MR
even will be shown as a banner so we can keep the status area from becoming too tall.
Issue created | MR created |
---|---|
Only shown if the most recent issue or MR event. Entire banner links to issue. | Only shown of most recent issue or MR event. Entire banner links to MR. |
Examples:
High-level details:
The high-level detail area includes the:
- Severity line
- Severity
- Confidence
- Report type
The severity line is a 2px line that assumes the color of the severity of the vulnerability.
Severity line styles |
---|
Severity | Confidence | Report type |
---|---|---|
Report type |
---|
Link handling
We want to avoid, if possible, links breaking to two lines. There are two strategies to handling these cases.
- Truncating external links
...
Identifiers and links that take the user away from the GitLab application will have ... appended on to them if they exceed the line length. Example:
Linking to external sites |
---|
- Internal links: Links to Images or Files will be shown in a horizontally scrollable area with an icon that links to the location.
Linking to a file | Linking to an image | Linking to multiple images |
---|---|---|
Solution cases
If the solution is available, the solution section is always present and included directly below the Details section. All solutions are presented in an #f2f2f2
bounding box and the text is set in H4 - primary
. Below are the cases we must consider:
Text-based only solutions
Activity design
The activity area will be placed at the bottom of the vulnerability drawer and house all activity information related to the vulnerability. The activity will stack on each other just as we see it does in issues today with one minor change. We will remove the users handle (@name) and keep their first/surname to reduce line length. The hover state on the user's name will still reveal the same information as it does today.
Example:
Adding a comment to a dismissed vulnerability
If a vulnerability has been dismissed without a comment and a user wants to add a comment, they can in the activity section of the drawer.
Initial state | Adding a comment | Comment added | Long comment example |
---|---|---|---|
Deleting/editing a comment
Edit state | Deletion confirmation |
---|---|
What does success look like, and how can we measure that?
Users will be able to manage their vulnerabilities easier, ultimately managing more vulnerabilities during their session.
Users will view more information with this feature than they will if it were a modal.