MR Approval Policy does not get re-evaluated after vulnerability state is changed

Summary

MR Approval Policy for Newly Dismissed Vulnerability Only takes affect After Rerunning the Pipeline

Steps to reproduce

1. Create a policy as follows

   approval_policy:
     - name: newly_dismissed_vul
       description: ''
       enabled: true
       rules:
         - type: scan_finding
           scanners: []
           vulnerabilities_allowed: 0
           severity_levels:
             - critical
             - high
           vulnerability_states:
             - new_dismissed
           branch_type: protected
       actions:
         - type: require_approval
           approvals_required: 1
           role_approvers:
             - developer
         - type: send_bot_message
           enabled: true
       approval_settings:
         block_branch_modification: true
         prevent_pushing_and_force_pushing: true
         prevent_approval_by_author: true
         prevent_approval_by_commit_author: true
         remove_approvals_with_new_commit: true
         require_password_to_approve: false
       fallback_behavior:
         fail: closed
   

2. Introduce New vulnerabilites via an MR

3. Dismiss the Vulnerability

4. MR status does not change and still can be merged

5. Re-Run the MR pipeline, the policy gets evaluated and MR status changes to approval needed.

Example Project

What is the current bug behavior?

Policy Only gets evaluated after Re-Running the pipeline

What is the expected correct behavior?

After a vulnerability dismissal, the MR approval policy should also gets evaluated and blocks the MR.

Relevant logs and/or screenshots

1. New Vulnerabilities introduced

   

2. Dismiss the Vulnerability

   

3. MR can still be merged (should require an approval since vulnerability is dismissed)

4. Re-Run the same pipeline manually

5. Status changes to Requires Approval.

   

Output of checks

Results of GitLab environment info

Gitlab.com

Expand for output related to GitLab environment info

 (For installations with omnibus-gitlab package run and paste the output of: \`sudo gitlab-rake gitlab:env:info\`)  (For installations from source run and paste the output of: \`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\`)  

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:check SANITIZE=true`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`)

(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.