feat(blog): create CI/CD compliance guidelines article

src/data/blog/en/cicd-compliance-guidelines/index.mdx

@@ -0,0 +1,260 @@
+---
+title: "CI/CD Compliance Guidelines: A Reference Framework for Secure Software Delivery"
+description: "Authoritative guidelines for CI/CD compliance based on industry standards, regulatory requirements, and real-world supply chain incidents. Define, verify, correct, and prove your pipeline posture."
+draft: false
+authors:
+  - plumber
+pubDate: 2026-02-16
+categories:
+  - "CI/CD"
+  - "Security"
+  - "Compliance"
+  - "DevOps"
+  - "Supply Chain Security"
+  - "ISO 27001"
+  - "NIS2"
+  - "DORA"
+  - "OWASP"
+heroImage: ./heroImage.png
+---
+
+# CI/CD Compliance Guidelines: A Reference Framework for Secure Software Delivery
+
+Organizations today run hundreds or thousands of CI/CD pipelines. These pipelines access code, secrets, and production environments. Yet there is no reliable way to guarantee their compliance at scale. This article explains what CI/CD compliance means, why it matters now, and how to approach it.
+
+## What Does CI/CD Compliance Mean?
+
+**CI/CD compliance** means that your pipelines (the automation that builds, tests, and deploys your software) meet defined security, quality, and governance requirements. In practice, it answers four questions:
+
+<Steps class="my-6">
+
+1. ### What requirements must we follow?
+   *(no hardcoded secrets, trusted images only, required security checks)*
+2. ### Are we actually following those requirements?
+   *(automated controls prevent bypassing required checks)*   
+3. ### Can we prove it?
+   *(evidence for auditors, regulators, or internal governance)*
+4. ### Is it sustainable over time?
+   *(continuous verification, not a one-time snapshot)*
+
+</Steps>
+
+CI/CD compliance is not paperwork. It’s not a one-time manual checklist either.
+It’s about ensuring that the systems delivering your software are secure, auditable, and aligned with your organization’s risk posture.
+
+When your CI/CD pipelines are compliant, you significantly reduce the risk of supply chain attacks, data leaks, misconfigurations, and regulatory penalties. 
+
+CI/CD Compliance becomes part of how software is delivered — not an afterthought.
+
+## Why CI/CD Pipelines Need to Be Compliant Now
+
+Three converging forces make CI/CD compliance urgent today.
+
+<Steps class="my-6">
+
+1. ### Pipelines are a prime attack target
+   Attackers have shifted focus to the software supply chain. Compromising one pipeline can expose code, credentials, and production access across many projects. Incidents like **TJ-Actions** (23,000 repos, March 2025), **Shai-Hulud** (tens of thousands of repos, late 2025), and **SolarWinds** ($12M average impact per victim) show that pipelines are no longer a niche concern.
+
+   The risk is not whether a supply chain attack will occur. It’s whether you will detect it, and how long it will take you to realize it.
+2. ### Regulators are asking
+   Regulators and auditors are no longer focusing only on the software you ship.
+   They are now examining the systems that build, test, and deploy it : **your software supply chain.**
+   Frameworks like ISO 27001, NIS2, DORA, and the Cyber Resilience Act (CRA) require organizations to secure their information systems. CI/CD pipelines are now part of that scope.
+
+   To protect your organization, regulators now expect clear answers to questions such as:
+
+   * How many CI/CD pipelines run every day?
+   * Are they all secure and compliant?
+   * Can you prove it?
+   * How do you detect drift or compromise?
+
+   CI/CD is no longer just an engineering topic. **It is a governance and risk issue.**
+
+3. ### The hidden cost of this blind spot
+   Manual audits don’t scale. On average, they take around 1 hour per pipeline per month.
+   For 100 pipelines, that represents roughly the workload of more than one full-time employee — easily over €100,000 per year in staffing costs alone, depending on the country.
+
+   And in many organizations, even when monitoring exists, it often lives in silos, built ad hoc by individual teams, outside centralized governance. In other words: shadow IT.
+
+   That’s only the visible cost.
+
+   Non-compliance can represent 2–2.5% of annual revenue, not counting delivery stoppages, reputational damage, regulatory fines, or incident response expenses.
+
+</Steps>
+
+<Aside variant="caution" title="Key takeaway">
+The question is no longer *if* a supply chain attack will happen. It is whether you will notice when it does.
+</Aside>
+
+## Why CI/CD Compliance Is a Blind Spot
+
+CI/CD pipelines automate integration, testing, packaging, and deployment.
+They are powerful automation systems with extensive privileges — often able to access source code, secrets, infrastructure, and production environments.
+
+But they are also code. And like any code, they can be compromised, misconfigured, or neglected.
+
+Three main reasons explain why pipelines often escape proper governance:
+
+<Steps class="my-6">
+
+1. ### Controls exist on paper, but are not continuously verified
+   Security requirements may be defined, but they are rarely monitored systematically.
+   Pipelines evolve, configurations drift, and compliance becomes assumed rather than demonstrated.
+2. ### Pipeline code is rarely audited against formal requirements
+   Dev and DevOps teams build and maintain pipelines, but security and compliance teams often lack visibility.
+   As a result, no one consistently checks whether pipeline logic actually meets defined standards.
+3. ### CI/CD is seen as a technical topic, not as a high-privilege attack surface or a security concern
+   Pipelines automate builds and deployments, but they also hold powerful access to source code, secrets, and production environments.
+   Many organizations still underestimate their security impact.
+
+</Steps>
+
+<Aside variant="caution" title="Key takeaway">
+
+A CI/CD pipeline is one of the most privileged systems in your organization:
+
+1. It continuously reads your application code  
+2. It has access to your most sensitive secrets  
+3. It has the authority to write to production — automatically and at scale
+
+</Aside>
+
+## A Four-Step Compliance Framework
+
+Ensuring CI/CD compliance typically follows four continuous steps:
+
+
+<Steps class="my-6">
+
+1. ### Define
+   requirements (security rules, quality, compliance and governance standards).
+   The [OWASP Top 10 CI/CD Security Risks](https://owasp.org/www-project-top-10-ci-cd-security-risks/) provide a useful reference to start.
+
+2. ### Verify
+   posture (analyze pipelines, detect violations, and identify configuration drift before it becomes risk)
+3. ### Remediate
+   issues (close gaps, and realign pipelines with defined requirements)
+4. ### Prove
+   compliance (audit-ready evidence, continuous monitoring to demonstrate compliance over time.)
+
+</Steps>
+
+
+
+
+## Control Categories and Guidelines
+
+<nav class="my-6 flex w-full flex-wrap gap-2" aria-label="Jump to control category">
+  <a href="#1-cicd-container-images" class="border-primary-300 dark:border-primary-600/60 bg-primary-50/50 dark:bg-primary-950/30 hover:border-primary-500 dark:hover:border-primary-500/80 hover:bg-primary-100/50 dark:hover:bg-primary-900/30 text-primary-700 dark:text-primary-300 inline-flex items-center rounded-lg border px-4 py-2.5 text-sm font-semibold transition">
+    Container Images
+  </a>
+  <a href="#2-cicd-variables-and-secrets" class="border-primary-300 dark:border-primary-600/60 bg-primary-50/50 dark:bg-primary-950/30 hover:border-primary-500 dark:hover:border-primary-500/80 hover:bg-primary-100/50 dark:hover:bg-primary-900/30 text-primary-700 dark:text-primary-300 inline-flex items-center rounded-lg border px-4 py-2.5 text-sm font-semibold transition">
+    Secrets & Variables
+  </a>
+  <a href="#3-pipeline-composition" class="border-primary-300 dark:border-primary-600/60 bg-primary-50/50 dark:bg-primary-950/30 hover:border-primary-500 dark:hover:border-primary-500/80 hover:bg-primary-100/50 dark:hover:bg-primary-900/30 text-primary-700 dark:text-primary-300 inline-flex items-center rounded-lg border px-4 py-2.5 text-sm font-semibold transition">
+    Pipeline Composition
+  </a>
+  <a href="#4-access-and-authorization" class="border-primary-300 dark:border-primary-600/60 bg-primary-50/50 dark:bg-primary-950/30 hover:border-primary-500 dark:hover:border-primary-500/80 hover:bg-primary-100/50 dark:hover:bg-primary-900/30 text-primary-700 dark:text-primary-300 inline-flex items-center rounded-lg border px-4 py-2.5 text-sm font-semibold transition">
+    Access & Authorization
+  </a>
+  <a href="#5-security-policy-and-visibility" class="border-primary-300 dark:border-primary-600/60 bg-primary-50/50 dark:bg-primary-950/30 hover:border-primary-500 dark:hover:border-primary-500/80 hover:bg-primary-100/50 dark:hover:bg-primary-900/30 text-primary-700 dark:text-primary-300 inline-flex items-center rounded-lg border px-4 py-2.5 text-sm font-semibold transition">
+    Policy & Visibility
+  </a>
+</nav>
+
+### 1. CI/CD Container Images
+
+Pipelines run in containers. Untrusted or poorly configured images introduce supply chain risk.
+
+| Guideline | Rationale |
+|-----------|-----------|
+| **Use only trusted image sources** | Untrusted registries can deliver malicious images that steal credentials, exfiltrate code, or alter artifacts. |
+| **Avoid mutable tags (e.g. `latest`)** | Floating tags can pull compromised or breaking images without notice. Pin to explicit versions. |
+| **Scan images for vulnerabilities** | Integrate scanning into the pipeline before deployment. |
+
+### 2. CI/CD Variables and Secrets
+
+Variables and secrets grant access to sensitive resources. Exposure or misuse leads to breaches.
+
+| Guideline | Rationale |
+|-----------|-----------|
+| **Never hardcode secrets in pipeline config** | Secrets in `.gitlab-ci.yml` or similar files are visible to anyone with repo access. Use CI/CD variables or external secret managers. |
+| **Protect sensitive variables** | Restrict variables to protected branches/tags so they are not exposed on forks or feature branches. |
+| **Mask sensitive values in logs** | Unmasked variables appear in pipeline logs and can be exfiltrated. |
+
+### 3. Pipeline Composition
+
+How pipelines are built (templates, components, hardcoded jobs) affects maintainability and compliance.
+
+| Guideline | Rationale |
+|-----------|-----------|
+| **Prefer templates and components over hardcoded jobs** | Hardcoded jobs are harder to audit, update, and standardize. They increase technical debt and compliance risk. |
+| **Require mandatory templates** | Security scans (SAST, secret detection, dependency checks) must be present and not overridable. |
+| **Pin template and include versions** | Avoid `main` or default branches. Use explicit versions to prevent pulling compromised or breaking changes. |
+| **Detect and limit overrides** | Overriding required templates can bypass security checks. Overrides should be explicit and justified. |
+| **Include all required validations** | Missing checks increase the risk of vulnerabilities, defects, or non-compliant code reaching production. |
+
+### 4. Access and Authorization
+
+Who can change code and pipelines directly impacts security and compliance.
+
+| Guideline | Rationale |
+|-----------|-----------|
+| **Protect critical branches** | Unprotected branches allow anyone to push or merge without review. |
+| **Disable force push on protected branches** | Force push can erase history and hide malicious changes. |
+| **Enforce code owner approval** | Merges without code owner review increase the risk of bugs and security issues. |
+| **Restrict merge and push access** | Limit who can merge or push to protected branches. |
+| **Enforce merge request approval rules** | Require a minimum number of approvals before merge. |
+| **Respect role quotas** | Too many Owners or Maintainers weakens governance and increases misconfiguration risk. |
+
+### 5. Security Policy and Visibility
+
+Compliance requires defined policies and continuous visibility.
+
+| Guideline | Rationale |
+|-----------|-----------|
+| **Define a security policy source** | Projects must reference the organization’s security policy to ensure consistent checks. |
+| **Maintain logging and visibility** | Without logs and monitoring, drift and compromise go undetected. |
+
+## Five Questions to Assess Your Posture
+
+Before investing in tooling or process changes, answer these questions:
+
+<Steps class="my-6">
+
+1. ### How many CI/CD pipelines do you have?
+   (50, 250, 500, 5000?)
+2. ### Is your organization subject to security or compliance requirements?
+   (ISO 27001, NIS2, CRA, DORA, internal rules?)
+3. ### What would be the impact of a cyberattack on one pipeline?
+   (Ransomware, data theft, production outage, regulatory penalties?)
+4. ### How do you verify today that all pipelines are compliant?
+   (Manual checks, spot audits, or continuous automation?)
+5. ### What effort does this represent?
+   (Time, budget, headcount?)
+
+</Steps>
+
+If the answers reveal gaps, the framework above provides a starting point for improvement.
+
+## Making Compliance Durable
+
+Compliance is not a one-time project. Pipelines change constantly. New projects are added, templates are updated, and configurations drift. To stay compliant:
+
+<Aside variant="tip" title="Four pillars of durable compliance">
+- **Automate checks** so violations are detected as soon as they appear.
+- **Run continuously** rather than relying on periodic snapshots.
+- **Produce audit-ready evidence** (reports, scores, change history) that answers “What was the compliance state on date X?”
+- **Reduce manual effort** so security and DevOps teams can focus on remediation instead of repetitive audits.
+</Aside>
+
+The goal is real, proven, and lasting CI/CD compliance: not a checkbox exercise, but an operational discipline.
+
+## References
+
+- [OWASP Top 10 CI/CD Security Risks](https://owasp.org/www-project-top-10-ci-cd-security-risks/)
+- [ANSSI – Panorama de la cybermenace 2024](https://www.ssi.gouv.fr/)
+- [ISO/IEC 27001:2022](https://www.iso.org/standard/27001)
+- [NIS2 Directive](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555)
+- [DORA – Digital Operational Resilience Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2554)
+- [CRA – Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act)