Rationale - IaC Requirements Catalogue
🧠 Why this chapter is exceptional
This chapter is different from the others.
While Ch. 02 - Security Requirements defines a common base applicable to any software, a specialised technical catalogue (IaC requirements`) is presented here, covering risks and controls specific to Infrastructure as Code (IaC).
This covers aspects such as:
- state integrity,
- automatic validations in plan/apply,
- composition of environments,
- file→resource→environment traceability,
- enforcement in the pipeline.
👉 Each IaC requirement gives rise to its own user story, allowing exhaustive and auditable coverage, without gaps or ambiguities.
🔑 Fundamental points of the exceptionality
a) Different lifecycle and teams
IaC projects have a lifecycle distinct from application projects.
Normally:
- Architecture/Infra/Platform maintain the IaC, defining clusters, network, permissions, storage, etc.
- Application Development Teams use that infrastructure to put software into production, but do not control its base configuration.
👉 This separation means that the readers of this chapter may differ from those of others: here the focus is on those who build and govern the infrastructure, not only on those who develop applications.
b) IaC is also software
Although peculiar, an IaC project is, at heart, a software project.
It must therefore comply with the cross-cutting controls already defined in SbD-ToE:
- Risk classification (Ch. 01)
- Threat modelling (Ch. 03)
- Secure pipelines (Ch. 07)
- Dependency and SBOM management (Ch. 05)
- Automatic validations (linters, SAST for IaC)
- Governance and audit (Ch. 14)
⚠️ The difference is that an error in IaC does not affect just one application, but all the applications that depend on that infrastructure.
Hence the rigour: IaC must be treated with the same scientific discipline applied to the code it serves.
📚 Technical sources underpinning the catalogue
The IaC requirements catalogue is not arbitrary: it results from the synthesis of normative and market sources.
Among them:
- CIS Benchmarks (AWS, Azure, GCP, Kubernetes, Docker, Terraform)
- Kubernetes (Pod Security Standards, Network Policies, Admission Control, Audit Logging)
- NIST SP 800-53 and NIST SP 800-190
- Cloud Security Alliance - CCM
- ISO/IEC 27001 (Annex A: change control, least privilege, segregation of duties)
- SSDF (NIST 800-218) and SLSA (supply chain)
- Market practices (Terraform, Pulumi, OPA, Sentinel, Kyverno)
🧩 Relationship with Ch. 02 - Security Requirements
- The IaC requirements complement the security requirements of Ch. 02.
- Wherever possible, direct traceability is established:
| IaC Requirement | Objective | Ch. 02 Mapping | Note |
|---|---|---|---|
| IAC-001 Remote backend with locking | State integrity | SEC-CFG-STATE | Use of S3+DynamoDB+KMS |
| IAC-003 Automatic validations | Avoid bad practices | SEC-VAL-SHIFTLEFT | tflint, tfsec, OPA in PR |
IAC-007 plan review | Formal change control | SEC-CRL-PR | plan attached to PR; approval gate |
| IAC-010 Signing/Provenance | Supply chain | SEC-SUPPLY-PROV | Signing + verified provenance |
🧱 How to adapt the organisational catalogue
The catalogue published here (IAC-001 to IAC-010) is a prescriptive baseline.
Each organisation must adapt it to its own reality, following a clear methodology:
- Inventory the stacks and providers used
- Classify risks (L1–L3)
- Select applicable requirements
- Define thresholds/gates (High/Critical failures block at L2/L3)
- Specify expected evidence (logs,
plan, SBOM, signatures) - Automate validations (linters, policies, provenance)
- Govern exceptions (register, deadline, compensations, dual approval at L3)
- Audit and improve continuously (scorecards, drift metrics, blocked failures)
🧾 Why user stories per requirement
Unlike other chapters, the work here is not limited to macro practices.
Each IaC requirement becomes its own user story, because this:
- Guarantees that no requirement is forgotten
- Allows direct integration into the backlog (reusable cards)
- Ensures requirement → evidence → practice traceability
- Facilitates L1–L3 proportionality requirement by requirement
⚖️ L1–L3 proportionality (principles applied to IaC)
| Domain | L1 (low) | L2 (medium) | L3 (critical) |
|---|---|---|---|
| Automatic validations | Block (failure blocks the apply) | Block High/Critical | Block Medium+ |
plan approval | Recommended | Mandatory | Mandatory + dual approval |
| Remote backend/state | Recommended | Remote with locking | Remote + monitoring and break-glass |
| Module origin | Pinning recommended | Pinning mandatory | Allowlist + formal review + SBOM |
| Signing/provenance | Recommended | Mandatory | Mandatory + automatic rejection |
📦 Expected evidence
- Repo structure per environment;
backend.tf - Pipelines with lint/security/policies in PR and main
terraform planattached to PR, approved beforeapply- Exception register with deadline and compensations
- SBOM of modules/providers
- Signatures + provenance (SLSA)
- Correlated commit→pipeline→apply logs
- Compliance and drift dashboards
🚫 Frequent anti-patterns in IaC
Learning from recurring errors is essential.
Among the most dangerous anti-patterns, the following stand out:
- Terraform local state without locking → concurrent corruption
- Direct apply to production without an approved plan → untraceable changes
- External modules pinned to a branch (
main) → supply chain risk - Absence of network policies/admission control → expanded attack surfaces
- Secrets hardcoded in IaC variables → accidental exposure
- Lack of SBOM/artefact signing → untrustworthy builds and deploys
🏛️ Governance and metrics
A catalogue is only effective if it is governed and measured.
The following is recommended:
- Ownership: Architecture/Platform + AppSec
- Periodic review: quarterly, of the IaC requirements catalogue
- KPIs/KRIs:
- % of PRs with
planapproved beforeapply - Scanner coverage in IaC
- % of pinned/validated modules
- No. and average age of active exceptions
- Drift detected and time to correction
- % of PRs with
📌 How to read this chapter
- Read this Rationale to understand the exceptionality and methodology.
- Proceed to intro.md for the framing, roles and policies.
- Use aplicacao-lifecycle.md for practical integration into the SDLC.
- Consult 20-checklist-revisao.md for operational control.
- Review examples and templates in the
addon/directory.
👉 In summary: Requirements → User Stories → Evidence → Proportionality → Audit.
It is this chain that ensures that IaC is treated with the same scientific rigour as any other critical software artefact.