WAF-SEC-110 – Supply Chain Security

Pillar: Security | Severity: High | Category: Container Security | Automatable: High

Description

All container images deployed to production MUST use immutable tags to prevent post-push tampering. A Software Bill of Materials (SBOM) MUST be generated for all production container images and stored alongside the image in the registry. Third-party dependencies MUST be scanned for known CVEs before deployment using automated tooling in CI/CD pipelines. Container image signing MUST be implemented using Sigstore/Cosign or equivalent to verify image provenance and prevent deployment of unsigned or tampered images.

Rationale

Risk	Description
Risk	Mutable tags allow production images to be overwritten and complicate rollbacks after incidents.
Risk	Missing binary authorization lets compromised images deploy into production unnoticed.

Risk

Description

Risk

Mutable tags allow production images to be overwritten and complicate rollbacks after incidents.

Risk

Missing binary authorization lets compromised images deploy into production unnoticed.

Requirements

All container images deployed to production MUST use immutable tags to prevent post-push tampering.
A Software Bill of Materials (SBOM) MUST be generated for all production container images and stored alongside the image in the registry.
Third-party dependencies MUST be scanned for known CVEs before deployment using automated tooling in CI/CD pipelines.
Container image signing MUST be implemented using Sigstore/Cosign or equivalent to verify image provenance and prevent deployment of unsigned or tampered images.

Implementation Guidance

Document the requirement in a version-controlled policy or standard.
Assign ownership and establish a review cadence (e.g., quarterly).
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.

Level

Name

Criteria

Ad hoc – control not consistently applied

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

Standardised – policy defined and communicated

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

Integrated – automated validation in CI/CD

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

Auditable – metrics and exceptions tracked

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

Optimised – continuous improvement based on data

* Control effectiveness is measured and iteratively improved.

Checks

waf-sec-110.tf.aws.ecr-immutable-tags

Engine: terraform | Provider: aws | Automated: Yes

ECR repositories must enforce immutable image tags

All aws_ecr_repository resources must have image_tag_mutability set to 'IMMUTABLE'. Mutable tags allow a tag to be overwritten with a different image after a security scan has passed, creating a window for supply chain injection that bypasses pre-deployment controls.

Scope: resource — aws_ecr_repository

Assertions: * image_tag_mutability equals IMMUTABLE — ECR repository must use IMMUTABLE tag mutability to prevent post-push tag updates.

Remediation: Set image_tag_mutability = "IMMUTABLE" on all aws_ecr_repository resources. Update CI/CD pipelines to tag images with unique identifiers such as the Git commit SHA or a semantic version (e.g., v1.2.3-sha-abc1234) rather than mutable tags like 'latest'. Existing pipelines using 'latest' must be updated to use versioned tags before enabling immutability.

Compliant

resource "aws_ecr_repository" "app" {
  name                 = "my-application"
  image_tag_mutability = "IMMUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }

  encryption_configuration {
    encryption_type = "KMS"
    kms_key         = aws_kms_key.ecr.arn
  }

  tags = {
    environment = "production"
    owner       = "platform-team"
  }
}

Non-Compliant

resource "aws_ecr_repository" "app" {
  name                 = "my-application"
  image_tag_mutability = "MUTABLE"  # WAF-SEC-110 violation: allows tag overwrite
  # No image_scanning_configuration    # WAF-SEC-110 violation: scan-on-push required
}

waf-sec-110.config.azurerm.azurerm-container-security

Engine: config | Provider: azurerm | Automated: Yes

Azure Container Registry must enforce immutable tags and SBOM generation

A version-controlled policy document must exist at docs/security/waf-sec-110-azurerm-container-security.md and document the Azure implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/security/waf-sec-110-azurerm-container-security.md

Remediation: Create or update docs/security/waf-sec-110-azurerm-container-security.md. State the requirement, how it is implemented for Azure, the review cadence, and the owner.

Compliant

docs/security/waf-sec-110-azurerm-container-security.md:
- The Azure implementation of WAF-SEC-110 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-110-azurerm-container-security.md` is missing or does not contain a normative requirement.
# WAF-SEC-110 violation: Azure control is not documented

waf-sec-110.tf.google.binary-authorization

Engine: terraform | Provider: google | Automated: Yes

GCP Binary Authorization must require attestation for production deployments

A google_binary_authorization_policy resource must define a default_admission_rule with evaluation_mode "REQUIRE_ATTESTATION" so that only signed, trusted container images can be deployed to production GKE clusters.

Scope: resource — google_binary_authorization_policy

Assertions: * default_admission_rule attribute exists — Binary Authorization policy must define a default_admission_rule.

Remediation: Create a google_binary_authorization_policy with default_admission_rule evaluation_mode = "REQUIRE_ATTESTATION" and an attestation authority (google_binary_authorization_attestor) used by the CI/CD pipeline to sign images. Configure GKE clusters to enable Binary Authorization.

Compliant

resource "google_binary_authorization_policy" "prod" {
  default_admission_rule {
    evaluation_mode  = "REQUIRE_ATTESTATION"
    enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
    require_attestations_by = [
      google_binary_authorization_attestor.ci.id,
    ]
  }
}

resource "google_binary_authorization_attestor" "ci" {
  name = "ci-pipeline-attestor"
  attestation_authority_note {
    note_reference = google_container_analysis_note.ci.name
    public_keys {
      ascii_armored_pgp_public_key = file("ci-pipeline.pub")
    }
  }
}

Non-Compliant

resource "google_binary_authorization_policy" "prod" {
  default_admission_rule {
    evaluation_mode  = "ALWAYS_ALLOW"  # WAF-SEC-110 violation: any image can deploy
    enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
  }
}

waf-sec-110.tf.aws.ecr-scan-enabled

Engine: terraform | Provider: aws | Automated: Yes

ECR repositories must have image scanning enabled on push

All aws_ecr_repository resources must include an image_scanning_configuration block with scan_on_push = true to ensure every image pushed to the registry is automatically scanned for known CVEs before it can be deployed to production workloads.

Scope: resource — aws_ecr_repository

Assertions: * image_scanning_configuration attribute exists — ECR repository must have image_scanning_configuration defined with scan_on_push enabled.

Remediation: Add an image_scanning_configuration block with scan_on_push = true to all aws_ecr_repository resources. For enhanced scanning including programming language libraries (not just OS packages), enable Amazon Inspector integration at the account level and configure ECR enhanced scanning via the AWS Inspector console or API. Integrate ECR scan result checks into CI/CD deployment gates.

Compliant

resource "aws_ecr_repository" "app" {
  name                 = "my-application"
  image_tag_mutability = "IMMUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }
}

Non-Compliant

resource "aws_ecr_repository" "app" {
  name                 = "my-application"
  image_tag_mutability = "IMMUTABLE"
  # Missing image_scanning_configuration – WAF-SEC-110 violation
  # Images pushed to this repository are not scanned for CVEs
}

waf-sec-110.config.stackit.stackit-container-security

Engine: config | Provider: stackit | Automated: Yes

STACKIT Container Registry must use immutable image tags and SBOMs

A version-controlled policy document must exist at docs/security/waf-sec-110-stackit-container-security.md and document the STACKIT implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/security/waf-sec-110-stackit-container-security.md

Remediation: Create or update docs/security/waf-sec-110-stackit-container-security.md. State the requirement, how it is implemented for STACKIT, the review cadence, and the owner.

Compliant

docs/security/waf-sec-110-stackit-container-security.md:
- The STACKIT implementation of WAF-SEC-110 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-110-stackit-container-security.md` is missing or does not contain a normative requirement.
# WAF-SEC-110 violation: STACKIT control is not documented

waf-sec-110.config.ovh.ovh-container-security

Engine: config | Provider: ovh | Automated: Yes

OVHcloud container workloads must use immutable image tags and SBOMs

A version-controlled policy document must exist at docs/security/waf-sec-110-ovh-container-security.md and document the OVHcloud implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/security/waf-sec-110-ovh-container-security.md

Remediation: Create or update docs/security/waf-sec-110-ovh-container-security.md. State the requirement, how it is implemented for OVHcloud, the review cadence, and the owner.

Compliant

docs/security/waf-sec-110-ovh-container-security.md:
- The OVHcloud implementation of WAF-SEC-110 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-110-ovh-container-security.md` is missing or does not contain a normative requirement.
# WAF-SEC-110 violation: OVHcloud control is not documented

waf-sec-110.config.hcloud.hcloud-container-security

Engine: config | Provider: hcloud | Automated: Yes

Hetzner Cloud container workloads must use immutable image tags and SBOMs

A version-controlled policy document must exist at docs/security/waf-sec-110-hcloud-container-security.md and document the Hetzner Cloud implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/security/waf-sec-110-hcloud-container-security.md

Remediation: Create or update docs/security/waf-sec-110-hcloud-container-security.md. State the requirement, how it is implemented for Hetzner Cloud, the review cadence, and the owner.

Compliant

docs/security/waf-sec-110-hcloud-container-security.md:
- The Hetzner Cloud implementation of WAF-SEC-110 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-110-hcloud-container-security.md` is missing or does not contain a normative requirement.
# WAF-SEC-110 violation: Hetzner Cloud control is not documented

Evidence

Kind Required Description

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.

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 27001:2022	* A.5.19 – Information security in supplier relationships * A.5.20 – Addressing information security within supplier agreements * A.5.21 – Managing information security in the ICT supply chain * A.8.30 – Outsourced development
ISO 27017	* CLD.6.3 – Shared roles and responsibilities
CIS Controls v8	* CIS 2 – Inventory and Control of Software Assets * CIS 16 – Application Software Security
CSA STAR	* CCM STA-01 – Supply Chain Agreements * CCM STA-02 – Supply Chain Risk Management * CCM STA-09 – Provider Internal Assessments
PCI DSS v4.0	* Req 6.3 – Software development processes * Req 12.8 – Service provider management
SOC 2 Type II	* CC9.2 – Vendor and business partner management
GDPR	* Art. 28 – Processor obligations * Art. 32 – Security of processing
NIS2	* Art. 21(2)(d) – Supply chain security
DORA	* Art. 28 – ICT third-party risk management * Art. 30 – Contractual arrangements
EUCS (ENISA)	* SUP-01 – Supplier and supply chain management
BSI C5:2020	* DEV-04 – Secure development – supply chain * PSS-01 – Outsourcing and supply chain
IT-Grundschutz	* OPS.2.3 – Auslagerung und Lieferantensteuerung * CON.8 – Software-Entwicklung
TISAX	* Information security – Supplier relationships and supply chain
ANSSI SecNumCloud	* Domain – Supply chain security
BIO	* BIO – Toeleveringsketenbeveiliging
ENS High	* op.ext.4 – Cadena de suministro
UK NCSC CAF	* A4.b – Supplier security
NIST SP 800-53	* SR-3 – Supply Chain Controls and Processes * SR-4 – Provenance * SR-11 – Component Authenticity
NIST CSF 2.0	* GV.SC – Cybersecurity Supply Chain Risk Management
FedRAMP	* SR-3, SR-4, SR-11 (High baseline supply chain controls)
CMMC 2.0	* SA.L2-3.4.6 – Employ principle of least functionality * SI.L2-3.14.2 – Provide protection from malicious code
IRAP	* ISM – Software supply chain
CCCS PBMM	* SR-3, SR-4 – Supply chain risk controls
MAS TRM	* Ch.12 – Outsourcing risk management * Ch.7 – System development life cycle
ISMAP	* Supply chain assurance and provenance
FISC	* Operational measures – Supply chain and outsourcing

Framework

Controls

ISO 27001:2022

* A.5.19 – Information security in supplier relationships * A.5.20 – Addressing information security within supplier agreements * A.5.21 – Managing information security in the ICT supply chain * A.8.30 – Outsourced development

ISO 27017

* CLD.6.3 – Shared roles and responsibilities

CIS Controls v8

* CIS 2 – Inventory and Control of Software Assets * CIS 16 – Application Software Security

CSA STAR

* CCM STA-01 – Supply Chain Agreements * CCM STA-02 – Supply Chain Risk Management * CCM STA-09 – Provider Internal Assessments

PCI DSS v4.0

* Req 6.3 – Software development processes * Req 12.8 – Service provider management

SOC 2 Type II

* CC9.2 – Vendor and business partner management

GDPR

* Art. 28 – Processor obligations * Art. 32 – Security of processing

NIS2

* Art. 21(2)(d) – Supply chain security

DORA

* Art. 28 – ICT third-party risk management * Art. 30 – Contractual arrangements

EUCS (ENISA)

* SUP-01 – Supplier and supply chain management

BSI C5:2020

* DEV-04 – Secure development – supply chain * PSS-01 – Outsourcing and supply chain

IT-Grundschutz

* OPS.2.3 – Auslagerung und Lieferantensteuerung * CON.8 – Software-Entwicklung

TISAX

* Information security – Supplier relationships and supply chain

ANSSI SecNumCloud

* Domain – Supply chain security

BIO

* BIO – Toeleveringsketenbeveiliging

ENS High

* op.ext.4 – Cadena de suministro

UK NCSC CAF

* A4.b – Supplier security

NIST SP 800-53

* SR-3 – Supply Chain Controls and Processes * SR-4 – Provenance * SR-11 – Component Authenticity

NIST CSF 2.0

* GV.SC – Cybersecurity Supply Chain Risk Management

FedRAMP

* SR-3, SR-4, SR-11 (High baseline supply chain controls)

CMMC 2.0

* SA.L2-3.4.6 – Employ principle of least functionality * SI.L2-3.14.2 – Provide protection from malicious code

IRAP

* ISM – Software supply chain

CCCS PBMM

* SR-3, SR-4 – Supply chain risk controls

MAS TRM

* Ch.12 – Outsourcing risk management * Ch.7 – System development life cycle

ISMAP

* Supply chain assurance and provenance

FISC

* Operational measures – Supply chain and outsourcing