UX product discovery for first-class vulnerabilities
This issue is for the UX product discovery process for first-class vulnerabilities. More details to follow.
Approach: Unique vulnerability object
Benefits:
- Creates a stable vulnerability object in the DB with feedback hooks into issues and merge requests.
- Increase the potential to enhance the vulnerability object in future iterations with features that aide in the triage process, 3rd party integrations, and communication between security and engineering teams.
- Reduce risk by keeping the integration with issues to a minimum until more research can be conducted.
- Reduce risk by not creating a unique issue type which may present unknown conflicts within the product
- Reduces changes introduced into the product and confines them to the security area.
Risks:
- Adds an additional step to the process that could benefit security users, not add friction. Our initial direction was to avoid adding an additional step to the process in which our research-backed up. This workflow might not benefit from optimization right from the start as there is nothing to optimize. We need to get a foundation in place before we consider optimization.
Global changes to note:
What we are referencing in the UI today as "Vulnerabilities" will now be called "Findings".
Findings: A reference to something our analyzers have detected as a weakness, flaw, error, or vulnerability (cve) in our users' project. Findings can be dismissed and can contain dismissal comments like they do today. Findings can also be confirmed which creates a unique vulnerability object. The states of findings are:
- Unresolved: No action has been taken on the finding by the user
- Dismissed: The user has decided this is a false-positive or not impacting production. The dismissed state can also be accompanied by a comment or reason which will remain unchanged from today.
- Confirmed: The user has decided this finding needs attention, resolution or, further investigation by the engineering team.
Note: confirmed findings are removed from the findings list and moved to the vulnerability list. See use case 1 for more detail.
Vulnerability: A manually confirmed finding that a user has identified as something that needs to be fixed in the project. Vulnerabilities are stable database objects whereas findings are ephemera. A vulnerability can have an issue created from it which can subsequently have an MR created from that. Vulnerabilities can be Manually closed by users or resolved via a commit and MR. Vulnerabilities can also be reopened if manually closed. The vulnerability states are:
- Open: Default state after the finding as been confirmed. This is also the state after a vulnerability has been manually reopened by the user from the closed state.
- Resolved: State a vulnerability has when it is no longer detected in the default branch.
- Closed: State a vulnerability takes when a user manually closes the vulnerability. This may happen if it has been decided that the vulnerability is a false-positive or does not impact the production environment. We have this state since we reserve the dismissal state for findings. We choose this direction to avoid confusion and maintain separation between findings and vulnerabilities.
Vulnerabilities have a unique page and URL. Vulnerability states are reflected in the vulnerability list.
Use cases: (Primary)
*Note: use cases come with: *
- A story: what our user wants to do
- User action: what our user is doing in the UI
- System event: what the system is doing in the background
- Wireframes: a simple representation of what the UI and experience will look like
1. Confirming a vulnerability
2. Creating an issue from a vulnerability
3. Resolving a vulnerability
Use cases: (Secondary)
1. Closing a vulnerability
2. Reopening a vulnerability