Module 9 Lesson 3: Compliance Pipelines

In a small company, you can "Ask" everyone to run security scans. In a large company, people forget. Compliance Frameworks allow you to "Force" specific logic onto every repository.

1. What is a Compliance Pipeline?

It is a "Master YAML" that runs instead of or before the project's own YAML.

• The Policy: "Every project in the 'Banking' group MUST run a SAST scan and a License scan before any other job."

---

2. Setting it up

1. The Policy File: Create a central repository with your company's "Standard" security jobs.
2. The Framework: Go to your Group Settings -> Compliance frameworks.
3. The Link: Link that framework to your "Standard" YAML file.
4. The Label: Apply the "Banking-Compliance" label to any project.

---

3. Why Use This? (The "Anti-Shadow" DevOps)

It prevents "Shadow DevOps"—individual teams disabling security checks because they are "Trying to move fast."

• Even if a developer deletes their .gitlab-ci.yml, the Compliance Pipeline will still run! This provides 100% certainty for auditors.

---

4. Separation of Concerns

• Developers: Handle the build, test, and deploy of their specific app.
• Security Teams: Handle the "Global" scans and policies from one central location.

---

Exercise: The Governor's Rule

1. Create a "Governance" project in GitLab.
2. Add a security-policy.yml that includes a simple echo "SCANNING FOR SECRETS..." job.
3. Research: How do you link this file to a Compliance Framework in the Group settings?
4. If a developer tries to "Overwrite" a global stage from the compliance pipeline, what happens?
5. Why is "Compliance as Code" better than a 200-page PDF of rules?

---

Summary

Compliance Pipelines transform your company from a collection of "Random Projects" into a "Regulated Machine." By enforcing rules at the Group level, you eliminate human error and ensure that every piece of software follows the same high standard of safety.

Next Lesson: Who has the keys? Auditing and User Access Management (IAM).