The "Spellcheckers" of Infrastructure Code
Before you dive into complex policy engines, you should start with static analysis tools. They look directly at your source code files (like .tf files) and check them against a library of known security best practices — no plan generation required.
Think of them like a spellchecker for your code editor. You don't need to compile and run a program to know you've misspelled a word. Similarly, static analysis tools don't need to contact AWS to know that acl = "public-read" on an S3 bucket is dangerous.
Common tools:
- Checkov (by Bridgecrew/Palo Alto): Supports Terraform, CloudFormation, Kubernetes, Dockerfiles, and more. Has 1,000+ built-in checks.
- tfsec (now integrated into Trivy): Terraform-focused, fast, and easy to embed in CI.
Pros:
- Zero configuration to get started — install and run.
- Catches the most common, well-known misconfigurations immediately.
- Runs directly on source files, so it works even before terraform init.
Cons:
- Rules are pre-baked. You can write custom checks, but it requires more effort.
- Cannot express complex organizational logic like "Allow t3.micro instances only if the environment tag is set to dev." That kind of conditional, cross-attribute logic requires a proper policy engine like OPA.
- False positives are common. A public S3 bucket hosting a static website is intentional, but Checkov will still flag it unless you explicitly suppress the check.
Checkov can be pointed at a directory or a single file, with output formats ranging from human-readable to JSON for CI integration. It outputs a structured report showing each check's ID (e.g., CKV_AWS_20), the resource that failed, the file and line number, and a description of the violation. This makes it easy to trace failures back to the exact line of code that needs fixing.