DESIGN: Bulk status update for Security Dashboard
Background
For the Security Dashboard, when a customer makes a change to correct a vulnerability, the next time the scan runs and the dashboard is updated, it stills shows as a detected vulnerability. When you click into the vulnerabilities one by one, you’ll see a notice at the top saying that it is no longer detected and to please confirm that it is resolved. There should be a way to bulk update the findings to resolved instead of one by one, as doing so one by one is time-consuming and frustrating.
Problem
The current vulnerability report experience is not optimized for users who want to quickly set the status for a vulnerability or a set of vulnerabilities that share a similar attribute or resulting status.
User
Common Role: Persona: Security Analyst
Performer: Vulnerability manager
When I am managing vulnerabilities, I want to address similar vulnerabilities all at once, so I can save time and effort by not needing to go back and forth to each page to make a status change.
Proposal
Allow users to change the status on a set of vulnerabilities at the same time.
MVC
Users will be able to:
- Change the status of multiple vulnerabilities in the list at one time
- Add a comment when changing the status of multiple vulnerabilities
- Select a dismissal type
- Accept risk
- False positive
- Mitigating control
- Out of scope
Requirements
- Store the dismissal reason (e.g. False Positive, Won't Fix) for all vulnerabilities when bulk dismissed
- Store any comment ("Reason for status change...") made with any bulk status change
- Record the user who made the bulk change
- Record the time of the bulk change
- The Status change (with reason, if a dismissal) appears on each affected vulnerability's details page along with who made the change and when. This is the same as current behavior when manually updating a single vulnerability's status (see example below).
- Any comment left with a dismissal reason appears on each affected vulnerability's details page along with who made the comment and when. This is the same as the current behavior when leaving a comment directly on a vulnerability object (see example below).
Design
Future consideration:
From the design exploration, we've uncovered future opportunities to consider after the MVC implementation
Dismissal types: (Could be incorporated into this effort)
- Display of dismissal types in the vulnerability page
- Ability to add/edit/remove dismissal type in the vulnerability page
- Metrics to display dismissal type trends to users
Enhanced actions:
- Ability to bulk create issues
- Ability to bulk attach to issues
- Ability to attach multiple vulnerabilities to a single issue
- Ability to bulk patch vulnerabilities