Security policy/policies is enforced on merge requests if CI/CD is disabled

Summary

Reproduced on GitLab 15.2.2-ee

When a pre-existing security policy is enabled and linked to the current project, the security policy is enforced on new merge requests even if CI/CD is disabled in the project.

While this doesn't block the MR from being approved and merged, it seems a little odd that the security policy is being applied to the merge request even though there is no vulnerabilities to check.

Steps to reproduce

1. Create an empty project, and add another member to that project

2. Disable CI/CD on the project.

3. Within the project, create a security policy. For example, this is what I used (adjust the approver IDs to the member you just added in the project):

   ---
   scan_result_policy:
   - name: critical-high-approval
     description: ''
     enabled: true
     rules:
     - type: scan_finding
       branches: []
       scanners:
       - container_scanning
       - dependency_scanning
       vulnerabilities_allowed: 5
       severity_levels:
       - critical
       vulnerability_states:
       - newly_detected
     actions:
     - type: require_approval
       approvals_required: 1
       user_approvers_ids:
       - 139

4. Make a small change within the project and push it to a new branch. Create a merge request.

5. Notice that the merge request has the security policy in the approvers list

   

6. Do note that if I impersonate the user that is in the security policy approvers list, they are able to approve the MR:

   

Example Project

N/A

What is the current bug behavior?

Security policies are applied as approvers to new merge requests even if CI/CD is disabled.

What is the expected correct behavior?

Security policies should not be applied as approvers to new merge requests if CI/CD is disabled.

If CI/CD is disabled on a project, how should we handle pre-existing security policies?

Relevant logs and/or screenshots

N/A

Output of checks

N/A

Results of GitLab environment info

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)

Workarounds

• Disable the security policy and recreate any MRs where the security policy has applied.
• Remove the security policy project link and recreate any MRs where the security policy has applied.

Possible fixes