Static Analysis

Static analysis tools read your Terraform code and flag problems validate structurally cannot see: deprecated arguments, invalid instance types, and — the category that matters most — security misconfigurations like a public S3 bucket or a security group open to 0.0.0.0/0 on port 22. They do this without running a plan or touching AWS, by parsing the configuration and matching it against rule sets.

Two distinct kinds of tool live under this name, and conflating them is how teams end up half-covered. tflint is a linter for correctness and provider best practices. tfsec, checkov, and trivy are security scanners for misconfiguration and compliance. Running them in CI moves whole classes of bug — the open port, the unencrypted volume — to the left of the pipeline, caught in seconds on a pull request instead of in production after an incident.

tflint

tflint is provider-aware in a way validate is not. With its AWS ruleset enabled, it knows that t2.mega is not a real instance type, that an argument was deprecated in a recent provider version, and that a declared variable is never used. It catches the correctness mistakes that are valid HCL — they parse and type-check fine — but are wrong against the actual AWS provider. It runs against the code directly, no plan required.

# install the AWS ruleset once, then lint
tflint --init
tflint --recursive

Security Scanners

Security scanners exist to catch the misconfigurations that cause breaches: an S3 bucket without public-access blocks, an RDS instance without encryption at rest, a security group allowing inbound SSH from anywhere, an IAM policy with Action: "*". tfsec, checkov, and trivy each ship hundreds of such rules and parse your config to find them. They are the reviewers who never get tired and never miss the one open port in a 400-line diff.

# scan the current directory against the bundled ruleset
trivy config .

# example finding
# HIGH: aws_security_group.web ingress allows 0.0.0.0/0 on port 22

Policy Coverage and Suppressions

Each scanner ships a baseline of generic best-practice rules, and you tune that baseline to your standards — disabling checks that do not apply to you, raising or lowering severities. Some findings will be deliberate exceptions: a bucket that genuinely must be public for static hosting, a port that must be open for a known reason. For those you write an inline suppression with a justification, so the build goes green for the right reason and the next reader sees why.

Suppress sparingly and with a comment, because a blanket suppression is indistinguishable from a real exposure to everyone who comes after you. Review the list of suppressions periodically; an exception that made sense a year ago may now be a hole nobody remembers opening.

In the Pipeline

Run the linter and a security scanner on every pull request, after fmt and validate but before or alongside plan. The operational decision is which findings block the merge and which only warn. Treat high-severity security findings — public access, weak or absent encryption, wide-open ingress — as blocking; let lower-severity style and informational findings warn without stopping the build. A scanner that blocks on everything trains the team to bypass it; one that blocks only on what matters keeps its authority.