Security Policy blocks merge even if the conditions of the policy are not met anymore

Summary

When setting up a security policy to demand special MR approval in the presence of a high severity security issue, the policy remains active even if the conditions are not met anymore for example by fixing the high severity issue in the context of the MR.

Steps to reproduce

The sequence below is extracted by investigating a customer project that was shared with us -- this is roughly the sequence of steps but it lacks detail at the moment. Some details that hopefully help reproducing the issue may be added in the future (e.g., the concrete policy configuration).

1. Create GitLab project with SAST enabled.
2. Create a security policy (require approval for high/critical severity issues).
3. Create a branch, ingest high severity issues (for example by coping https://gitlab.com/gitlab-org/security-products/sast-rules/-/tree/main/c?ref_type=heads) into your branch and create an MR.
4. Upon creating the MR, there will be a security bot notification.
5. Remove all high severity issues from file created in step 3. Now, the conditions of the policy are not met anymore.
6. Although the conditions of the policy are no longer met, it remains active.

Example Project

What is the current bug behavior?

Security policy conditions do not seem to be checked regularly.

What is the expected correct behavior?

The satisfaction of the conditions of a policy should be checked with every change applied to a branch.