Design: Dismissal types / reasons
Problem to solve
Today we don't consistently give users a quick way to add a reason for dismissing a vulnerability; there are quick responses from the main Security Dashboard screens but not other places. This makes the act of writing a comment for every vulnerability that needs to be dismissed a labor-intensive task.
Intended users
Further details
Proposal
- Provide users a way to quickly select a predefined reason for dismissing a vulnerability.
- Provide users with a way to track/audit vulnerability dismissal exemptions.
- Extend the ability of selecting a reason beyond the Vulnerability Report to other key areas of vulnerability interaction.
Dismissal reasons / exemptions
Below are the reasons why a vulnerability will not be addressed.
| Exemption | Definition |
|---|---|
| Acceptable risk | The vulnerability is known, and has not been remediated or mitigated, but is considered to be an acceptable business risk. |
| False positive | An error in reporting in which a test result incorrectly indicates the presence of a vulnerability in a system when the vulnerability is not present. |
| Mitigating control | A management, operational, or technical control (i.e., safeguard or countermeasure) employed by an organization that provides equivalent or comparable protection for an information system. |
| Used in tests | The finding is not a vulnerability because it is part of a test or is test data. |
| Not Applicable | The vulnerability is known, and has not been remediated or mitigated, but is considered to be in a part of the application that will not be updated. |
Design
Additional exemptions to consider:
Documentation
Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Links / references
Edited by Andy Volpe