Extend unblock_rules_using_execution_policies to recognize scans skipped via rules:changes on source branch

Summary

MR Approval Policies should recognize when security scans are intentionally skipped on the source branch due to rules:changes conditions, and not require approval for those scan types.

Problem

When security scans are configured with rules:changes to optimize pipeline performance (only running when relevant files change):

  1. A scan may be legitimately skipped because no relevant files changed in the MR
  2. The MR Approval Policy still requires approval because GitLab cannot distinguish between an intentional skip vs. a malicious bypass
  3. This creates unnecessary approval requirements and friction for developers

Current behavior: If a specified scanner doesn't output a security report on the source branch, approvals are enforced as a precautionary measure—GitLab cannot distinguish between an intentional skip (via rules:changes) vs. an attempt to bypass security scanning.

Desired behavior: MR Approval Policies should recognize when a scan was skipped due to rules:changes conditions (no relevant files changed) and not require approval for that scan type.

Gap Analysis

Scenario Current Solution Status
Scan artifact missing on target branch policy_tuning.unblock_rules_using_execution_policies ✅ Available
Scan intentionally skipped on source branch (via rules:changes) No solution ❌ Gap

The existing unblock_rules_using_execution_policies setting addresses missing scans on the target branch when a Scan Execution Policy is in place, but does not address the source branch scenario.

Proposal

Extend the policy evaluation logic to recognize when:

  1. A Scan Execution Policy exists that would normally require a scan
  2. The scan job was present in the pipeline configuration but was skipped due to rules:changes (or similar conditional rules)
  3. In this case, the Approval Policy should not require approval for that scan type

This could potentially be an extension of the unblock_rules_using_execution_policies behavior or a new policy_tuning option.

Use Case

Organizations want to optimize CI/CD pipeline performance by only running security scans when relevant files change. For example:

  • SAST only runs when source code files change
  • Dependency scanning only runs when dependency manifest files change

Without this feature, teams must choose between:

  • Running all scans on every MR (inefficient)
  • Accepting unnecessary approval requirements when scans are legitimately skipped
  • Not using MR Approval Policies for security scans

Investigation and implementation plan:

See #585752 (comment 3082363554) for the investigation.

Plan:

Edited by Martin Cavoj