Auto-creation of Vulnerabilities from Findings in default branch (backstage)
Problem to solve
According to the recent evolution of the First-class Vulnerabilities UX, every Finding (formerly, Occurrence) that gets to the project's default branch and is persisted in the DB should be already accessible by a URL to start the discussion on the vulnerability details. That is, the Vulnerability should be available before the confirmation of a Finding.
This change simplifies the Findings/Vulnerabilities UX greatly and reduces the required amount of frontend work.
It was decided that every new Finding getting to the default branch should auto-create the associated first-class Vulnerability object. The newly created Vulnerability will be in opened state. After, it could be made confirmed, resolved, or dismissed.
Permissions and Security
No new or changed permissions are required. Auto-created Vulnerabilities are going to be confidential.
No documentation is going to be added. This is a backstage change that does not touch any public APIs. The First-class Vulnerabilities feature in general is hidden behind the feature flag. The documentation on the entire feature is yet to be added and should be correlated with the feature flag removal.
Unit tests are going to be added for the service classes that perform post-merge actions on the default branch pipeline.
What does success look like, and how can we measure that?
Security analysts are able to interact with the Vulnerabilities in the project's default branch even before it has been confirmed.