Vulnerability Widget incorrectly shows existing vulnerabilities as new when using merge commits with a long-lived source branch

Summary

Vulnerability report shows existing vulnerabilities as new when using merge commits with a long-lived source branch.

Workaround

Enable fast-forward merges in the merge request settings.

OR

Enable merged results pipelines

Steps to reproduce

1. Create a new group
2. Create a project inside that group (ex: https://gitlab.com/bwill/rails)
3. In the group, go to Secure -> Policies -> New Policy -> Scan Execution Policy -> .yaml mode and paste the scan execution policy below.
4. Merge the MR created by the security policy wizard.
5. Add secrets or code that triggers a specific vulnerability to the default branch. To do this on the bwill/rails project:
   1. git checkout main
   2. git reset --hard b71b2d642ba64e385b28d7e3e7bb18293834e767
   3. git remote add gdk <gdk_repo>
   4. git push -u gdk main
   5. git checkout -b develop
   6. curl https://gitlab.com/-/project/278964/uploads/ac17754ef094bd5b03fd307fba67cc31/user_model.patch | git am - user_model.patch
   7. git push -u -o merge_request.create gdk develop
   8. Merge the MR. Do not delete the source branch
6. In the same branch, edit some content or file that's not related to the vulnerability and create the MR again.
   1. curl https://gitlab.com/-/project/278964/uploads/3d5388f048e9953d65b718ef7eb0f9f2/unrelated_change.patch | git am - unrelated_change.patch
   2. git push -o merge_request.create gdk develop
7. MR will show the old vulnerability as new again. This is not expected.

Configs:

Scan execution policy:

type: scan_execution_policy
name: SAST
description: ''
enabled: true
policy_scope:
  projects:
    excluding: []
rules:
  - type: pipeline
    branch_type: all
actions:
  - scan: sast

Merge request approval policy

approval_policy:
- name: MR approval
  description: ''
  enabled: true
  rules:
  - type: scan_finding
    scanners:
    - sast
    vulnerabilities_allowed: 0
    severity_levels: []
    vulnerability_states:
    - new_needs_triage
    branch_type: protected
  actions:
  - type: require_approval
    approvals_required: 1
    user_approvers_ids:
    - 1111111
  - type: send_bot_message
    enabled: true
  approval_settings:
    block_branch_modification: true
    prevent_pushing_and_force_pushing: false
    prevent_approval_by_author: false
    prevent_approval_by_commit_author: false
    remove_approvals_with_new_commit: true
    require_password_to_approve: false
  fallback_behavior:
    fail: closed

Example Project

Secret detection: https://gitlab.com/gl-demo-ultimate-pdumaitre/experiments/vulnerability-management-experiments/retail-banking/personal-banking-production-branch/-/merge_requests/7.

SAST: https://gitlab.com/psureshbabu_ultimate_group/sast-test/.

What is the expected correct behavior?

Existing vulns are filtered out of the security widget.

Relevant logs and/or screenshots

Output of checks

 I checked the MR security widget docs and all conditions seem satisfied:

• feature branch was created from the target branch.
• origin commit was scanned, the last pipeline is a merge pipeline with successful scans that ran and did detect the vulnerabilities we’re talking about

A few links and screenshots:

• mr showing new vulns
• list of commits for feature branch and target branch pointing to the origin commit 34f30629
• last pipeline on origin commit having run for master: finds the same 2 commits

Results of GitLab environment info

gitlab.com

Possible fixes