Merge Results and Security Policies: always detected as NEW with merge train pipelines

Summary

When using a security policy to trigger approval for NEW vulnerabilities and using merge trains, vulnerabilities are always detected as NEW.

Steps to reproduce

Customer has the following policy:

- name: No new critical vulnerabilities
  rules:
  - type: scan_finding
    scanners:
    - sast
    vulnerabilities_allowed: 0
    severity_levels:
    - critical
    vulnerability_states:
    - new_needs_triage
    branches: []
  actions:
  - type: require_approval
    approvals_required: 1
    role_approvers:
    - maintainer

Note that it reacts upon NEW findings only.

It works as expected, but when they enable merge train functionality, the vulnerabilities are always detected as NEW and therefore always reacted on.

What is the current bug behavior?

When enabling the merge train functionality, the issue occurs. It seems that when using merge trains, ALL vulnerabilities are always seen as NEW, and GitLab doesn't distinguish anymore at all between old (even triaged one) and actually new ones.

What is the expected correct behavior?

When using merge trains and configuring a security policy to trigger approval, it doesn't trigger for old/triaged vulnerabilities.

Results of GitLab application Check

Zendesk ticket

https://gitlab.zendesk.com/agent/tickets/560431