Terraform security scanning — Checkov, tfsec and Terrascan

Infrastructure as Code turns cloud configuration into version-controlled files, and Terraform is the most widely used tool for writing it. Because a single Terraform plan can create storage buckets, networks, and identity roles across an entire cloud account, a misconfiguration here has the same blast radius as a misconfiguration in production itself. This lesson introduces Checkov, tfsec, and Terrascan, three scanners that catch insecure infrastructure patterns before a single resource is ever created.

Analogy🏏Cricket

🎮 Think of it like gaming: a single Terraform plan is a save file that, when loaded, spawns your entire world at once — every server, network, and permission. Loading a corrupted save doesn't glitch one room; it rebuilds the whole map broken, exactly as the file describes. That is why the best players validate a save before loading it rather than after. Checkov, tfsec, and Terrascan act as that pre-load integrity check, reading the file and refusing it if the world it would build is unsafe. This reveals why scanning the config beforehand carries the same weight as guarding live production itself.

These scanners work by parsing Terraform configuration statically, without needing cloud credentials or an actual deployment, and comparing each resource block against a library of known-bad patterns. A public storage bucket, an unencrypted database, an overly permissive security group opening every port to the internet, or an IAM policy granting wildcard permissions are all patterns these tools recognise instantly, long before the plan is ever applied and the resource actually exists in a live account.

Analogy🏏Cricket

🎵 Think of it like music: a trained ear can read a score silently off the page and hear the wrong note before a single instrument is played, because it recognises the shape of a bad chord instantly. It needs no orchestra, no hall, no performance — just the notation and years of pattern memory. A static Terraform scanner reads configuration the same way, spotting a public bucket, an unencrypted database, or a wildcard permission as an obviously discordant chord in the written score, long before anything is deployed. This reveals how a tool can judge safety purely from the notation, with no live account required.

Under the hood, each tool ships hundreds of built-in checks mapped to common frameworks such as CIS benchmarks, and each supports custom rules for organisation-specific requirements. Checkov and Terrascan lean on structured policy definitions, while tfsec focuses on fast, Terraform-native pattern matching. Running any of them, or combining several for broader coverage, on every plan gives a consistent, automatic second opinion that never skims past the details a rushed human reviewer might miss.

Analogy🏏Cricket

📷 Think of it like photography: a studio's quality review runs every shot through a fixed checklist — focus, exposure, white balance, horizon level — plus a few house rules the client always demands. Two reviewers might reach for slightly different tools, one a sharp loupe and one a calibrated screen, but both apply the same disciplined pass and never tire or skim. Checkov, tfsec, and Terrascan are those reviewers for infrastructure: hundreds of standard checks from frameworks like CIS, plus your own custom rules, applied identically every time. This reveals why an automated second opinion catches the tired-eye details a rushed human waves through.

bash

# Static scan of Terraform config before any plan is applied
checkov -d ./infra --framework terraform --compact
tfsec ./infra
terrascan scan -i terraform -d ./infra

# Example finding (Checkov):
# CKV_AWS_20  FAILED  "S3 Bucket has an ACL defined which allows public READ access"

Analogy🏏Cricket

🏏 Think of it like cricket: scanning Terraform before applying it is inspecting the pitch, the boundary rope, and the sightscreens before a single ball is bowled, not after a six has already sailed into the crowd. A cracked rope or a soft, damp patch found in the morning costs the groundsman ten quiet minutes with a roller and a stitch. The very same flaw discovered mid-innings, with a packed stadium watching, costs a stoppage, an official inquiry, and a far angrier crowd than any groundsman wants to face. This reveals why the cost of a defect multiplies the moment it moves from the config file to the live account.

Best practice runs these scanners as a mandatory pipeline gate on every pull request that touches infrastructure code, failing the build on high-severity findings the same way SAST gates block insecure application code. Maintain a reviewed suppression list for accepted exceptions with clear justification and expiry, keep custom rules for organisation-specific requirements such as mandatory tagging or approved regions, and re-run scans whenever the underlying rule set updates, since new checks continually get added as new risks are discovered.

Analogy🏏Cricket

✈️ Think of it like travel: airport security is not a courtesy you request when you feel like it — every passenger clears the same scanner on every flight, and a flagged bag stops the queue until it is resolved. Genuine exceptions, like a diplomatic pouch, get a documented, signed, time-limited waiver rather than a wink-through, and the screening rules are refreshed the instant a new threat appears. Running scanners as a mandatory gate on every infrastructure pull request, with a reviewed suppression list carrying justification and expiry, works exactly this way. This reveals why unskippable enforcement beats occasional voluntary checks.

In the real world, a platform team might catch a security group accidentally opening SSH to the entire internet the moment a pull request is opened, weeks before that infrastructure would have been provisioned and exposed. The developer sees the failing check, adjusts the CIDR range to a specific office IP, and the plan passes cleanly, turning what could have been a scanned-and-exploited server into a two-minute pull-request fix.

Analogy🏏Cricket

🎬 Think of it like movies: a continuity supervisor spots that a character's watch is on the wrong wrist while reviewing the dailies that same evening, not after the film has premiered to a full cinema. Caught in the review, it is a trivial reshoot of one shot before anything is locked; caught at the premiere, it is a flaw burned permanently into every print. When a scanner flags a security group opening SSH to the whole internet the instant the pull request opens, the developer simply tightens the CIDR range and moves on. This reveals how catching the error in review turns a live, exploitable server into a two-minute fix.

A Terraform misconfiguration can have the same blast radius as one in live production.
Checkov, tfsec, and Terrascan statically scan config without needing cloud credentials.
Common findings include public buckets, open security groups, and wildcard IAM policies.
Gate every infrastructure pull request on high-severity scan findings.
Maintain a reviewed suppression list and keep custom rules for org-specific requirements.