Vulnerability fingerprints for feedback are not generated the same way on BE and FE for Container Scanning and DAST
The feedback feature relies on a legacy property called the
Due to the current architecture that splits raw report processing between backend and frontend we have that fingerprint generated in different places.
Unfortunately when we implemented the backend parsers we did not exactly follow the same approach as frontend (for good reasons) but missed to update it, which ends up in generating different fingerprints. This prevents from matching a given feedback with a vulnerability reported on the Group Security Dashboard and the "same" vulnerability displayed on the other places (MR, Pipeline, Project Dashboard).
This issue already happens for various reasons (code is updated, so fingerprint is updated) and that's why the feedback feature is still considered unstable, but this specific bug adds more misses that could be avoided.
Important consideration: A side effect of updating frontend fingerprint generation is that we will loose all existing feedback created for Container Scanning and DAST on MRs, Pipeline view and Project Dashboard since we launched them. By loosing I don't mean we will drop created records from DB, but that we might not be able to display them anymore. E.g. the issue will still exists, but you won't see it attached to your vulnerability. Though this seems aligned with our Alpha stage description:
data loss can occur (be that through bugs or updates).
Steps to reproduce
- create a feedback (issue or dismissal) on a vulnerability reported on the project dashboard for Container Scanning
- display that vulnerability on the Group Dashboard and discover it is not dismissed.
What is the current bug behavior?
Feedback created from Group Dashboard is not found in other places, and vice versa.
What is the expected correct behavior?
Feedback created from Group Dashboard is also visible in other places, and vice versa.
Relevant logs and/or screenshots
project_fingerprint generation methods between frontend and backend. We might double check but the backend way is probably the one we want to keep, as it's based on more up to date discussions and knowledge.
- backend Extract vulnerability formatting logic for reuse in fingerprint migration https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14879
- backend Migrate feedback for default branch occurrences to new fingerprint https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14848
- backend Recreate old fingerprint matching for non-default branch occurrences on the backend
- frontend Remove old fingerprint matching from frontend
- backend Migrate feedback for non-default branch occurrences
- Move fingerprint matching for pipeline occurrences to the backend
- Use a migration to update non-default branch feedback
Both decisions where made during a Zoom meeting. Notes from the meeting are https://docs.google.com/document/d/1yiKFW6--K3kYhhckSXjEtozFCLYhrGTzjLgbhQQBLwI/edit?usp=sharing
- Do we need a feature flag for any of this work?