Investigate automatically restoring vulnerability statuses reset by semgrep 6.7.0 bug
Summary
As discusssed in GitLab Semgrep and Spotbugs analyzers are causi... (#573266 - closed) • Adam Cohen • 18.5, semgrep v6.7.0 had a bug which changed the primary identifier and resulted in duplicate vulnerabilities showing up in the Vulnerability Report.
This bug was fixed in semgrep v6.7.1, however, if a pipeline had executed using semgrep v6.7.0, and then again with semgrep v6.7.1, this would result in resetting the status of all existing vulnerabilities in the Vulnerability Report.
This happens because the bug broke the contract between our generated reports and the rails monolith in a way that the monolith was never designed to handle.
The purpose of this issue is to investigate automatically restoring vulnerability statuses that were reset by semgrep v6.7.0.
Proposal
We should first investigate whether we can create a script or commandline tool that uses the Vulnerability GraphQL API to restore the vulnerabilities.
If using the API isn't possible, then we'll need to look into creating a data migration.
With regards to the data migration, we need to figure out the following:
- Identify vulnerability records that were created with incorrect primary identifier values.
- Once we have the vulnerability records with incorrect primary identifier values, we need to determine the correct original vulnerability statuses for these records, possibly using the
vulnerability_state_transitionsDB table - Loop through the vulnerability records with incorrect statuses and restore them to the original status.