Create System Notes when interacting with a vulnerability
Context
It is important to provide a traceable way to understand the lifecycle of a given vulnerability. This is useful for auditors and security teams, who are concerned with the lifecycle of a vulnerability & that it has gone through and when it has gone through various processes and stages.
Proposal
Create a system event when a user interacts with a vulnerability. Specifically, create a system event when:
- a user creates an issue from a vulnerability
- a user changes the state of a vulnerability (e.g.
open->confirmed,confirmed->resolved, etc)- a user dismisses a vulnerability
- a user reverts a dismissal
This is in context of the standalone vulnerability itself, not inside the MR. It is also not needed to be displayed in the vulnerability modal window either.
Designs:
Status change cases:
When a user reverts a dismissal, we'll communicate that as we do with the system note set above. So if a user changes status from dismissed to confirmed we'll communicate that with the confirmed system note since we have a note structure:
[Icon] [user name] [@user handle] "Changed vulnerability status to x" [friendly timestamp]
Primarily, we will do this as opposed to having a unique system note for reverting the dismissal because:
- we assume when a user reverts a dismissal it is because the initial dismissal was erroneous due to some type of investigation or re-evaluation. In this case, the user will set the status to confirmed.
- we don't allow users to set the vulnerability back to the open status once the status has manually been changed. Allowing this action would cause a breakdown in communication in the dashboard since the vulnerability had been triaged and the open status is meant to communicate to the user that the vulnerability has not been reviewed/triaged yet.
Creating an issue from a vulnerability case:
The syntax will be a bit different from status change:
[Icon] [user name] [@user handle] "Created issue #123456 from vulnerability" [friendly timestamp]
For this iteration, we won't allow users to disassociate an issue created from a vulnerability due to the assumption that it will cause a break in the SSOT and workflow for the vulnerability. With this understanding, we won't have a system note for disassociating an issue from a vulnerability until we include the feature to allow users to link multiple issues to a vulnerability.
Dependencies
As a follow up of #5151 (closed) we want to create system notes in a MR for following events: