WAF-OPS-010 – CI/CD Pipeline Defined & Automated
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
mainor production branches -
Approval gates MUST be configured before production deployments
-
Artifacts MUST be versioned (Git SHA or semantic version, not
latest)
Implementation Guidance
-
Define pipeline-as-code:
.github/workflows/,.gitlab-ci.yml,buildspec.yml– in the repository, not externally -
Define stages: Lint → Test → Security Scan → Build → Deploy Staging → Approval → Deploy Production
-
Configure branch protection: At least 1 reviewer, CODEOWNERS, direct commits prohibited
-
Artifact versioning: Git SHA as container image tag;
latestprohibited in production -
Activate approval gate: GitHub Environments, Azure DevOps Environment Checks, CodePipeline Manual Approval
-
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 |
|---|---|
|
|
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. |