A history should be kept of vulnerability state changes and their reasons
Release notes
A history should be recorded of the reasons for vulnerability state changes
Problem to solve
Currently the vulnerabilities_feedback
table captures comments on vulnerabilities. This is used both by users, as well as by the vulnerability dashboard when vulnerabilities are bulk-dismissed. Unless I'm misunderstanding how the code works (maybe I am), the vulnerability_feedback
table does not keep a history of the comments and only tracks the current comment for a specific vulnerability. Not recording a history of state change reasons prohibits auditability. The overlap between user-provided comment data and GitLab-provided comment data makes the comment text hard to operate on.
Additionally, requiring a reason for every state change will help us more clearly present the vulnerability's state to the user. The issue Remediated badge for vulnerability report is misleading is an example of this, with these comments specifically discussing other uses for vulnerability state change reasons besides the dismissed state.
Examples of Vulnerability State Change Reasons
Below are examples of how reasons for vulnerability state changes could apply to the different, current vulnerability states (copied from my comment on Remediated badge for vulnerability report is misleading):
state | feedback |
---|---|
detected |
|
dismissed |
|
resolved |
|
confirmed |
|
Intended users
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
- Cameron (Compliance Manager)
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
- Sam (Security Analyst)
- Alex (Security Operations Engineer)
- Simone (Software Engineer in Test)
- Allison (Application Ops)
User experience goal
Users should be able to see the reasons for a vulnerability changing state.
Proposal
- All vulnerability state changes should be accompanied by a reason
- All vulnerability state changes + reasons should be tracked in a
vulnerability_state_history
(or similar) table
Future iterations could:
- Expose the reasons for vulnerability state changes to the user (for example, the
remediated: needs attention
badge)