Security Policies, Scan Execution, Pipeline Execution, Approval Policies, and Compliance Controls: Configuration, Design Choices, and Tradeoffs

1. Central policy versus project-owned configuration

Project-owned CI is the simplest choice when the project team legitimately owns both the requirement and implementation. Central policy is justified when the control must survive project edits, must be consistent across many projects, or must be owned by a separate security/compliance function.

2. Preventive enforcement versus detective reporting

A preventive control blocks or changes delivery behavior before an unsafe action completes. An MR approval policy that requires approval before merge is preventive. A detective control records a violation and lets the workflow continue, such as a warn-mode policy or compliance report that creates review evidence.

Do not make every signal blocking. If a low-confidence scanner frequently fails, a hard gate can train developers to seek bypasses. Conversely, a critical separation-of-duties requirement should not be implemented as an informational dashboard only.

3. Scan execution versus pipeline execution versus approval policy

The decision is about what must happen and when GitLab can know the answer.

4. Pipeline execution strategy is an architectural choice

Current GitLab pipeline execution policies support inject_policy and override_project_ci; inject_ci is deprecated. inject_policy adds policy jobs while retaining project CI. override_project_ci gives policy authors much stronger control and must deliberately include any project configuration that should remain.

For organization baselines, prefer the least invasive strategy that satisfies the requirement. Reserve override_project_ci for cases where replacement/controlled merging is an explicit governance decision, because stage-order and duplicate-job mistakes can break delivery.

5. Strict global baseline versus scoped exceptions

Start with the broadest requirement that is actually universal, then narrow exceptions explicitly. Policy scope can target projects, groups, and compliance frameworks. Inheritance lowers administrative overhead, but incorrect scope can either leave gaps or break unrelated projects.

Use warn mode where supported to measure impact before strict enforcement. Current merge request approval-policy warn mode is GA and creates auditable bypass behavior when a user dismisses a violation.

6. Scope logic needs the same rigor as firewall rules

policy_scope conditions can interact. The default matching behavior is restrictive all; current GitLab also supports match_mode: any. Combining broad exclusions with any can unexpectedly widen scope. Treat scope changes as code and calculate the affected project set before merging.

# Synthetic scope review table, not GitLab API output
projects:
  101 payments-api      regulated      INCLUDE
  102 docs-site         none           EXCLUDE
  103 legacy-worker     exception      EXCLUDE until 2026-09-30
# Review output should name concrete project IDs/paths, not only labels.

7. Compliance framework versus security policy

Compliance frameworks (Premium/Ultimate) identify projects that share requirements and can carry controls. In Ultimate, security policies can scope enforcement by compliance framework. This yields a clean separation: project/framework classification is maintained by governance owners; enforcement logic remains in security policy projects.

Do not assume a framework label is itself a complete control. A label says “this project is in scope.” You still need enforceable settings/policies and evidence that controls are operating.

8. Worked production scenario

A platform team owns 80 services. Twenty process regulated data; ten are legacy systems with a temporary exception. Choose an architecture:

9. Reliability, performance, and cost are policy properties

Central jobs add runner queue time, compute, network use, artifact/report storage, and possible external-system pressure. Avoid “more scans everywhere” without understanding pipeline critical paths. Scheduled policies create additional pipelines even without commits. Policy failure behavior should be designed so deterministic misconfiguration fails visibly rather than creating retry storms.

10. Decision checklist

• What exact requirement is being enforced?
• Who owns the requirement, policy code, and target project?
• What is the smallest policy type that can enforce it?
• What linked unit and scope produce the intended project set?
• What evidence proves enforcement worked?
• What happens if the policy CI file is unavailable?
• How are exceptions owned, expired, and audited?
• What is the rollout and rollback plan?
• What compute/latency/storage impact will central enforcement add?

Knowledge check

Summary and bridge

A production policy architecture balances central enforceability with developer autonomy, fail-safe behavior, explicit scope, and auditable exceptions. Lesson 4 stress-tests that design with realistic failure modes and diagnostics.

Primary sources and version notes

These lessons were finalized against current official GitLab documentation on 2026-08-22. Re-check tier, feature status, policy schema, permission, audit-event, and Self-Managed-version behavior before applying the same design later.

• GitLab 19.3 release
• Security policies
• Policy enforcement
• Security policy projects
• Scan execution policies
• Pipeline execution policies
• Scheduled pipeline execution policies
• Merge request approval policies
• Compliance frameworks
• Compliance and security policy groups
• Compliance and policy settings API
• Audit event types