Wombat

WAF-PERF-060 – Load & Stress Testing in CI/CD Pipeline

Pillar: Efficiancy | Severity: Medium | Category: Network Security | Automatable: High

Description

All production services handling external or variable load MUST have load tests defined and executed at least as part of staging or pre-production validation gates. Load tests MUST define explicit acceptance criteria (P95/P99 latency thresholds, error rate limits, minimum throughput targets). Performance regression MUST be detected automatically by comparing load test results against the established baseline. Critical services MUST be stress-tested to identify capacity limits before production launches.

Rationale

Risk Description

Risk

Workloads without load balancing are disproportionately impacted by node failure or traffic spikes.

Risk

Missing load-balancer configurations create single points of failure.

Requirements

  • All production services handling external or variable load MUST have load tests defined and executed at least as part of staging or pre-production validation gates.

  • Load tests MUST define explicit acceptance criteria (P95/P99 latency thresholds, error rate limits, minimum throughput targets).

  • Performance regression MUST be detected automatically by comparing load test results against the established baseline.

  • Critical services MUST be stress-tested to identify capacity limits before production launches.

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-perf-060.tf.aws.codepipeline-performance-stage

Engine: terraform | Provider: aws | Automated: Yes

AWS CodePipeline should include a performance testing stage

AWS CodePipeline deployment pipelines for production services should include a performance testing stage (using CodeBuild running k6/Gatling/Locust) before promoting to production. This check verifies that a performance stage is referenced in pipeline configuration.

Scope: resource — aws_codepipeline

Assertions: * stage not empty — CodePipeline must have at least 3 stages (Source, Build, Deploy) with performance validation included.

Remediation: Add a performance testing stage to CodePipeline using CodeBuild to execute load tests. Configure the stage to block promotion to production when acceptance criteria are not met.

Compliant
resource "aws_codepipeline" "app" {
  name     = "pipeline-payment-api"
  role_arn = aws_iam_role.pipeline.arn
  artifact_store { location = aws_s3_bucket.artifacts.bucket; type = "S3" }
  stage { name = "Source"; action { ... } }
  stage { name = "Build";  action { ... } }
  stage {
    name = "PerformanceTest"
    action {
      name     = "LoadTest"
      category = "Build"
      owner    = "AWS"
      provider = "CodeBuild"
      configuration = {
        ProjectName = aws_codebuild_project.load_test.name
      }
    }
  }
  stage { name = "Deploy"; action { ... } }
}
Non-Compliant
resource "aws_codepipeline" "app" {
  name = "pipeline-payment-api"
  stage { name = "Source"; action { ... } }
  stage { name = "Build";  action { ... } }
  stage { name = "Deploy"; action { ... } }
  # No performance test stage – WAF-PERF-060 violation
}

waf-perf-060.tf.azurerm.devops-pipeline-perf-gate

Engine: terraform | Provider: azurerm | Automated: Yes

Azure DevOps pipelines should include performance validation gates

Azure deployment pipelines should configure release gates or pre-deployment conditions that execute performance tests before production deployment.

Scope: resource — azurerm_resource_group_policy_assignment

Assertions: * name not empty — Policy assignments must be named descriptively.

Remediation: Configure Azure DevOps pipeline YAML with a performance test job that runs k6 or Gatling and fails the pipeline if acceptance criteria are not met. Reference load test scripts stored in the repository.

Compliant
# azure-pipelines.yml (referenced by Terraform azuredevops_build_definition)
stages:
  - stage: PerformanceTest
    dependsOn: BuildAndPush
    jobs:
      - job: LoadTest
        steps:
          - script: |
              k6 run --vus 50 --duration 5m \
                --env BASE_URL=$(STAGING_URL) \
                tests/performance/payment-api.js
            displayName: "Run k6 Load Tests"
          - task: PublishTestResults@2
            inputs:
              testResultsFormat: JUnit
              testResultsFiles: 'k6-results.xml'
Non-Compliant
# azure-pipelines.yml without performance stage
stages:
  - stage: Build
  - stage: Deploy  # Direct deploy without performance gate – WAF-PERF-060 violation

waf-perf-060.tf.google.cloud-build-perf-step

Engine: terraform | Provider: google | Automated: Yes

GCP Cloud Build triggers should include performance test steps

GCP Cloud Build configurations for production deployments should include load test execution steps before deploying to production.

Scope: resource — google_cloudbuild_trigger

Assertions: * filename not empty — Cloud Build trigger must reference a cloudbuild.yaml file. * disabled is false — Cloud Build trigger must not be disabled.

Remediation: Enable Cloud Build trigger and ensure the referenced cloudbuild.yaml includes a performance test step using k6 or Locust before the deploy step.

Compliant
resource "google_cloudbuild_trigger" "deploy" {
  name     = "deploy-payment-api"
  filename = "cloudbuild.yaml"
  disabled = false
  github {
    owner = var.github_owner
    name  = var.github_repo
    push { branch = "^main$" }
  }
}
# cloudbuild.yaml includes:
# - id: 'performance-test'
#   name: 'grafana/k6'
#   args: ['run', 'tests/performance/payment-api.js']
Non-Compliant
resource "google_cloudbuild_trigger" "deploy" {
  name     = "deploy-payment-api"
  disabled = true  # Trigger disabled – WAF-PERF-060 violation
  filename = "cloudbuild.yaml"
}

waf-perf-060.tf.stackit.caching-enabled

Engine: terraform | Provider: stackit | Automated: Yes

All production services handling external or variable load for stackit

All production services handling external or variable load must be documented in IaC via a caching-enabled tag/label on stackit_project. This validates the control is tracked as code.

Scope: resource — stackit_project

Assertions: * labels key exists — stackit_project is missing the caching-enabled tag/label.

Remediation: Add a caching-enabled tag/label to the stackit_project resource to show the stackit implementation of WAF-PERF-060 is tracked in IaC.

Compliant
resource "stackit_project" "example" {
  labels = {
    caching-enabled = "true"
  }
}
Non-Compliant
resource "stackit_project" "example" {
  # Missing caching-enabled labels
}

waf-perf-060.tf.ovh.caching-enabled

Engine: terraform | Provider: ovh | Automated: Yes

All production services handling external or variable load for ovh

All production services handling external or variable load must be documented in IaC via a caching-enabled tag/label on ovh_cloud_project. This validates the control is tracked as code.

Scope: resource — ovh_cloud_project

Assertions: * tags key exists — ovh_cloud_project is missing the caching-enabled tag/label.

Remediation: Add a caching-enabled tag/label to the ovh_cloud_project resource to show the ovh implementation of WAF-PERF-060 is tracked in IaC.

Compliant
resource "ovh_cloud_project" "example" {
  tags = {
    caching-enabled = "true"
  }
}
Non-Compliant
resource "ovh_cloud_project" "example" {
  # Missing caching-enabled tags
}

waf-perf-060.tf.hcloud.caching-enabled

Engine: terraform | Provider: hcloud | Automated: Yes

All production services handling external or variable load for hcloud

All production services handling external or variable load must be documented in IaC via a caching-enabled tag/label on hcloud_server. This validates the control is tracked as code.

Scope: resource — hcloud_server

Assertions: * labels key exists — hcloud_server is missing the caching-enabled tag/label.

Remediation: Add a caching-enabled tag/label to the hcloud_server resource to show the hcloud implementation of WAF-PERF-060 is tracked in IaC.

Compliant
resource "hcloud_server" "example" {
  labels = {
    caching-enabled = "true"
  }
}
Non-Compliant
resource "hcloud_server" "example" {
  # Missing caching-enabled labels
}

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 25010

* Performance Efficiency – Time Behavior * Performance Efficiency – Capacity