Automated Validations and Quality Control in the IaC Project

🌟 Objective

Ensure that all changes in Infrastructure as Code (IaC) projects are treated as untrusted input, subject to blocking automated validations, and accompanied by auditable evidence before any application in a real environment.

This file establishes the mandatory technical minimum to ensure that the IaC project:

• is correct (syntax and structure);
• is secure (configuration, permissions, exposure);
• is understood (real impact of the plan);
• is auditable (evidence linked to the decision and to execution);
• does not degrade control when supported by automation or assisted tools.

In the SbD-ToE model, automated validation is a control mechanism, not an optional optimisation.
Without blocking validation and minimum evidence, there is no effective governance of IaC.

---

🧩 Base principle: untrusted input by origin

In a modern engineering context, IaC changes may be produced by:

• humans,
• templates,
• normalisers,
• scripts,
• generators,
• assisted or automated mechanisms.

Fundamental prescription:
👉 The origin of a change is never a guarantee of security.
👉 All proposed IaC is treated as untrusted input, with additional reinforcement when the change is produced or modified by automated mechanisms.

Consequently:

• no change may reach apply without blocking validation;
• validation must address real effects, not only form;
• the decision to execute must be explicit, traceable and evidenced.

This principle is operationalised by the technical validations and gates defined in this document.

---

📌 What must be done (minimum prescription)

The organisation must ensure, at a minimum:

1. Execution of linters and syntax validators (e.g. terraform validate, tflint);
2. Application of IaC-specific security scanners;
3. Validation of compliance with internal policies (naming, tagging, permissions, modules);
4. Integration of all validations into the CI/CD pipeline, with mandatory failure;
5. Generation and validation of terraform plan (or equivalent) before any apply;
6. Semantic validation of the real impact of the plan;
7. Automatic blocking when critical requirements are not met;
8. Storage and correlation of minimum evidence (plan + reports + approval).

---

⚙️ How to apply (types of validation)

Type of Validation	Technical purpose
Syntactic	Ensure that the code is valid and executable
Structural / Linting	Enforce standards, avoid recurring bad practices
Security	Detect exposures, excessive permissions, insecure configurations
Policy-as-Code	Enforce organisational rules automatically
Semantic validation	Assess the real impact of the plan
Execution control	Prevent apply without validation and approval
Evidence	Ensure decision → execution traceability

Illustrative tools and techniques

Category	Examples
Syntax / format	terraform fmt, terraform validate, yamllint
Linting	tflint, actionlint, ansible-lint
Security	tfsec, checkov, kics, terrascan
Policies	OPA/Rego, Sentinel, Conftest
Pipeline	Mandatory gates on PR/MR and pre-apply
Local	Mandatory pre-commit hooks

Tools are means; the requirement is the verifiable effect.

---

🔍 Semantic validation of the plan (mandatory where applicable)

Beyond syntax, the real impact of the plan must be assessed, including:

• creation, change or destruction of resources per environment;
• expansion of permissions (e.g. IAM, roles, wildcards);
• network exposure (public endpoints, permissive rules);
• absence of encryption or logging on critical resources;
• indirect changes through modules, providers or dependencies;
• unexpected or unexplained diffs.

Prescription:
👉 Semantic validation must work as a blocking gate, not as an informational warning.

---

🧾 Mandatory minimum evidence

For validation to be auditable, the organisation must ensure:

• plan generated in CI associated with:
  • PR/MR,
  • commit hash,
  • target environment;
• reports from linters, scanners and policies associated with the same PR/MR;
• explicit record of approval before apply;
• retention of artefacts proportional to risk and internal obligations.

Without this evidence, there is no proof of control, only technical execution.

---

🕒 When to apply

Moment	Expected validations
Commit / Push	Local linters, pre-commit hooks
Pull Request	Linters + scanners + policies + plan
Merge to release	Reinforced validation + complete evidence
Pre-apply	Final verification of plan, hashes and environment
Periodically	Drift, revalidation of modules and dependencies

---

👥 Profiles involved

Role	Responsibility
DevOps / Infra	Technical integration of the validations into the pipeline
AppSec / Security	Definition and maintenance of policies
Development	Remediation of findings and explanation of impact
Cloud / Architecture	Validation of real effects and secure design

---

🧪 Practical examples

• Pipeline blocked by tfsec on overly broad IAM permissions;
• checkov preventing a merge because of an unencrypted bucket;
• OPA policy blocking a plan that creates a public endpoint;
• Mandatory validate-iac job before apply;
• PR rejected because of an unexplained diff on a critical resource.

---

✅ Control checklist (per project)

• All changes are treated as untrusted input
• Automated validations are blocking
• Semantic validation of the plan exists
• plan and reports are linked to PR/MR + commit
• Approval before apply is recorded and auditable
• Evidence is retained according to criticality

---

🔗 Cross-references

Document	Relation
15-aplicacao-lifecycle.md	User stories for validation, plan and approval
addon/04-principios-sbd-iac.md	SbD principles applied to IaC
addon/11-uso-ferramentas-automatizadas-iac.md	Rules for automation/assistance

---

⚠️ The absence of blocking automated validations and minimum evidence turns IaC into a privileged channel of systemic risk, compromising security, auditing and governance.