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

WAF-SEC-110 – Supply Chain Security

Pillar: Security | Severity: High | Kategorie: Supply Chain | Automatisierbar: Mittel

Beschreibung

Alle Container-Images MÜSSEN vor dem Deployment in produktive Umgebungen gescannt worden sein. ECR-Repositories MÜSSEN image_tag_mutability = "IMMUTABLE" konfiguriert haben, um Tag-Override-Angriffe zu verhindern. Terraform-Provider MÜSSEN in required_providers mit exakten Versionen und .terraform.lock.hcl im Repository versioniert sein. Dependency-Scanning (Dependabot, Renovate oder äquivalent) MUSS für alle Repositories konfiguriert sein.

Rationale

Software-Lieferketten sind ein wachsender Angriffsvektor: Angreifende kompromittieren Dependencies, Basis-Images oder Build-Tools, um Schadcode in Produktionssysteme einzuschleusen – ohne direkten Angriff auf das Ziel. Immutable Image-Tags verhindern, dass ein deployed Image heimlich ersetzt wird. Gepinnte Provider-Versionen mit Lock-File stellen sicher, dass terraform init deterministisch ist und kein kompromittiertes Provider-Update unbemerkt eingezogen wird. SBOM ermöglicht die schnelle Bewertung des Impacts neuer CVEs auf alle produktiven Artefakte.

Bedrohungskontext

Risiko Beschreibung

Kompromittierte Dependencies

Eine schadhafte Version eines npm/pip/go-Moduls kann Backdoors oder Cryptominer einschleusen.

Typosquatting

Paketnamen mit ähnlichem Tippfehler (z. B. reqests statt requests) enthalten oft Malware.

Mutable Image-Tags

latest-Tags können überschrieben werden; deployed Images entsprechen nicht mehr dem, was im CI geprüft wurde.

Transitive Vulnerabilities

Kritische CVEs in transitiven Abhängigkeiten bleiben ohne SBOM und Dependency-Tracking unsichtbar.

Anforderung

  • ECR-Repositories MÜSSEN image_tag_mutability = "IMMUTABLE" konfiguriert haben.

  • ECR-Repositories MÜSSEN Image-Scanning aktiviert haben (image_scanning_configuration.scan_on_push = true).

  • Terraform-Provider MÜSSEN mit exakten Versionen in required_providers gepinnt sein; .terraform.lock.hcl MUSS ins Repository eingecheckt sein.

  • Dependency-Scanning MUSS für alle Repositories konfiguriert sein (Dependabot, Renovate oder äquivalent).

  • Kritische und High-CVEs mit verfügbarem Fix MÜSSEN innerhalb der definierten Patch-SLA behoben sein (Critical: 24h, High: 7d).

Implementierungsanleitung

  1. ECR Immutable Tags: image_tag_mutability = "IMMUTABLE" in allen aws_ecr_repository-Ressourcen setzen.

  2. ECR Image Scanning: image_scanning_configuration { scan_on_push = true } aktivieren oder Trivy/Grype im CI-Build verwenden.

  3. Provider-Versionen pinnen: In required_providers exakte Versionen verwenden (z. B. version = "5.31.0" statt >= 5.0).

  4. Lock-File committen: .terraform.lock.hcl nach terraform providers lock ins Repository einchecken; .gitignore darf es nicht ausschließen.

  5. Dependabot konfigurieren: .github/dependabot.yml mit package-ecosystem: terraform und package-ecosystem: docker einrichten.

  6. SBOM generieren: trivy image --format spdx-json oder syft im CI für alle Production-Images ausführen und als CI-Artifact speichern.

  7. CVE-Triage-Prozess: CVSS-basierte Patch-SLA definieren und in einem Tracking-System (Jira, GitHub Issues) dokumentieren.

Reifegrad-Abstufung

Level Bezeichnung Kriterien

1

Keine Lieferkettensicherheit

Mutable Tags; keine Image-Scans; Provider-Versionen nicht gepinnt; kein Dependency-Scanning.

2

Grundlegendes Scanning

CI-Image-Scan vorhanden; einige Actions/Provider gepinnt; kein SBOM; kein Dependabot.

3

Immutable Tags + gepinnte Versionen

ECR Immutable Tags; alle Provider gepinnt mit Lock-File; Dependabot konfiguriert; Critical-CVEs blockieren Deployment.

4

SBOM und automatisiertes Dependency-Update

SBOM für alle Production-Container; automatische Dependency-PRs via Dependabot; Image-Signing mit cosign.

5

SLSA Level 3+ Provenance

Vollständige Build-Provenance-Attestierungen; hermetic Builds; kontinuierliches CVE-Monitoring aller deployed Artefakte.

Terraform Checks

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

Prüft: ECR-Repositories müssen unveränderliche Image-Tags konfiguriert haben.

Compliant Non-Compliant 
resource "aws_ecr_repository" "app" {
  name                 = "myapp/backend"
  image_tag_mutability = "IMMUTABLE"
  image_scanning_configuration {
    scan_on_push = true
  }
}
 
resource "aws_ecr_repository" "app" {
  name = "myapp/backend"
  # image_tag_mutability = "MUTABLE" (default)
  # WAF-SEC-110 Violation: Tags können überschrieben werden
}

Remediation: image_tag_mutability = "IMMUTABLE" zu allen aws_ecr_repository-Ressourcen hinzufügen. Deployment-Prozesse müssen auf eindeutige Tags (z. B. Git-SHA) statt latest umgestellt werden.

Evidenz

Typ Pflicht Beschreibung

IaC

✅ Pflicht

Terraform-Konfiguration von ECR-Repositories mit image_tag_mutability = "IMMUTABLE" und scan_on_push = true.

Config

✅ Pflicht

.terraform.lock.hcl im Repository; Dependabot/Renovate-Konfigurationsdatei.

Config

Optional

SBOM-Artefakt (SPDX oder CycloneDX) für mindestens ein Produktions-Container-Image.

Process

Optional

Trivy/Grype-Scan-Report der letzten CI-Pipeline für ein Produktions-Image.

Regulatorisches Mapping

Framework Controls

ISO 27001:2022

A.5.15 – Threat intelligence; A.5.16 – Threat classification; A.5.24 – Information security incident management; A.5.25 – Assessment and decision on information security events; A.5.26 – Response to information security incidents; A.5.27 – Learning from information security incidents; A.5.28 – Collection of evidence; A.8.16 – Technology use identification and monitoring; A.8.21 – Telecommunications and network security

ISO 27017

CLD.5.1 – Information security in cloud services; CLD.5.2 – Access control in cloud services

ISO 27018

A.2 – Purpose legitimacy and PII protection; A.10 – Confidentiality and security of PII

GDPR

Art. 5(1)(c) – Data minimisation; Art. 5(1)(f) – Integrity and confidentiality; Art. 9 – Special categories of personal data; Art. 25 – Data protection by design and by default; Art. 32 – Security of processing

BSI C5:2020

IDM-01 – Identity and access management policy; IDM-02 – Role management; IDM-03 – User lifecycle management; COM-01 – Network and service security; COM-02 – Cloud monitoring

EUCS (ENISA)

IAM-01 – Identity and access management; IAM-02 – Access rights management; IAM-03 – Privileged access management

NIST SP 800-53

AC-1 – Policy and procedures; AC-2 – Account management; AC-3 – Access enforcement; AC-6 – Least privilege; IA-2 – Identification and authentication; SI-4 – Information system monitoring

FedRAMP

AC-1, AC-2, AC-3, AC-6, IA-2 (Moderate/High baseline)

HIPAA

§ 164.308(a)(4) – Access management; § 164.312(a) – Access control; § 164.312(d) – Information system activity review

PCI DSS v4.0

Req 7 – Restrict access to cardholder data; Req 8 – Identify and authenticate access; Req 8.3 – Non-service accounts

SOC 2 Type II

CC6.1 – Logical access security software; CC6.2 – Logical access security management; CC6.6 – Secure configuration

CSRD

ESRS E1 – Climate change; ESRS G1 – Governance

NIST CSF 2.0

GV.AC – Identity management and access control; DE.CM – Configuration management

CIS Controls v8

CIS 4 – Secure Configuration; CIS 4.4 – Access control; CIS 4.5 – Least privilege

TISAX

Information security – Access rights management

ANSSI SecNumCloud

Domain – Identity and access management; Domain – Security monitoring

BIO

BIO – Identificatie en authenticatie; BIO – Toegangsbeheer

ENS High

org.3 – Políticas de acceso; op.exp.5 – Monitorización de la configuración

UK NCSC CAF

B1 – Access control; B2 – Secure configuration

CMMC 2.0

AC.L2-3.1.1 – Access control policy; AC.L2-3.5.1 – Access enforcement

IRAP

ISM – Identity and access management; ISM – Access control

CCCS PBMM

AC-6 – Least privilege; AC-7 – Unsuccessful logon attempts

MAS TRM

Ch.4 – Identity and access management; Ch.8 – Security monitoring

ISMAP

Access control and identity management

FISC

Operational measures – Access control

Best Practice