IaC Security: Securing Terraform & CloudFormation Before Deployment

Common IaC Misconfigurations

These are the misconfigurations that IaC scanners catch most frequently. Each one has been involved in real-world data breaches.

IaC Scanning Tools Comparison

Most teams start with Checkov or tfsec (now part of Trivy) for open-source IaC scanning, then layer in a platform like TigerGate for unified scanning across code, infrastructure, containers, and cloud posture with centralized policy management.

The Overlooked Attack Surface: State Files and Modules

Scanning resource definitions is necessary but not sufficient — Terraform's operational machinery has its own attack surface that scanners largely ignore.

State files contain secrets

Terraform state stores resource attributes in plaintext JSON — including database passwords, generated private keys, and API tokens, even when the corresponding variables are marked sensitive. A readable state bucket is functionally equivalent to a leaked secrets vault. Lock down the state backend with a dedicated IAM policy, enable bucket encryption and versioning, block public access explicitly, and never commit terraform.tfstate to git. Where possible, keep secrets out of state entirely by referencing them at runtime (e.g., an RDS password managed by Secrets Manager with manage_master_user_password).

Modules are a supply chain

A third-party module from the Terraform Registry executes with the full privileges of your pipeline's cloud credentials. Unpinned module sources (ref=main instead of a version or commit hash) mean your infrastructure changes when someone else pushes code. Pin module versions, review module source before first use, prefer a curated internal registry of vetted modules, and remember that malicious providers are also possible — provider checksums in .terraform.lock.hcl exist for exactly this reason and belong in version control.

The pipeline is the privilege

The CI job that runs terraform apply typically holds near-admin cloud credentials, which makes it a prime target. Use OIDC federation instead of static keys, split plan (runs on PRs, read-only role) from apply (runs on merge, write role, protected environment), and require human approval between them for production workspaces.

Beyond Built-in Rules: Policy as Code

Off-the-shelf rules encode generic best practice; policy as code encodes your rules — the ones auditors and architects actually care about. Examples: every S3 bucket must use a customer-managed KMS key from the security account; production databases may only live in the two approved regions; every resource must carry a cost-center tag matching a defined pattern; no IAM role may trust an account outside the organization.

Two ecosystems dominate. OPA/Rego (used by Conftest, Terrascan, and KICS) evaluates the Terraform plan JSON against declarative policies, and the same Rego skills transfer to Kubernetes admission control. Checkov takes a lower-friction path: custom rules in Python or YAML, which most platform teams find faster to author. Sentinel fills the same role for teams on HCP Terraform / Terraform Enterprise, with the advantage of running inside the plan/apply workflow natively.

Whichever engine you choose, treat policies like production code: version them in their own repository, write test cases with known-good and known-bad fixtures, and stage rollouts — new policies start as warnings, graduate to soft-fail with an exception process, and only then become hard gates. An exception process matters more than teams expect: a policy with no documented escape hatch gets bypassed with --skip-check comments scattered through the codebase, which is worse than having no policy at all because it looks like coverage.

Finally, map policies to compliance frameworks from day one. Most scanners annotate rules with CIS, PCI DSS, HIPAA, and SOC 2 references; preserving those mappings in your custom rules means every passing pipeline run doubles as audit evidence, and a failed control maps directly to the framework requirement it would violate.