Modify the Vulnerability creation/remediation flow to represent Vulnerability made up of Taint Flow
This issue was created based on the decision taken in https://gitlab.com/gitlab-org/gitlab/-/issues/456135+.
Today our vulnerabilities' uniqueness is calculated only based on the Sink.
Once we complete MS1 of the oxeye integration (GitLab Advanced Sast) we will have a taint flow for each vulnerability scanned by the Advanced Sast.
When taint flow is available, We should consider the entire flow when defining new/existing vulnerabilities (motivation for this can be found in the issue mentioned above).
The basic principle will be that each unique flow (different by source/propagations/sink) should have its unique vulnerability (1:1 relationship) :
- Once we discover a new flow that doesn't exist - create a new vulnerability.
- Once we no longer see existing flow - we can mark it as remediated.
In order to apply this new vulnerability creation/remidiation strategy, we should consider the following topics:
- Backward compitability with previously existed vulnerabilities.
- possible required changed in tracking items representation.
- wider changes in the SAST report (and how it affects the rest of the scanners/analyzers?) - code flow data will not only used for display (details) but for calculating the uniqness of the vulnerability.
- additions to the finding information in DB (not a must, UUID can be calculated upon the data from report and then ignored (if a copy exists in the "details"))
- tbd