Wombat

WAF-OPS-050 – Change Management & Deployment Risk Assessment

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

Description

All changes to production systems MUST go through a defined change management process that includes risk assessment, approval workflow for high-risk changes, deployment freeze policies for critical periods, and post-deployment verification. Change records MUST be linked to deployment artifacts and stored with sufficient context for audit.

Rationale

Risk Description

Risk

Undocumented changes to production systems complicate rollbacks and audits.

Risk

Missing approval gates enable unauthorized or untested deployments.

Requirements

  • All changes to production systems MUST go through a defined change management process that includes risk assessment, approval workflow for high-risk changes, deployment freeze policies for critical periods, and post-deployment verification.

  • Change records MUST be linked to deployment artifacts and stored with sufficient context for audit.

Implementation Guidance

  1. Document the requirement in a version-controlled policy or standard.

  2. Assign ownership and establish a review cadence (e.g., quarterly).

  3. Implement the required configuration as code in Terraform or equivalent IaC.

Maturity Levels

Level Name Criteria

L1

Ad hoc – control not consistently applied

* Manual evidence exists for some workloads, but coverage is unknown.

L2

Standardised – policy defined and communicated

* A version-controlled policy, ADR, or standard describes the requirement.

L3

Integrated – automated validation in CI/CD

* Terraform checks run automatically on pull requests and report results.

L4

Auditable – metrics and exceptions tracked

* Control coverage, failures, and approved exceptions are reported quarterly.

L5

Optimised – continuous improvement based on data

* Control effectiveness is measured and iteratively improved.

Checks

waf-ops-050.tf.aws.codepipeline-manual-approval

Engine: terraform | Provider: aws | Automated: Yes

Production CodePipeline must include a manual approval stage before deployment

AWS CodePipeline pipelines deploying to production MUST include a manual approval action before the production deploy stage to enforce change review.

Scope: resource — aws_codepipeline

Assertions: * stage attribute exists — Pipeline must define at least one stage with approval action.

Remediation: Add a stage with an Approval action before the production Deploy stage in your CodePipeline. Set the approval SNS topic and add a message referencing the change ticket.

Compliant
resource "aws_codepipeline" "app_pipeline" {
  name     = "payment-service-pipeline"
  role_arn = aws_iam_role.codepipeline_role.arn

  artifact_store {
    location = aws_s3_bucket.artifacts.bucket
    type     = "S3"
  }

  stage { name = "Source" /* ... */ }
  stage { name = "Build"  /* ... */ }
  stage { name = "Deploy-Staging" /* ... */ }

  stage {
    name = "Approval-Production"
    action {
      name     = "ManualApproval"
      category = "Approval"
      owner    = "AWS"
      provider = "Manual"
      version  = "1"
      configuration = {
        NotificationArn = aws_sns_topic.approvals.arn
        CustomData      = "Review checklist: https://wiki/deploy-checklist"
      }
    }
  }

  stage { name = "Deploy-Production" /* ... */ }
}
Non-Compliant
resource "aws_codepipeline" "app_pipeline" {
  # Pipeline goes directly from staging to production
  # with no approval gate – WAF-OPS-050 Violation
  stage { name = "Source" }
  stage { name = "Build" }
  stage { name = "Deploy-Production" }
}

waf-ops-050.tf.azurerm.devops-environment-approval

Engine: terraform | Provider: azurerm | Automated: Yes

Azure DevOps production environment must require approval checks

Azure DevOps environments used for production deployments MUST have approval checks configured to enforce the change review process.

Scope: resource — azuredevops_environment

Assertions: * name not empty — Azure DevOps environment must have a name.

Remediation: Configure approval checks on the azuredevops_environment used for production via azuredevops_check_approval or the Azure DevOps portal after environment creation.

Compliant
resource "azuredevops_environment" "production" {
  project_id  = azuredevops_project.main.id
  name        = "production"
  description = "Production environment – requires approval before deployment"
}

# Configure approval check via API or portal:
# Approvers: tech-lead group, minimum 1 approval required
Non-Compliant
resource "azuredevops_environment" "production" {
  project_id = azuredevops_project.main.id
  name       = "production"
  # No approval check configured – WAF-OPS-050 Violation
}

waf-ops-050.tf.google.cloud-build-approval

Engine: terraform | Provider: google | Automated: Yes

GCP Cloud Build production trigger must require manual approval

GCP Cloud Build triggers deploying to production MUST include a manual approval step or be gated by a release promotion workflow that enforces change review before production deployment.

Scope: resource — google_cloudbuild_trigger

Assertions: * approval_config attribute exists — GCP Cloud Build production trigger must require manual approval.

Remediation: Configure a Cloud Build approval configuration or use a release promotion pipeline where production deployments require at least one reviewer approval. Document the approval process in a version-controlled change-management policy.

Compliant
resource "google_cloudbuild_trigger" "prod_deploy" {
  name     = "deploy-to-production"
  project  = var.project_id
  filename = "cloudbuild-prod.yaml"

  approval_config {
    approval_required = true
  }

  substitutions = {
    _ENVIRONMENT = "production"
  }
}
Non-Compliant
resource "google_cloudbuild_trigger" "prod_deploy" {
  name     = "deploy-to-production"
  project  = var.project_id
  filename = "cloudbuild-prod.yaml"
  # No approval_config – production deployment proceeds automatically
}

waf-ops-050.tf.stackit.pipeline-defined

Engine: terraform | Provider: stackit | Automated: Yes

STACKIT infrastructure changes must go through a pipeline

STACKIT infrastructure changes must go through a pipeline. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — stackit_ske_cluster

Assertions: * labels.deployment-pipeline key exists — STACKIT SKE cluster is missing the 'deployment-pipeline' label.

Remediation: Review the Terraform configuration for the listed resource types and ensure the required attribute or tag is present. See the control narrative for provider-specific guidance.

Compliant
# Example resource meets the requirement.
resource "stackit_ske_cluster" "example" {
  # required attribute/tag/label present
}
Non-Compliant
# Example resource does not meet the requirement.
resource "stackit_ske_cluster" "example" {
  # Missing required attribute/tag/label
}

waf-ops-050.tf.ovh.pipeline-defined

Engine: terraform | Provider: ovh | Automated: Yes

OVHcloud infrastructure changes must go through a pipeline

OVHcloud infrastructure changes must go through a pipeline. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — ovh_cloud_project_kube, ovh_cloud_project_kube_nodepool

Assertions: * tags.deployment-pipeline key exists — OVHcloud Kubernetes resource is missing the 'deployment-pipeline' tag.

Remediation: Review the Terraform configuration for the listed resource types and ensure the required attribute or tag is present. See the control narrative for provider-specific guidance.

Compliant
# Example resource meets the requirement.
resource "ovh_cloud_project_kube" "example" {
  # required attribute/tag/label present
}
Non-Compliant
# Example resource does not meet the requirement.
resource "ovh_cloud_project_kube" "example" {
  # Missing required attribute/tag/label
}

waf-ops-050.tf.hcloud.pipeline-defined

Engine: terraform | Provider: hcloud | Automated: Yes

Hetzner Cloud infrastructure changes must go through a pipeline

Hetzner Cloud infrastructure changes must go through a pipeline. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — hcloud_server

Assertions: * labels.deployment-pipeline key exists — Hetzner Cloud server is missing the 'deployment-pipeline' label.

Remediation: Review the Terraform configuration for the listed resource types and ensure the required attribute or tag is present. See the control narrative for provider-specific guidance.

Compliant
# Example resource meets the requirement.
resource "hcloud_server" "example" {
  # required attribute/tag/label present
}
Non-Compliant
# Example resource does not meet the requirement.
resource "hcloud_server" "example" {
  # Missing required attribute/tag/label
}

Evidence

Kind Required Description

iac

Required

Terraform configuration implementing the control.

governance

Required

Policy, ADR, or standard documenting the requirement.

config

Optional

Cloud console or API output confirming runtime state.

Related Controls

Framework Controls

ISO/IEC 20000-1

* Change and deployment management * Release and deployment management

ITIL 4

* Change enablement * Release management

SOC 2 Type II

* CC8.1 – Change Management – Authorized Changes

PCI DSS v4.0

* Requirement 6.5: Changes to all system components are managed securely