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

WAF-SOV-080 – Dependency & Subprocessor Inventory

Pillar: Sovereign | Severity: 🟡 Medium | Category: Supply Chain | Automatable: Medium

Description

An inventory of all dependencies and subprocessors MUST be maintained: managed cloud services, third-party SaaS tools, CI/CD platforms, observability providers, and data processors. Changes to this inventory MUST be versioned, reviewed, and approved.

Provider version constraints in Terraform MUST be pinned to prevent silent upgrades. Module sources MUST reference approved registries with version-locked references.

Rationale

Cloud sovereignty cannot be assessed without knowing which third parties process data, from which jurisdiction, and on what legal basis. A Datadog agent sending logs to US servers, a GitHub Actions runner with production access, or an unreviewed Terraform module from an untrusted source can each independently compromise the sovereignty posture. Supply chain awareness is the prerequisite for supply chain control.

Threat Context

Risk Description

SaaS tool outside approved jurisdiction

Monitoring, ticketing, or CI/CD tool processes sovereign data outside the approved region.

Unpinned Terraform provider

Unpinned provider version is silently updated to a version with breaking changes or changed behavior.

Unreviewed Terraform module

Terraform module from an unknown author with malicious resource configurations.

Subprocessor without DPA

New subprocessor added without a GDPR Art. 28-compliant DPA.

CI/CD as unrecognized subprocessor

CI/CD platform (GitHub, GitLab, CircleCI) with production access not listed as a subprocessor.

Regulatory Mapping

Framework Controls

GDPR

Art. 28 – Data processors; Art. 30 – Records of processing activities; Art. 44–46 – Transfers to third countries

BSI C5:2020

SCA-01 – Supply chain management; OPS-04 – Data management

EUCS (ENISA)

SCA-01 – Supply chain; IAM-04 – Third-party access

ISO 27001:2022

A.5.19 – Information security in supplier relationships; A.5.20 – Information security in supplier agreements; A.5.21 – Information security in the ICT supply chain

SLSA

L2 – Build integrity; L3 – Source integrity

BSI C3A:2026

Dimension 6 – Supply Chain: Software inventory (SBoM); Dimension 6 – Supply Chain: Hardware inventory; Dimension 6 – Supply Chain: External service dependencies

Requirement

  • All required_providers in Terraform MUST include a version constraint

  • required_version MUST be set in the Terraform block

  • Terraform module versions MUST be pinned (Registry: version = "x.y.z"; Git: ?ref=vX.Y.Z)

  • Module sources MUST NOT reference unapproved public Git repositories

  • The dependency register MUST be machine-readable (YAML/JSON) and versioned in the repository

  • A DPA reference MUST exist in the register for all subprocessors handling personal data

  • The register MUST be reviewed at least quarterly

  • terraform.lock.hcl MUST be committed to the repository

Implementation Guidance

  1. Create dependency register: YAML/JSON in Git; all external services with name, purpose, processed data, hosting region, and legal basis.

  2. Pin provider versions: All entries in required_providers with ~> constraint (e.g. ~> 5.40 for AWS Provider v5.x).

  3. Pin module versions: Registry modules with version = "x.y.z"; Git modules with ?ref=v1.2.3.

  4. DPA for data processors: DPA agreement for every subprocessor with personal data; reference in the register.

  5. Quarterly review: Review subprocessor list quarterly; record changes in changelog.

  6. Commit lock file: terraform.lock.hcl in repository; CI blocks if lock file is missing.

  7. CI/CD as subprocessor: List the CI/CD platform itself as a subprocessor when secrets or data flow through it.

Maturity Levels

Level Name Criteria

1

No formal inventory, provider versions unpinned

Some knowledge of main dependencies; no structured documentation.

2

Dependency inventory documented, providers pinned

Dependency register exists (even as a table); Terraform provider versions pinned in required_providers; lock file committed to repository.

3

Versioned inventory with DPA references

Machine-readable dependency register in Git; every subprocessor has a DPA reference and data class annotation; quarterly review process with documented evidence.

4

Automated supply chain monitoring

Automatic alerts on new/changed providers or modules in PRs; SBOM generated for infrastructure deployments; subprocessor changes trigger review workflow.

5

Full supply chain attestation

SLSA compliance for critical supply chain components; automated DPA status verification integrated into deployment gate; cryptographic attestation for module provenance.

Terraform Checks

waf-sov-080.tf.any.required-providers-version-pinned

Checks: All required_providers must include version constraints.

Compliant Non-Compliant 
terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.40"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.100"
    }
    stackit = {
      source  = "SchwarzIT/stackit"
      version = "~> 2.0"
    }
    ovh = {
      source  = "ovh/ovh"
      version = "~> 1.0"
    }
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.0"
    }
  }
}
 
terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      # ❌ No version constraint –
      #    any version accepted
    }
  }
}

waf-sov-080.tf.any.required-terraform-version

Checks: required_version must be set in the terraform block.

Compliant Non-Compliant 
terraform {
  required_version = ">= 1.6.0, < 2.0.0"
}
 
terraform {
  # ❌ No required_version –
  #    any Terraform version accepted
}

waf-sov-080.tf.any.module-source-version-pinned

Checks: Terraform modules must reference a pinned version (no ref=main/ref=master).

Compliant Non-Compliant 
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.3"  # ✅ Pinned version
}

module "internal" {
  source = "git::https://git.example.com/modules/vpc.git?ref=v2.1.0"
  # ✅ Git tag instead of branch reference
}
 
module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  # ❌ No version – latest version
}

module "internal" {
  source = "git::https://git.example.com/modules/vpc.git?ref=main"
  # ❌ Mutable branch reference
}

waf-sov-080.tf.any.no-untrusted-registry-modules

Checks: Module sources must reference approved registries or internal Git.

# Non-Compliant: Unauthorized public GitHub repository
module "custom" {
  source = "github.com/unknown-user/terraform-aws-module.git"
  # ⚠️ Unapproved public repository without registry validation
}

# Compliant: Official Terraform Registry
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.3"
}

Evidence

Type Required Description

Governance

✅ Required

Dependency/subprocessor register (versioned; covering all external services with data flows).

IaC

✅ Required

Terraform required_providers with pinned version constraints and committed lock file.

Process

Optional

Quarterly review records of the subprocessor inventory.

Governance

Optional

DPA agreement reference list for all data-processing subprocessors.

Related Controls

Regulatorisches Mapping

Framework Controls

DSGVO

Art. 44 – Allg. Grundsätze für Übermittlungen; Art. 46 – Geeignete Garantien; Art. 28 – Verarbeitungsvereinbarung

BSI C5:2020

OPS-04 – Datenverwaltung; OPS-05 – Datenleakage-Prävention; SIM-01 – Sicherheitsvorfallmanagement

EUCS (ENISA)

DSP-01 – Datenklassifikation; DSP-02 – Dateninventar und Datenfluss; DSP-03 – Datenverfügbarkeit; DSP-04 – Datenlöschung; IAM-01 – Identität und Zugriff

ISO 27001:2022

A.5.12 – Klassifizierung von Informationen; A.5.13 – Kennzeichnung von Informationen; A.5.33 – Schutz von Aufzeichnungen

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

BSI C3A:2026

Domain – Datenhoheit; Domain – Cloud-Spezifische Anforderungen

GAIA-X

Sovereign Cloud – Anforderungen an Datenlokation und Transparenz

NIST SP 800-53

SC-1 – Cloud computing security; SC-7 – Boundary protection; SC-8 – Transmission confidentiality

NIST CSF 2.0

GV.PO – Policy; GV.RM – Risk management; GV.SC – Cybersecurity supply chain risk management

FedRAMP

SC-1, SC-7, SC-8 (High baseline)

TISAX

Information security – Data protection; Prototype protection – Sensitive data handling

ANSSI SecNumCloud

Domain – Data protection; Domain – Cloud security

BIO

BIO – Gegevensbescherming; BIO – Cloudbeveiliging

ENS High

ds.info.1 – Datos personales; ds.info.2 – Calificación de la información

UK NCSC CAF

B3 – Understanding data; B4 – System security

CMMC 2.0

SC.L2-3.13.16 – Protect CUI confidentiality at rest

IRAP

ISM – Data protection; ISM – Cloud security

CCCS PBMM

SC-7 – Boundary protection; SC-8 – Transmission confidentiality

MAS TRM

Ch.5 – Technology risk governance; Ch.8 – Cloud computing controls

ISMAP

Data sovereignty and cloud security

FISC

Technical measures – Data protection

Best Practice