Security Policies

You can automate vulnerability management and enforce requirements on merge requests, security scans, and pipeline execution with policies.

Merge Request Approval Policies

GitLab enforces security requirements at the merge request level, not at the pipeline level. When a policy is triggered, GitLab automatically adds required approvers to the MR — the pipeline itself continues to pass, but the merge is blocked until the required approvals are obtained.

Policy configurations are not stored in your project repository. GitLab automatically creates a dedicated Security Policy Project — a separate repository linked to your project — the first time you save a policy. All policy definitions live there as YAML files, versioned and auditable independently from your code.

Two types are available, depending on what triggers the policy:

Security Approval Policies

Security Approval Policies trigger when scan results meet defined criteria. Filters can be based on:

• Vulnerability severity (Critical, High, etc.)
• Scanner type (Dependency Scanning, Container Scanning, SAST, etc.)
• Newly introduced vulnerabilities only (vs. pre-existing ones)

License Approval Policies

License Approval Policies trigger when a dependency introduces a disallowed license. Filters can be based on:

• Denied license list (e.g., GPL-3.0, AGPL-3.0)
• Allowed license list (block anything not explicitly permitted)
• Unknown licenses

Scan Execution Policies

Scan execution policies allow you to enforce running specific security scanners for projects and groups.

Pipeline Execution Policies

Pipeline execution policies allow you to enforce specific pipeline jobs and pipeline configurations for projects and groups.

Vulnerability Management Policies

Vulnerability management policies allow you to automatically resolve vulnerabilities found by scanners in your projects.