You already have fmt and validate catching basic errors. But those commands check that the code is correct, not that it is secure. Perfectly valid code can create dangerous infrastructure: an S3 bucket open to the world, an unencrypted database, a Security Group with SSH exposed. To detect this, there is static security analysis, with tools like Checkov and tfsec.

validate (subchapter 21.1) would tell you this code is "fine":

Syntactically, it is correct. But you are creating a bucket with confidential data open to the internet (remember the danger from subchapter 5.4). validate does not detect this, because it is not a code error: it is a security error. You need something that knows best practices and warns you.

Static analysis examines your code without executing it (without creating anything in AWS) and compares it to a database of security rules and best practices. If it finds a dangerous configuration, it warns you by pointing out exactly what is wrong and why.

Analogy: it's like a safety inspector reviewing the blueprints of a building before it is built. They don't wait for the building to be finished to discover that a fire exit is missing: they detect it in the blueprint and force you to fix it first. Static analysis reviews the "blueprints" (your code) and catches security problems before deployment.

There are several tools for this; the two best known in the Terraform world are:

Checkov (from the company Prisma/Bridgecrew) is a very popular and comprehensive tool. It comes with hundreds of predefined rules that check security best practices and compliance in AWS (and other clouds). It detects things like public buckets, unencrypted resources, dangerous open ports, missing logs, etc.

tfsec is another widely used tool, specifically focused on Terraform and security. It is fast and easy to integrate. (It is worth knowing that tfsec has been integrated with Trivy, another tool in the same field; the ecosystem evolves, but the idea is the same.)

Both do a similar job: they analyze your code and list the security problems found. Many teams use one or the other (or both).

These tools catch exactly the security errors we have mentioned throughout the book:

It's like having a security expert reviewing every change, who never gets tired or distracted, consistently applying hundreds of rules that a person could not remember all at once.

Just like fmt and validate (subchapter 21.1), these tools are run in CI, automatically, on every Pull Request:

This way, no insecure change can reach production without someone consciously approving it. If a developer, by mistake, writes a public bucket, the CI detects it and blocks the PR. This is "shift left": detecting security problems as early as possible (in the code), not when they are already in production and an attacker finds them before you do.

Real world example: a developer, in a hurry, configures an unencrypted database for a test and, without realizing it, that code ends up in a PR to production. The CI runs Checkov, which detects "RDS database without encryption at rest" and blocks the PR with a clear message. The developer adds encryption, resubmits, and now it passes. The security flaw never reached production, and all automatically.

Sometimes these tools flag something that, in your specific case, is intentional and acceptable (for example, a bucket that must be public because it serves a static website, subchapter 5.5). For those cases, you can exclude specific rules in a justified way (with annotations in the code or in the tool's configuration). But do it consciously and with documentation, not just to silence annoying warnings without thinking: every exception must have a clear reason.

• fmt and validate check that the code is correct, but not that it is secure: valid code can create dangerous infrastructure (public buckets, unencrypted DBs, open SSH).
• Static security analysis examines your code without executing it and compares it to hundreds of best practice rules, warning you of dangerous configurations. Like an inspector reviewing blueprints before building.
• The main tools are Checkov (very comprehensive, multi-cloud) and tfsec (focused on Terraform, now linked to Trivy). They do a similar job.
• They integrate into CI to automatically block insecure changes in every PR: this is the "shift left" principle (catching problems as early as possible).
• Manage false positives by excluding specific rules in a justified and documented way, not by silencing warnings lightly.

In the next subchapter, we will move on to more comprehensive tests: integration tests with Terratest, which create real infrastructure and verify that it works.