### 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 https://gitlab.com/gitlab-org/gitlab/-/work_items/585752#note_3082363554 for the investigation. Plan: - Fix incorrect documentation in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/223367+ - Address an identified gap with canceled jobs: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/223614+