A GitLab merge request approval policy requires extra approvals on a merge request when scan results, license findings or merge request conditions match a rule. It is evaluated after CI scan jobs finish and applies to protected target branches. It is an Ultimate tier feature.
The three rule types
| Rule | Matches |
|---|---|
| scan_finding | Findings from SAST, secret detection, dependency scanning, container scanning, DAST and fuzzing, filtered by severity, state and attributes such as fix availability, known exploitation and EPSS score |
| license_finding | SPDX licenses on allowed or denied lists, with optional exclusions |
| any_merge_request | Any merge request, or only those with unsigned commits |
Dependency scanning findings can also block malicious packages. Each policy holds up to five rules.
Actions
require_approvalsets a number of approvals from users, groups or roles, up to five such actions.send_bot_messageposts a comment listing violations. It is on by default.approval_settingsoverrides project settings, for example preventing authors from approving their own change or removing approvals when new commits arrive.
Enforce or warn
In enforce mode, which is the default, a violating merge request is blocked until approved. In warn mode it can proceed with warnings, and users can bypass by giving a reason that is audited. Warn mode is a good first step while a team learns what the gate catches.
What happens when a scan is missing
This is where gates quietly fail. Every scanner named in a rule must produce a report on both the source and target branches. Missing reports, or failed or cancelled scan jobs without reports, typically require approval. The fallback_behavior setting decides what happens when rules cannot be evaluated: closed, the default, requires approval, and open does not.
Limits to know
- Manual jobs are ignored until they run.
- Policies do not verify the integrity or authenticity of scan artifacts.
- You get up to five policies per security policy project.
- Changing a vulnerability state does not re-evaluate until a pipeline reruns or the merge request updates.
- Group level policies can take minutes to propagate in large groups.
A cautious rollout
- Pair the policy with a scan execution policy so scans always run.
- Start with critical severity and fixes available, then widen.
- Use warn mode for two weeks and count how often it fires.
- Define bypass for service accounts and emergency fixes, with an audit review.
- Switch to enforce.
Where a dedicated scanner fits
If you want one gate rule that applies across hosts, or want exploitability and reachability to inform the decision, a separate platform can add that. Safeguard supports policies, gates and reachability analysis, with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Change the finding severity and see when the gate flips from pass to blocked.
Quick check
What happens if a required scan fails?
By default the fallback is closed, so approval is typically required when a report is missing.
Do approval policies cover every branch?
No. They apply to protected target branches.
Sources
Last reviewed: 19 October 2026.
