Skip to content

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:

  1. a user creates an issue from a vulnerability
  2. a user changes the state of a vulnerability (e.g. open->confirmed, confirmed->resolved, etc)
    1. a user dismisses a vulnerability
    2. 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:

  1. 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.
  2. 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

Original description
### Description

As a follow up of #5151 (closed) we want to create system notes in a MR for following events:

  • a user dismisses a vulnerability
  • a user reverts a dismissal
  • a user creates an issue from a vulnerability

Edited by Andy Volpe