WAF++ WAF++
Back to WAF++ Homepage

WAF-OPS-010 – CI/CD Pipeline Defined & Automated

Pillar: Operational Excellence | Severity: High | Kategorie: Deployment-Automatisierung | Automatisierbar: Hoch

Beschreibung

Jeder Produktions-Workload MUSS eine definierte, versionierte CI/CD-Pipeline haben. Manuelle Deployments in Produktion sind nicht zulässig. Pipeline-Definitionen MÜSSEN als Code im selben Repository wie die Applikation gespeichert sein.

Rationale

Manuelle Deployments sind die häufigste Ursache von Configuration Drift, Deployment-Fehlern und undokumentierten Änderungen. Automatisierte Pipelines erzwingen Konsistenz, reduzieren menschliche Fehler und liefern einen Audit-Trail für jede Änderung.

DORA-Elite-Teams deployen mehrfach täglich mit einer Change Failure Rate unter 5%. Manuelle Prozesse können diese Zuverlässigkeit nicht erreichen.

Bedrohungskontext

Risiko Beschreibung

Undokumentierte manuelle Änderungen

Manuelle Deployments hinterlassen keinen Audit-Trail; Debugging nach Incident ist erschwert.

Inkonsistente Umgebungen

Manuelles Deployment erzeugt Abweichungen zwischen Staging und Production (Snowflake-Problem).

Fehlende Rollback-Fähigkeit

Ohne Pipeline ist Rollback ein neuer manueller Deployment-Prozess statt automatischer Umkehrung.

Compliance-Verletzung

Change-Management-Anforderungen (SOC 2, ISO 20000) fordern dokumentierte Änderungskontrolle.

Anforderung

  • Pipeline-Definitionen MÜSSEN in Version-Control gespeichert sein

  • Alle Deployments in Produktion MÜSSEN durch die Pipeline ausgeführt werden

  • Direkte SSH-Zugriffe oder Console-Deployments in Produktion MÜSSEN verboten sein

  • Branch-Protection MUSS direkte Commits auf main oder Produktions-Branches verhindern

  • Approval-Gates MÜSSEN vor Production-Deployments konfiguriert sein

  • Artefakte MÜSSEN versioniert sein (Git-SHA oder semantische Version, nicht latest)

Implementierungsanleitung

  1. Pipeline-as-Code definieren: .github/workflows/, .gitlab-ci.yml, buildspec.yml – im Repository, nicht extern

  2. Stages definieren: Lint → Test → Security Scan → Build → Deploy Staging → Approval → Deploy Production

  3. Branch-Protection konfigurieren: Mindestens 1 Reviewer, CODEOWNERS, direkte Commits verboten

  4. Artefakt-Versionierung: Git-SHA als Container-Image-Tag; latest in Production verboten

  5. Approval-Gate aktivieren: GitHub Environments, Azure DevOps Environment Checks, CodePipeline Manual Approval

  6. Deployment-Benachrichtigungen: Pipeline-Failure-Alerts an Team-Kanal (Slack, Teams)

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Manuelle Deployments

Keine Pipeline; Deployments via SSH oder Konsole; kein Audit-Trail.

2

Basis-Pipeline

CI-Pipeline für Tests vorhanden; Deployments per Skript aber manuell ausgelöst.

3

Vollständige CI/CD mit Gates

Alle Deployments automatisiert; Branch-Protection; Approval-Gate für Production.

4

Metriken & Progressive Delivery

DORA-Metriken gemessen; Canary/Blue-Green; Auto-Rollback bei Fehler.

5

Continuous Deployment

Mehrfach täglich; Change Failure Rate < 5%; Feature Flags für risikolose Releases.

Terraform Checks

waf-ops-010.tf.aws.codepipeline-exists

Prüft: AWS CodePipeline mit Source, Build und Deploy-Stage ist definiert.

Compliant Non-Compliant 
resource "aws_codepipeline" "app" {
  name     = "payment-pipeline"
  role_arn = aws_iam_role.cp_role.arn
  artifact_store {
    location = aws_s3_bucket.artifacts.bucket
    type     = "S3"
  }
  stage { name = "Source" /* ... */ }
  stage { name = "Build"  /* ... */ }
  stage { name = "Deploy" /* ... */ }
}
 
# Kein Pipeline definiert
# Deployments via SSH/Console
# WAF-OPS-010 Violation

waf-ops-010.tf.google.cloudbuild-trigger-exists

Prüft: Google Cloud Build Trigger mit Build-Konfigurationsdatei ist definiert.

# Compliant
resource "google_cloudbuild_trigger" "app" {
  name     = "payment-service-trigger"
  filename = "cloudbuild.yaml"
  github {
    owner = "myorg"
    name  = "payment-service"
    push { branch = "^main$" }
  }
}

Remediation: Eine aws_codepipeline, azuredevops_build_definition oder google_cloudbuild_trigger Ressource mit Repository-Referenz und Build-Konfiguration definieren.

Evidenz

Typ Pflicht Beschreibung

IaC

✅ Pflicht

Pipeline-Definitions-Dateien (.github/workflows/, .gitlab-ci.yml) in Version-Control.

Config

✅ Pflicht

Branch-Protection-Konfiguration (min. Reviewer, CODEOWNERS, direkte Commits verboten).

Process

Optional

DORA-Metriken-Report (Deployment Frequency, Lead Time for Changes).

Governance

Optional

Change-Management-Policy die manuelle Production-Deployments explizit verbietet.

Regulatorisches Mapping

Framework Controls

ISO/IEC 20000-1:2018

8.2.3 – Change management; 8.3.4 – Release management; 8.4.1 – Service delivery; 8.4.2 – Service reporting

ITIL 4

SVS – Service value system; DP – Design principle; OV – Operation value chain; CW – Continual improvement

AWS Well-Architected Framework

Operational Excellence Pillar – Prepare; Operational Excellence Pillar – Deploy; Operational Excellence Pillar – Monitor; Operational Excellence Pillar – Improve

DORA

DORA 2024 – Technical practices; DORA 2024 – Organizational culture

SOC 2 Type II

CC4.1 – Monitoring activities; CC7.1 – Infrastructure and software monitoring; CC7.2 – Evaluation of system changes

Google SRE Book

Chapter 2 – SRE: The role of an SRE; Chapter 3 – Service Level Objectives; Chapter 4 – Eliminating toil

PCI DSS v4.0

Req 6.4 – Secure development lifecycle; Req 6.5 – Secure coding practices; Req 6.6 – Application security

FinOps Foundation

Core Module – Financial accountability; Management Layer – Cost governance

BSI C5:2020

OPS-01 – Operational monitoring; OPS-02 – Operational control; OPS-03 – Operational capacity; OPS-04 – Change management

NIST SP 800-53

CM-1 – Configuration management policy; CM-2 – Configuration management; CM-6 – Configuration settings; CM-8 – Information system integration; CA-7 – Continuous monitoring

NIST CSF 2.0

GV.PO – Policy; RC.RP – Recovery planning; DE.CM – Continuous monitoring

TISAX

Information security – Change management

ANSSI SecNumCloud

Domain – Change management

BIO

BIO – Veranderingenbeheer

ENS High

op.exp.6 – Gestión de cambios

UK NCSC CAF

A4 – Policy and assurance; A5 – Continual improvement

CMMC 2.0

CM.L2-3.4.1 – Establish baseline configurations; CA.L2-3.12.1 – Periodically assess security controls

IRAP

ISM – Change management

CCCS PBMM

CM-2 – Baseline configuration; CA-7 – Continuous monitoring

MAS TRM

Ch.3 – Technology risk governance; Ch.9 – Change management

ISMAP

Operational excellence and continuous improvement

FISC

Operational measures – Change management

Verwandte Controls

Best Practice