What Is IaC Scanning? A Practical Guide

An engineer writes twelve lines of Terraform to stand up an S3 bucket for log storage. The block leaves off one argument, so the bucket defaults to no encryption and a public ACL. They apply it, the pipeline goes green, and a publicly readable bucket is now live. A week later three more buckets exist, all copied from the same module, all public. Nobody clicked a wrong button in a console. The mistake was in code, it was reviewed and merged like any other code, and it provisioned itself across the estate. IaC scanning is the control that reads that Terraform before apply runs and fails the build on the missing encryption and the public ACL, so the bucket is fixed in the pull request instead of discovered in an audit.

Infrastructure as code turns servers, networks, and policies into files that get versioned, reviewed, and applied automatically. That is a real gain in speed and consistency, and it is also why one bad line propagates: the same template that builds one resource builds a hundred. IaC scanning checks those files for security problems before they become running cloud resources. This guide covers what IaC scanning is, what it looks for, where in the pipeline it runs, the process around it, the tools that do it, where it breaks down, and how teams keep it useful.

What is IaC scanning?

IaC scanning is the practice of analyzing infrastructure-as-code files, Terraform, CloudFormation, Kubernetes manifests, Helm charts, ARM templates, before they are applied, to find misconfigurations, exposed secrets, and policy violations. A scanner parses the code, evaluates it against a set of rules, and reports the resources that would be provisioned insecurely if the code ran as written. It is a static check on the definition of the infrastructure, not on the infrastructure itself.

The reason it matters is that the code is the source of truth. In an IaC workflow, nobody hand-configures a security group in the console; they write it in a file, and that file decides what the cloud builds. So the file is where the misconfiguration lives, and the file is the cheapest place to catch it. Finding a public bucket in code costs a one-line diff. Finding the same bucket after it has been live and indexed for a month is an incident.

IaC scanning is the static-analysis pillar of broader cloud security. It sits left of runtime controls: instead of detecting a bad configuration after the cloud provider provisions it, it reads the intent and stops the bad configuration from being provisioned at all. That shift-left position is what makes it a DevSecOps control rather than a monitoring one. It runs where the code is written and merged, not where it is deployed.

What IaC scanning looks for

A scanner is only as useful as the categories of problem it catches. IaC scanning covers four that matter most.

• Misconfigurations. The core function: insecure settings that would create an exposed or weakly protected resource. An unencrypted database, a storage bucket open to the public, a security group allowing 0.0.0.0/0 on port 22, logging disabled on an account. These are correct code that builds an incorrect-from-a-security-standpoint resource.
• Overly permissive access. IAM policies and rules that grant more than the resource needs: a wildcard action on a wildcard resource, a role assumable by any account, a network rule open to the world. These are the misconfigurations attackers reach for first because they turn one foothold into many.
• Exposed secrets. Credentials hardcoded into the IaC: an access key in a Terraform variable default, a password in a manifest, a token committed into a Helm values file. A secret in code is a secret in version control history, where it stays even after the line is deleted.
• Compliance and policy violations. Deviations from a benchmark or an internal standard: a configuration that fails a CIS Benchmark, a resource that breaks a tagging policy, a region or service the organization has banned. This is where the scan proves the code meets the rules, not just that it lacks obvious flaws.

The first three are about insecure resources. The last is about whether the code meets the rules the organization is held to. A scanner that only flags open ports and ignores the wildcard IAM policy and the hardcoded key leaves the highest-leverage problems unreported.

Where IaC scanning runs

Scanning is not a single gate. The same code can be scanned at several points, and the earlier it runs the cheaper the fix, because the goal is to catch the problem before it ever provisions a resource.

Pre-commit scanning runs locally, in the editor or a git hook, the instant the code is written. It gives the author the tightest feedback loop: the missing encryption argument is flagged before the commit exists, so it never enters a pull request.

Pull-request scanning runs in CI on every change and is the primary gate. This is where the full ruleset evaluates the changed Terraform or manifests and a failing result blocks the merge, so insecure code does not reach the main branch.

Pre-deploy scanning runs in the deployment pipeline, against the plan about to be applied. It is the last automated check before the cloud provider provisions anything, and it catches problems in the actual resources a change will create, not just the static text.

Drift and continuous scanning runs on a schedule against both the repository and the live environment. It catches resources that someone changed by hand outside of code, and it re-evaluates already-merged code against rules that did not exist when it merged.

The IaC scanning process

Tooling is one part. The process around it is what turns a scanner into a control. A working IaC scanning program runs roughly this loop.

1. Establish policies. Decide what the scanner enforces: which benchmarks (a CIS Benchmark, an internal standard), which severities block a build, what is allowed to warn versus fail. Without this, the scanner's defaults decide your security posture by accident.
2. Integrate with CI/CD. Wire scanning into the pipeline so it runs automatically on every change. A scan a person has to remember to run is not a control. A scan the pipeline runs on every PR is.
3. Scan. Run the analysis against the IaC on commit, on PR, and before deploy. The same code gets evaluated at the points above.
4. Review results. Triage the findings: what is a real misconfiguration, what is a false positive that does not apply to this environment, what is severe enough to block.
5. Remediate. Fix the real findings in code, in the same pull request where possible, so the fix ships with the change that introduced the risk.
6. Refine the policies. Feed what triage learned back into the ruleset: suppress the genuine false positives, tighten the rules that let something through, add coverage for new resource types. The policy set is maintained, not set once.

The loop matters more than any single run. A scanner pointed at a stale policy set, or one whose findings nobody triages, produces noise that the team learns to ignore, which is how a real critical gets waved through with the rest.

Policy as code

The rules a scanner enforces are themselves code. Policy as code (PaC) is the practice of writing those security and compliance rules in a machine-readable language so they are versioned, reviewed, and applied automatically, the same way the infrastructure is. Open Policy Agent and its Rego language, and HashiCorp Sentinel, are the common ways to do it.

The reason PaC pairs with IaC scanning is consistency. If the rules live in code beside the infrastructure code, every pipeline evaluates the same policy, a rule change goes through review like any other change, and there is a history of what the policy was on any given date. A rule that lives in one engineer's head, or in a wiki nobody reads, is enforced unevenly or not at all. Writing the policy as code is what makes "we require encryption on every bucket" an enforced gate instead of a guideline.

IaC scanning tools

Scanners fall into a few categories by what they analyze, and most real programs run more than one because no single tool covers everything.

• Static configuration analyzers. Parse the IaC and match resources against a library of misconfiguration rules. Checkov (open source, by Prisma Cloud) scans Terraform, CloudFormation, Kubernetes, Helm, and more. Trivy (by Aqua Security) scans IaC misconfigurations alongside images and dependencies; its trivy config command absorbed the older tfsec project, which was merged into Trivy and is no longer developed standalone, so new work targets Trivy.
• Compliance scanners. Focus on mapping findings to benchmarks and regulatory frameworks. Terrascan (open source) evaluates IaC against policies built on the Open Policy Agent engine and ships rules mapped to common standards.
• Dependency scanners. Check the modules and providers the IaC pulls in, the same supply-chain problem as any other dependency: a vulnerable or malicious module imported into your infrastructure code.
• Secret scanners. Detect credentials committed into the IaC and its history. Often a dedicated tool run alongside the configuration analyzer, because a config scanner tuned for misconfigurations is not always tuned for secrets.

The reason to run more than one is coverage. A configuration analyzer that catches the open security group may miss the hardcoded key; a secret scanner that catches the key does not evaluate the IAM policy. The combination, run consistently in the pipeline, is what gives a complete picture rather than a partial one.

Where IaC scanning breaks down

Scanning is easy to bolt on and hard to keep useful. The same few problems show up in most programs.

Policy complexity. Writing and maintaining a policy set that fits the organization is real work. Too loose and the scanner misses real risk; too strict and it blocks legitimate changes and trains people to override it. Keeping the rules current with new services and new resource types is ongoing, not a one-time setup.

Workflow friction. A scanner wired in clumsily slows every pull request and breaks builds on findings developers see as noise. When that happens, teams route around it, with blanket suppressions or by skipping the gate, and the control quietly stops controlling anything. Fit to the existing workflow matters as much as detection quality.

Keeping pace with threats. New misconfiguration classes and new attack techniques appear constantly. A ruleset that was complete last year has gaps now. The scanner and its policies need the same maintenance as any detection: current rules, regular review, validation that they still catch what they should.

False positives and noise. Too many findings that do not apply and the team starts ignoring all of them, which is how a real critical slips through with the noise. Tuning suppressions to the environment, and confirming the suppressions do not hide real risk, is continuous work. This is why a passing IaC scan is not proof of safety; the pass is only as good as the policy set and the tuning behind it.

Making IaC scanning work

The fixes are mostly process, not a bigger tool.

1. Shift it left and automate it. Run scanning as early as the editor and as a required CI check, triggered by the pipeline, not by a person. The earliest catch is the cheapest fix.
2. Gate the merge, not just the report. A scan that runs and emails a report is documentation. A scan that fails the build on a blocking finding is a control. Wire it so insecure code cannot merge.
3. Write policy as code. Keep the rules versioned and reviewed beside the infrastructure, so every pipeline enforces the same standard and rule changes have a history.
4. Tune for signal. Triage findings, suppress what genuinely does not apply, and keep the noise low enough that a blocking finding still means something. An ignored scanner protects nothing.
5. Maintain the ruleset. Update policies for new services and new misconfiguration classes, and re-scan existing code against new rules. The threat set moves; the policy has to move with it.

Done together, these turn IaC scanning from a box-check into the place infrastructure risk is caught, in the pull request, before the cloud builds anything, which is both the cheapest place to fix it and the only place that scales to the rate IaC changes.

Frequently Asked Questions

What is IaC scanning?

IaC scanning is the practice of analyzing infrastructure-as-code files, such as Terraform, CloudFormation, and Kubernetes manifests, before they are applied, to find misconfigurations, exposed secrets, overly permissive access, and policy violations. It is a static check on the code that defines the infrastructure, so security problems are caught and fixed in the code review instead of after the resources are live.

What does an IaC scan check for?

A scan covers four main categories: misconfigurations such as an unencrypted database or a public storage bucket, overly permissive access such as a wildcard IAM policy, exposed secrets such as a hardcoded access key, and compliance or policy violations against a benchmark like a CIS Benchmark or an internal standard.

Where in the pipeline does IaC scanning run?

It can run at several points: in the editor or a pre-commit hook for the fastest feedback, in CI on every pull request as the main gate that blocks a merge, in the deployment pipeline before apply as the last check before resources are provisioned, and on a schedule to catch drift and newly added policy failures. Running it early and often is cheaper than catching the problem at runtime.

What tools are used for IaC scanning?

Common open-source tools include Checkov, which scans Terraform, CloudFormation, Kubernetes, and Helm, and Terrascan, which maps findings to compliance benchmarks using the Open Policy Agent engine. Trivy scans IaC misconfigurations alongside container images and dependencies; the older tfsec project was merged into Trivy and is no longer developed on its own. Most programs run a configuration analyzer plus a dedicated secret scanner for full coverage.

What is the difference between IaC scanning and policy as code?

IaC scanning is the act of analyzing infrastructure code against rules. Policy as code (PaC) is how those rules are written: in a machine-readable, versioned language such as Open Policy Agent's Rego or HashiCorp Sentinel, so the policy is reviewed and applied automatically. PaC is the ruleset; IaC scanning is the enforcement that runs it against the code.

Does a passing IaC scan mean the infrastructure is secure?

No. A pass is only as good as the policy set and the tuning behind it. A loose ruleset, missing coverage for a new service, or aggressive false-positive suppression can all let real risk through, and scanning only checks the code, not the running environment, where drift and runtime exposure still apply. A passed scan lowers risk; it does not prove the infrastructure is secure.

The bottom line

IaC scanning reads infrastructure-as-code, Terraform, CloudFormation, Kubernetes manifests, and the rest, before it is applied, and reports the misconfigurations, exposed secrets, overly permissive access, and policy violations it finds. It matters because in an IaC workflow the code is the source of truth: the file decides what the cloud builds, so the file is where the misconfiguration lives and the cheapest place to fix it. Catching a public bucket in a pull request is a one-line diff; catching it after it ships is an incident.

The value is in the process around the tool. Establish the policies, write them as code, wire scanning into the pipeline as a required gate, triage the findings, fix them in the same change, and keep the ruleset current. A scanner with a stale policy set or untuned noise produces a green check that means little, which is how a misconfigured resource or a leaked key rides merged code straight into the cloud and can feed a software supply chain attack. IaC scanning does not secure the cloud on its own. It makes insecure infrastructure visible while it is still text in a pull request, which is the earliest and cheapest place to stop it.