GitLab security policies come in four types. Scan execution policies force scans to run. Merge request approval policies require approvals based on scan results. Pipeline execution policies enforce CI jobs. Vulnerability management policies auto-resolve findings that are no longer detected. All require Ultimate.
The four types
| Policy type | What it enforces | Typical use |
|---|---|---|
| Scan execution | Security scans run in pipelines or on a schedule | Make sure every project is scanned |
| Merge request approval | Approval rules and project settings based on scan results | Block risky merges until reviewed |
| Pipeline execution | Specific CI/CD jobs in project pipelines, including scheduled ones | Required build or compliance steps |
| Vulnerability management | Auto-resolves vulnerabilities no longer detected on the default branch | Keep the report clean |
The GitLab page lists Ultimate as the tier, on GitLab.com, Self-Managed and Dedicated.
Why teams get confused
Scan execution says "run the scanner." Approval policy says "if the scanner found this, a human must approve." They work together, but they are separate. If a scan never runs, an approval policy has nothing to evaluate, so a missing scan can quietly weaken your gate. Pairing the two is the usual fix.
Scoping
A policy can be limited with policy_scope to groups, projects, compliance frameworks or security attributes such as business impact and exposure. The match_mode setting controls whether all conditions or any condition must match. An empty collection is treated as if the field were omitted, so the policy applies to everything. To switch a policy off, set enabled to false.
How policies are stored
Policies live in .gitlab/security-policies/policy.yml in a security policy project. Changes sync only when a merge request is merged into that project, so direct commits to its default branch are not synced. To enforce a policy project on a group or project you need the Owner role, or a custom role with the manage_security_policy_link permission.
One trap: avoid linking one security policy project to both a development project and its parent group. The documentation says that prevents merge request approval rules from applying to that project.
A sensible first policy set
- A scan execution policy that runs secret detection and dependency scanning on all projects.
- A merge request approval policy that requires security review for critical findings on protected branches.
- Warn mode first if your teams are new to gates, then enforce.
- A named owner for the policy project and a review cycle.
Where a dedicated scanner fits
If you need the same gates across repositories on more than one host, or want guardrails for AI coding agents next to your merge rules, a separate platform can carry that. Safeguard provides policies, gates and guardrails, plus the MCP Guardrail, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what a gate decides on a pull request and which finding triggers it.
Quick check
Do approval policies run the scans themselves?
No. They evaluate results after CI scan jobs complete. Use a scan execution policy to make sure the scans run.
Where are GitLab security policies defined?
In a file named policy.yml under .gitlab/security-policies in a security policy project.
Sources
Last reviewed: 19 October 2026.
