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

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

Pillar: Operational Excellence | Severity: High | Category: Deployment Automation | Automatable: High

Description

Every production workload MUST have a defined, versioned CI/CD pipeline. Manual deployments to production are not permitted. Pipeline definitions MUST be stored as code in the same repository as the application.

Rationale

Manual deployments are the most common cause of configuration drift, deployment errors, and undocumented changes. Automated pipelines enforce consistency, reduce human error, and provide an audit trail for every change.

DORA Elite teams deploy multiple times daily with a Change Failure Rate below 5%. Manual processes cannot achieve this level of reliability.

Threat Context

Risk Description

Undocumented manual changes

Manual deployments leave no audit trail; debugging after an incident is harder.

Inconsistent environments

Manual deployment creates deviations between staging and production (snowflake problem).

Missing rollback capability

Without a pipeline, rollback is a new manual deployment process rather than an automated reversal.

Compliance violation

Change management requirements (SOC 2, ISO 20000) require documented change control.

Requirements

  • Pipeline definitions MUST be stored in version control

  • All production deployments MUST be executed through the pipeline

  • Direct SSH access or console deployments in production MUST be prohibited

  • Branch protection MUST prevent direct commits to main or production branches

  • Approval gates MUST be configured before production deployments

  • Artifacts MUST be versioned (Git SHA or semantic version, not latest)

Implementation Guidance

  1. Define pipeline-as-code: .github/workflows/, .gitlab-ci.yml, buildspec.yml – in the repository, not externally

  2. Define stages: Lint → Test → Security Scan → Build → Deploy Staging → Approval → Deploy Production

  3. Configure branch protection: At least 1 reviewer, CODEOWNERS, direct commits prohibited

  4. Artifact versioning: Git SHA as container image tag; latest prohibited in production

  5. Activate approval gate: GitHub Environments, Azure DevOps Environment Checks, CodePipeline Manual Approval

  6. Deployment notifications: Pipeline failure alerts to team channel (Slack, Teams)

Maturity Levels

Level Name Criteria

1

Manual Deployments

No pipeline; deployments via SSH or console; no audit trail.

2

Basic Pipeline

CI pipeline exists for tests; deployments via script but triggered manually.

3

Full CI/CD with Gates

All deployments automated; branch protection; approval gate for production.

4

Metrics & Progressive Delivery

DORA metrics measured; canary/blue-green; auto-rollback on failure.

5

Continuous Deployment

Multiple times daily; Change Failure Rate < 5%; feature flags for low-risk releases.

Terraform Checks

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

Checks: AWS CodePipeline with source, build, and deploy stage is defined.

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" /* ... */ }
}
 
# No pipeline defined
# Deployments via SSH/Console
# WAF-OPS-010 Violation

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

Checks: Google Cloud Build Trigger with build configuration file is defined.

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

Remediation: Define an aws_codepipeline, azuredevops_build_definition, or google_cloudbuild_trigger resource with a repository reference and build configuration.

Evidence

Type Required Description

IaC

✅ Required

Pipeline definition files (.github/workflows/, .gitlab-ci.yml) in version control.

Config

✅ Required

Branch protection configuration (min. reviewer, CODEOWNERS, direct commits prohibited).

Process

Optional

DORA metrics report (Deployment Frequency, Lead Time for Changes).

Governance

Optional

Change management policy that explicitly prohibits manual production deployments.

Related Controls

Regulatorisches Mapping

Framework Controls

ISO/IEC 20000-1:2018

8.2.3 – Change management; 8.3.4 – Release management; 10.2.2 – Financial management

ITIL 4

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

AWS Well-Architected Framework

Operational Excellence Pillar – Prepare; Operational Excellence Pillar – Deploy

DORA

DORA 2024 – Technical practices; DORA 2024 – Organizational culture

SOC 2 Type II

CC4.1 – Monitoring activities; CC7.1 – Infrastructure and software monitoring

Google SRE Book

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

PCI DSS v4.0

Req 6.4 – Secure development lifecycle; Req 6.5 – Secure coding practices

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

NIST SP 800-53

CM-1 – Configuration management policy; CM-2 – Configuration management

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

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

Best Practice