Inconsistent behavior of the merge request approval policy with its document for MRs that target branches that have never had a security scan run in the past.

Summary

The documentation states

Merge request approval policies | GitLab

• If security scans are missing on either the source or target branch, GitLab cannot effectively evaluate whether the merge request is introducing new vulnerabilities. In such cases, approval is required as a precautionary measure.
• For new projects where security scans have not yet been set up or executed on the target branch, all merge requests require approval. This ensures that security checks are active from the project’s inception.

However, in the actual behavior, the MR will not be blocked when no vulnerabilities are detected on the source branch even if there is no history of security scans on the target branch.

This seems to contradict the document.

Steps to reproduce

1. Create a project
2. Set up a scan execution policy to run the secret detection
3. Set up a merge request approval policy to block MRs to add secret
4. Create branches to be used as a source and target branches in the test
5. Add a file that contains secret to a source branch
6. If any pipelines had to be run on the target branch at this point, delete them.
7. Open an MR

Example Project

• https://gitlab.com/kkamiya_gl/595220-20250120-test1 (unblock_rules_using_execution_policies: true)
• https://gitlab.com/kkamiya_gl/595220-20250120-test2 (unblock_rules_using_execution_policies: false)

What is the current bug behavior?

Even if there is no history of security scans being run on the target branch, the MR will not be blocked when no vulnerabilities are detected on the source branch

What is the expected correct behavior?

If there is no history of security scans being run on the target branch

• The MR requires approval if unblock_rules_using_execution_policies: false
• The MR does not require approval if unblock_rules_using_execution_policies: true

Relevant logs and/or screenshots

Here are test results on the above example projects. I tested the possibility that the setting of unblock_rules_using_execution_policies was affecting the results, but I was unable to confirm any effect.

Test1

• Conditions
  • unblock_rules_using_execution_policies: true
  • No history of secret detection execution in the target branch. 
  • No secret is added in the source branch
• Results
  • Approval is Optional
  • kkamiya_gl/595220-20250120-test1!1

 
Test2

• Conditions
  • unblock_rules_using_execution_policies: true
  • No history of secret detection execution in the target branch.
  • New secret is added in the source branch
• Results
  • Approval is Required (unexpected since there is no history of security scan in the target branch and unblock_rules_using_execution_policies: true)
  • kkamiya_gl/595220-20250120-test1!3

 
Test3

• Conditions
  • unblock_rules_using_execution_policies: true
  • There is a history of secret detection execution in the target branch.
  • No secret is added in the source branch
• Results
  • Approval is Optional
  • kkamiya_gl/595220-20250120-test1!4

 
Test4

• Conditions
  • unblock_rules_using_execution_policies: true
  • There is a history of secret detection execution in the target branch.
  • New secret is added in the source branch
• Results
  • Approval is Required
  • kkamiya_gl/595220-20250120-test1!5

Test5

• Conditions
  • unblock_rules_using_execution_policies: false
  • No history of secret detection execution in the target branch. 
  • No secret is added in the source branch
• Results
  • Approval is Optional (unexpected because there is no history of security scan in the target branch and unblock_rules_using_execution_policies: false)
  • kkamiya_gl/595220-20250120-test2!1

Test 6

• Conditions
  • unblock_rules_using_execution_policies: false
  • No history of secret detection execution in the target branch.
  • New secret is added in the source branch
• Results
  • Approval is Required
  • kkamiya_gl/595220-20250120-test2!2

 
Test 7

• Conditions
  • unblock_rules_using_execution_policies: false
  • There is a history of secret detection execution in the target branch.
  • No secret is added in the source branch
• Result
  • Approval is Optional
  • kkamiya_gl/595220-20250120-test2!3

 
Test 8

• Conditions
  • unblock_rules_using_execution_policies: false
  • There is a history of secret detection execution in the target branch.
  • New secret is added in the source branch
• Result
  • Approval is Required
  • kkamiya_gl/595220-20250120-test2!4

Output of checks

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)

Possible fixes