here’s the fully updated and GitLab 18.x Cloud–compliant answer to your original question:

---

✅ Enforcing Pipeline Standards with Limited Flexibility in GitLab 18.x Cloud (2025)

GitLab 18.x provides modern, centralized tools to enforce strict CI/CD standards while still allowing controlled customization across your projects.

---

🔹 1. Create Standardized CI/CD Templates

Use central CI/CD templates to define reusable pipeline logic that can be included in other projects.

✅ How:

• Store templates in a central project, e.g., devops/pipeline-templates
• Reference using include: in .gitlab-ci.yml of any project

include:
  - project: 'devops/pipeline-templates'
    file: '/secure-pipeline.yml'
Code language: PHP (php)

🔐 Tip:

You can lock template jobs by:

• Using rules: to control when they run
• Marking them as required via Pipeline Execution Policies (see below)

---

🔹 2. Implement Compliance Checks for Pipelines

GitLab 18.x replaces “compliance pipelines” with Pipeline Execution Policies — the official and enforced way to run compliance-required jobs.

✅ Where:

• Go to: Group → Secure → Compliance Center → Policies Tab
• Click “New Policy → Pipeline”

✅ Example Policy YAML:

Enforce SAST and Secret Detection on every push in all projects:

type: pipeline
name: enforce-sast-and-secrets
enabled: true
rules:
  - type: pipeline
    branches:
      include:
        - "*"
    project_filter:
      include:
        - "*"
actions:
  - scan: sast
  - scan: secret_detection
Code language: PHP (php)

You can also use:
action: job: job_name@group/project
to enforce your custom job templates.

---

🔹 3. Define Allowed Customization Options

Limit what project teams can customize by:

Strategy	How to Apply
✅ Use include: for central logic	Forces all teams to inherit your base pipeline
✅ Lock jobs via Execution Policies	Enforced jobs cannot be overridden by project maintainers
✅ Set global variables at group level	Use Group CI/CD variables to prevent secrets/config drift
✅ Use rules: in templates	Control when jobs run based on branches, tags, etc.
✅ Optional stages for teams	Let teams extend pipelines via extends: or workflow: rules:

Example: Central job with team-controlled overrides

.default_security_job:
  script: echo "Running standard security scan"

security_scan:
  extends: .default_security_job
  rules:
    - if: '$CI_PROJECT_NAME =~ /internal.*/'
Code language: PHP (php)

---

✅ Summary

Goal	GitLab 18.x Feature
Standard templates	include: from shared CI/CD projects
Pipeline compliance enforcement	✅ Pipeline Execution Policies (via Compliance Center)
Central control with limited flexibility	rules, extends, group variables, protected jobs
Custom job enforcement	job@group/project in execution policy

---

Here’s your complete GitLab policy project setup, designed for rollout across an entire group. It includes:

• ✅ A Pipeline Execution Policy YAML
• ✅ Centralized CI template project (secure-ci-templates)
• ✅ Enforced security scans (SAST, Secret Detection)
• ✅ A compliance approval check
• ✅ A deploy guard to prevent unreviewed changes to main

Use this with:

1. GitLab Group → Secure → Compliance Center → Policies → New Policy
2. Paste the pipeline YAML from the top section
3. Reference the central project in your teams’ .gitlab-ci.yml as shown