Advanced Recommendations for Secure IaC
This annex presents reinforced practices for security in Infrastructure as Code (IaC) projects. The recommendations described here are not mandatory, but should be considered in:
- Organisations with high security maturity;
- Regulated environments or environments with certification requirements;
- Projects with high exposure or risk (e.g. critical infrastructure);
- Supply chains that require proof of compliance (e.g. SLSA, ISO 27001, DSOMM level 3).
📌 Policy and semantic enforcement with OPA / Sentinel
| Theme | Description |
|---|---|
| OPA with detailed Rego rules | Create rules by resource type, environment and project |
| Enforcement with Sentinel (TFC/TFE) | Apply organisational policies with a Terraform execution gate |
| Linters with adapted rulesets | Use of Conftest, Checkov or tfsec with a customised profile per project |
| Comparison with the security baseline | Validate deviations from policy per repository/project |
| Integration with CI/CD | CI fails if the execution violates policies |
🎯 Reinforces trust, standardises the application of rules and enables proof of compliance.
📊 Reinforced provenance and traceability
| Theme | Description |
|---|---|
Hash and retention of plan files | Each execution must generate a plan file with a hash and retention per version |
| Execution metadata | Commit, branch, tag, user, runner and hash associated with the applied plan |
| IaC template version | Include in the repository and in the artefact being deployed |
| Tamper-proof application record | Store the effective plan and apply in an auditable repository |
📎 Facilitates audit, rollback, proof of state and forensic analysis.
🔁 Integration with cost and “drift”
| Theme | Description |
|---|---|
Integration with Infracost | Compare the estimated cost per plan with the approved baseline |
| Continuous drift detection | Active monitoring of differences between code and real infrastructure |
| Alerts for modifications outside Git | Verification of whether an apply occurred outside PRs or the pipeline |
🧩 Integration with cost and drift enables early detection of anomalies, and financial and technical control.
🔐 Security in module provenance
| Theme | Description |
|---|---|
| Generation of SBOM for templates | Record the modules, resources and providers used in a readable format |
| Semantic validation of providers | Blocking of unaudited or untested versions |
| Replacement of external sources | Specify internal mirrors, private registries and trusted repositories |
| Audit of changes to modules | Validate whether changes introduce insecure configurations (e.g. open ACLs) |
💡 These practices help treat IaC modules as software, subject to a secure SDLC.
🧪 Programmatic infrastructure tests
| Theme | Description |
|---|---|
terratest with Go | Tests of resource application and rollback, validating outputs and routes |
opa test for policies | Unit tests for security rules written in Rego |
kitchen-terraform | Integration tests of temporary environments |
| Integration into the pipeline | Automatic tests per PR or release, with archived logs and results |
🧬 Guarantees that the provisioned infrastructure is functional and secure, validating behaviour beyond syntax.
📋 Governance of technical exceptions
| Theme | Description |
|---|---|
| Validation of exceptions with a cycle | Each exception with an owner, deadline and formal review |
| Audit of executions with bypass | Logs of bypasses or forced flags analysed periodically |
| Automation of reassessment | Jobs that flag expired exceptions or exceptions due for review |
| Exception reports per stack | Compliance dashboards per project and environment |
🧾 Continuous governance of exceptions ensures that technical "security debt" is visible, traceable and reviewed.
✅ Conclusion
These recommendations are not mandatory, but they constitute valuable reinforcements for teams with high maturity or that operate in regulated contexts.
📌 Their application directly reinforces the Design & Development, Build & Test and Operate & Monitor domains of OWASP DSOMM, making it possible to reach level 3 maturity in security practices applied to IaC.
For applications with an L3 risk classification, it is recommended to consider a subset of these practices as a mandatory baseline.