Infrastructure as Code Requirements Catalogue
Scope: the IaC project as a software product
This catalogue defines security requirements that apply to the IaC project itself - treating infrastructure code as a software product with its own risks, which must be governed, validated and audited with the same rigour as any application.
The requirements cover: remote state management, segregation of environments, automated validations in the pipeline, traceability of modules and their provenance, versioning of artefacts, secure management of secrets, drift detection and periodic review of templates.
For the complete mapping of all SbD-ToE requirements catalogues by technical domain, canonical prefix and owner, see Ch. 02 - Catalogue Mapping.
Note: These requirements govern how infrastructure is defined and managed as code - not the security properties of the provisioned infrastructure itself (network configurations, IAM permissions, bucket encryption, etc.), which result from what the IaC code defines and are subject to each organisation's policies.
On curation: Consolidated from NIST SSDF, SLSA (Supply Chain Levels for Software Artefacts), the CIS Benchmarks for IaC, OWASP SAMM and established practices for Terraform, Pulumi and cloud platforms. It must be adapted to the context and to the IaC tools used by the organisation.
For project instantiation and the operational nomenclature (SEC-Lx-IAC-CODIGO), see Taxonomy and Traceability.
Conventions
| Symbol | Meaning |
|---|---|
| ✔ | Mandatory requirement at this level |
| - | Not applicable or not mandatory at this level |
The levels are cumulative: L3 includes all L1 and L2 requirements; L2 includes all L1 requirements.
IAC Catalogue - Infrastructure as Code
Requirements that guarantee that the IaC project is developed, versioned, validated and operated with security controls proportional to the risk of the infrastructure it manages.
| ID | Name | L1 | L2 | L3 | Acceptance criterion |
|---|---|---|---|---|---|
| IAC-001 | Authenticated remote backend with active locking | - | ✔ | ✔ | backend configured with authentication and locking; an attempted concurrent apply results in blocking; lock logs available. |
| IAC-002 | Segregated and versioned environments | ✔ | ✔ | ✔ | Distinct dev, staging and prod configurations, versioned in separate directories or workspaces; a deploy cannot cross environments without explicit approval. |
| IAC-003 | Mandatory automated validations in the pipeline | ✔ | ✔ | ✔ | Pipeline with lint, security analysis (e.g. tfsec, checkov) and policy validation stages; failure at any stage blocks the apply. |
| IAC-004 | Reused modules with a trusted origin and an immutable version | - | ✔ | ✔ | Module references with a pinned semantic version or hash; no unversioned references (latest, master, HEAD); origin documented. |
| IAC-005 | Complete history with versioning, tags and releases | ✔ | ✔ | ✔ | Git repository with intact history, semantic tags per release and release notes; no mandatory squash on main branches. |
| IAC-006 | Formal naming, tagging and layout conventions | - | ✔ | ✔ | Linter or automated policy that validates naming conventions and mandatory tags; resources without mandatory identification tags are rejected. |
| IAC-007 | Traceable and approved plan before any apply | - | ✔ | ✔ | PR with the plan output attached and reviewable; approval recorded before apply; evidence that the apply took place after approval and on the same plan. |
| IAC-008 | Traceability file → resource → environment | - | ✔ | ✔ | Possible to identify, for any provisioned resource, the source IaC file, the environment and the pipeline that created it; evidence available at audit. |
| IAC-009 | Automated enforcement of policies in the pipeline | - | - | ✔ | Policy rules (e.g. OPA/Rego, Sentinel) active in the pipeline; logs of blocking due to policy violations available; policy versioned with the code. |
| IAC-010 | Plan artefacts and manifests versioned and hashed | - | ✔ | ✔ | Plans and manifests stored with a verifiable hash; integrity confirmed before the apply; artefacts not reusable across distinct environments. |
| IAC-011 | Secure management of secrets - prohibition of hardcoding | ✔ | ✔ | ✔ | No secrets in code, unprotected environment variables or versioned files; integration with a secrets vault (Vault, KMS, OIDC) verifiable; automated secrets scan in the pipeline. |
| IAC-012 | Automated detection of drift between IaC and actual state | - | ✔ | ✔ | Periodic drift reports available; active alerts for divergence between the state defined in IaC and the actual state of the infrastructure. |
| IAC-013 | Formal periodic review of modules and templates | - | - | ✔ | Review records with date, owner and findings; review cycle defined and evidence of compliance; obsolete modules or modules with known vulnerabilities withdrawn from service. |
Explanatory notes
- IAC-001: Applies whenever there is collaboration between multiple engineers, shared pipelines or more than one environment managed by the same state. In single-operator contexts with an isolated pipeline, locking may be waived with a documented justification.
- IAC-004: Any dependency on an external module must be treated as code untrusted by origin until explicitly validated. Shared internal modules are also subject to this requirement.
- IAC-007: Embodies the principle of technical change control in IaC: no
applyshould take place without direct traceability to a human approval of a verifiableplan. - IAC-009: A structural requirement for high-risk environments (L3), where reliance on manual review is insufficient to guarantee continuous policy coverage.
- IAC-011: The secrets scan must cover code, Git history and pipeline variables; reference tools: TruffleHog, GitLeaks, detect-secrets.
- IAC-012: Drift is treated as a security failure, not as an operational exception - infrastructure that diverges from the state defined in IaC represents unauditable risk.
For Security by Design principles applied specifically to IaC projects, see SbD Principles for IaC. For recommended automated validations and checks, see Validations and Checks. For management of exceptions to these requirements, see Exception Management. For traceability and tagging of resources, see Traceability and Tags.