An IaC scan analyzes your infrastructure-as-code — Terraform, CloudFormation, Kubernetes manifests, ARM/Bicep templates — for insecure configurations before that code provisions any real infrastructure. Instead of discovering that an S3 bucket is public after it is already serving your customer data, an iac scan catches the acl = "public-read" line in the pull request. It is the cheapest place in the entire lifecycle to fix a cloud security problem, because at that point the problem is a text diff, not a live exposure.
What an IaC scan actually checks
Infrastructure-as-code turned server provisioning into files you commit to git. That was a huge operational win, and it also means your security posture is now partly encoded in those files — and inherits their bugs. An IaC scan applies a library of policy rules against the declared configuration and flags the ones that violate secure defaults.
The recurring findings are consistent across every cloud:
- Storage buckets or blobs made publicly readable or writable.
- Security groups or firewall rules opening ports like SSH (22) or RDP (3389) to
0.0.0.0/0. - Encryption at rest disabled on databases, volumes, or object storage.
- IAM policies granting
*actions on*resources. - Logging or audit trails (CloudTrail, flow logs) not enabled.
- Kubernetes workloads running as root or without resource limits.
None of these are exotic. They are the boring defaults that ship insecure and that a human reviewer skims past in a 400-line Terraform plan. A scanner does not get bored on line 380.
How it differs from other scans
It is easy to lump every "scan" together, so be precise about what an IaC scan is not. SAST scans your application source code. SCA scans your open-source dependencies. A container scan looks at image layers. An IaC scan looks at the declared configuration of your infrastructure — a distinct artifact from all three. A project frequently needs several of these because each covers a different layer, and a clean IaC scan tells you nothing about a vulnerable library in your app.
The other important distinction is timing. An IaC scan is a shift-left control: it runs against configuration files pre-deployment. A cloud security posture management (CSPM) tool scans what is already running. You want both — the IaC scan prevents new misconfigurations from being introduced, and CSPM catches drift and anything provisioned outside your IaC.
Wiring it into CI
The value of an IaC scan multiplies when it runs automatically on every change rather than as an occasional manual sweep. Open-source scanners like Checkov, tfsec (now part of Trivy), and Terrascan run from a single command and integrate cleanly into pipelines.
A minimal Checkov run against a Terraform directory:
checkov -d ./infra --compact
In GitHub Actions, gating a pull request on the result:
- name: IaC scan
run: |
pip install checkov
checkov -d ./infra --hard-fail-on HIGH
Two design choices matter here. First, run it on pull requests, not just on the main branch, so the feedback reaches the author while the change is still fresh. Second, gate on severity. If you fail the build on every low-severity note, developers learn to bypass the check; if you fail only on HIGH and CRITICAL, the gate stays credible.
Managing false positives without going numb
The failure mode of IaC scanning is not missing bugs — it is crying wolf until the team ignores it. A default rule set will flag things that are intentional in your environment (a bucket that is public by design because it hosts a static site, an open port that a WAF sits in front of). Handle these deliberately:
- Use inline suppressions with a required justification comment, so every exception is documented in the code where the reviewer sees it. Checkov's
#checkov:skip=CKV_AWS_20:Public static site, fronted by CDNsyntax is a good pattern. - Tune the rule set to your actual cloud providers and compliance requirements rather than running everything.
- Track suppression counts over time. A steadily growing pile of skips is a signal that a rule is mistuned or that a real risk is being papered over.
The goal is a scan whose failures always mean something, because a scan the team trusts is one they will not route around.
Bringing it together with the rest of your pipeline
An IaC scan is one control in a layered pipeline. The misconfiguration in your Terraform, the vulnerable dependency in your app, and the outdated base image in your container are three separate problems, and mature teams gate on all three. Consolidating those signals so a single view shows deployment readiness is exactly what a supply-chain security platform is for — an SCA and policy tool such as Safeguard can evaluate IaC findings alongside dependency and container results against one policy gate. For hands-on rule-writing and cloud-hardening material, the Academy goes deeper.
FAQ
What file types does an IaC scan cover?
Typically Terraform (.tf), CloudFormation (YAML/JSON), Kubernetes manifests, Helm charts, ARM/Bicep templates, and Dockerfiles. Coverage varies by scanner, so confirm your specific formats are supported before standardizing on a tool.
Is an IaC scan the same as a cloud security posture (CSPM) scan?
No. An IaC scan checks configuration files before deployment (shift-left). CSPM scans infrastructure that is already running. They complement each other: IaC scanning prevents bad config from being introduced, CSPM catches drift and out-of-band changes.
Which IaC scanner should I start with?
Checkov and Trivy (which absorbed tfsec) are widely used open-source options with broad rule coverage and easy CI integration. Start with one, tune its rules to your providers, and gate CI on high and critical findings. You can layer a commercial tool later if you need policy management across teams.
How do I stop an IaC scan from flooding developers with false positives?
Gate the build only on high and critical severities, tune the rule set to your actual cloud providers, and require documented inline suppressions for intentional exceptions. Monitor the number of suppressions over time to catch rules that are mistuned.