Explore ways of tracking state changes of a Vulnerability
High-level problem statement
How do we track changes to the Vulnerability state with comments?
How did we discover the problem?
During work on #292636 (closed) it came to our attention that we have no sane way of extending GraphQL mutations for manipulating the state of a given Vulnerability to account for user comments.
Current approach
Currently we have four possible states for a Vulnerability:
-
Detected
–Vulnerability#state
isdetected
; there's noVulnerabilities::Feedback
that dismisses the vulnerability OR noVulnerabilities::Feedback
that ties theVulnerability
to anIssue
-
Dismissed
–Vulnerability#state
isdismissed
; there's aVulnerabilities::Feedback
that dismisses the Vulnerability -
Confirmed
–Vulnerability#state
isconfirmed
OR there'sVulnerabilities::Feedback
which ties theVulnerability::Finding
to anIssue
. We also rely on the fact that there should be noVulnerabilities::Feedback
that dismisses the issue -
Resolved
–Vulnerability#state
isresolved
Possible solutions
Vulnerabilities::Feedback#feedback_type
to account for confirmation and resolution
Extend The simplest solution in which we create additional values for vulnerability confirmation and resolution state. While I wrote the simplest I am not entirely convinced that is the simplest solution since we would have to create additional rules about how our system works.
If we extend Vulnerabilities::Feedback
to account for confirmation and resolution the we would have to make sure we have a Vulnerabilities::Feedback
record for every Vulnerability
that's either confirmed or resolved.
Pros:
- Kind of ties into the existing system
- Doesn't require that much backend work
Cons:
- Lots of database work
- This model will actually have two responsibilities: tracking Vulnerability state changes AND allowing us to take action of
Vulnerability::Findings
that did not get promoted to aVulnerability
yet
Track the changes in a different model
At this point I'm tempted to delegate this to another model – let's name it VulnerabilityStateChange
whose only concern would be tracking state changes for a given Vulnerability
Pros:
- Wouldn't affect
Vulnerabilities::Feedback
role - We can add as many states as we want without touching the
vulnerabilites
table - Would allow us to retain a clear history of Vulnerability state changes along with reasons for said changes
Cons:
Use Notable on Vulnerability
Here's how that looks like https://gitlab.com/gitlab-org/gitlab/-/snippets/2084288
Pros:
- Relatively simple
Cons:
- It's more of a free-form comment rather than a state tracking system