A misconfigured S3 bucket or an overly permissive security group is rarely the result of a deliberate decision — it's usually a default that nobody thought to lock down. IaC scanning catches these before they ever reach a live cloud account.
Why scan the code instead of the cloud
Scanning cloud resources after deployment (CSPM) tells you something is wrong after it's already live and potentially exposed. Scanning the Terraform or CloudFormation code that defines those resources catches the same misconfiguration before it's ever applied — in a pull request, where it costs nothing to fix.
What these scanners catch
- Publicly readable/writable storage buckets
- Security groups open to the internet on sensitive ports
- Unencrypted storage or databases
- Overly permissive IAM policies (wildcard actions or resources)
- Missing logging/audit configuration on critical resources
Where to run it
- Locally, via pre-commit — fast feedback while writing IaC.
- In CI, on every pull request — the primary gate. Block merges on high-severity findings.
- Periodically against live state — to catch drift where someone applied a change outside the normal PR process.
Common tools
Open-source options like tfsec, checkov, and terrascan all support policy-as-code rules for Terraform, and most integrate directly into CI with minimal setup. Many also support custom rules for org-specific policies (e.g. "all S3 buckets must have versioning enabled").
Avoiding alert fatigue
Not every finding needs to block a merge. Start by gating only critical/high severity findings (public exposure, missing encryption on sensitive data), and treat lower-severity findings as visibility rather than a hard block. Expand gating gradually as your team builds trust in the scanner's accuracy.
Catching a misconfigured bucket in a PR review costs a comment. Catching it after a data exposure costs a lot more than that.