What is IaC Security?

What IaC security means

Infrastructure as Code security is the practice of scanning IaC templates for security misconfigurations before they get deployed to cloud environments. Terraform files, CloudFormation templates, Kubernetes manifests, Helm charts, Dockerfiles – any declarative configuration that defines infrastructure can be checked against security policies automatically.

The idea is straightforward. If your infrastructure is defined in code, you can review that code for security issues the same way you review application code for bugs. A misconfigured S3 bucket is just a few lines of Terraform. Catch it in the pull request instead of finding it in production after someone exfiltrates your data.

IaC scanning tools read your templates, parse them into a structured representation, and check each resource against a library of security policies. A policy might say “S3 buckets must have encryption enabled” or “security groups must not allow inbound traffic from 0.0.0.0/0.” The tool compares what your code defines against what the policy requires. Failures get reported with the exact file, line number, and resource name.

This is shift-left for infrastructure. The same concept that SAST brought to application security – find problems in the code before they become live vulnerabilities – applied to cloud infrastructure. The difference is that IaC misconfigurations are often easier to fix than application bugs, because you are changing a configuration value rather than rewriting logic.

Why IaC security matters

Cloud misconfiguration is not a theoretical problem. It is the leading cause of cloud security incidents. Gartner has projected that through 2025, 99% of cloud security failures would be the customer’s fault, and misconfiguration sits at the top of that list.

The numbers back this up. The 2024 IBM Cost of a Data Breach report puts the average breach cost at $4.88 million. The 2024 Verizon DBIR repeatedly calls out misconfiguration as a factor in web application breaches. Most of these are preventable with checks that any IaC scanner runs out of the box.

Why bother when you could just review Terraform manually? A few reasons.

Speed. An IaC scan runs in seconds. A Terraform plan with 200 resources scans in under a minute on any modern tool. A manual security review of the same infrastructure takes days and still misses things.

Consistency. Humans miss things. Especially on the 50th pull request of the week. An automated scanner applies the same policies to every change, every time. CIS Benchmarks, organizational standards, compliance requirements – all enforced without relying on someone remembering to check.

Cost. Fixing a misconfiguration in a Terraform file costs a developer five minutes. Fixing the same misconfiguration after it causes a breach costs orders of magnitude more.

Common IaC misconfigurations

These are the issues that IaC scanners flag most often. They are also the misconfigurations behind most cloud breaches.

Public storage buckets

S3 buckets, Google Cloud Storage buckets, and Azure Blob containers configured with public access. The Capital One breach in 2019 started with a misconfigured WAF but the data was in publicly accessible S3 storage. Every IaC scanner checks for this. It is the most basic rule in every policy library.

Overly permissive IAM

IAM policies with "Effect": "Allow", "Action": "*", "Resource": "*" give full administrative access. IaC scanners flag wildcard actions, wildcard resources, and missing condition constraints. The principle of least privilege is easy to state and hard to maintain manually across hundreds of IAM policies.

Open security groups

Security groups or network ACLs that allow inbound traffic from 0.0.0.0/0 on sensitive ports like SSH (22), RDP (3389), or database ports (3306, 5432, 27017). These are among the first things attackers scan for in cloud environments.

Unencrypted storage and databases

EBS volumes, RDS instances, S3 buckets, and similar resources without encryption at rest. Many compliance frameworks (PCI DSS, HIPAA, SOC 2) require encryption. IaC scanners check both that encryption is enabled and that customer-managed keys are used where required.

Disabled logging and monitoring

CloudTrail not enabled, VPC flow logs not configured, S3 access logging disabled. Without logging, you cannot detect or investigate incidents. IaC scanners verify that logging resources exist and are properly configured.

Exposed databases

RDS instances, Elasticsearch domains, or Redis clusters with public accessibility enabled. Databases should sit in private subnets and only be reachable through application servers or bastion hosts. A publicly accessible database is one credential-stuffing attack away from a breach.

Missing network segmentation

Resources in the default VPC, subnets without network ACLs, or missing private subnet configurations for sensitive workloads. IaC scanners check that network architecture follows isolation best practices.

How IaC scanning works

IaC scanners use several techniques under the hood. Understanding them helps when you are evaluating tools or debugging why a scan missed something.

Policy-based checking

The core mechanism. The scanner maintains a library of policies (also called checks, rules, or queries depending on the tool). Each policy defines a condition that a resource must meet. “aws_s3_bucket must have server_side_encryption_configuration” is a policy. The scanner evaluates every resource against every applicable policy and reports failures.

Checkov ships with 3,000+ policies. KICS has 2,400+ Rego-based queries. Trivy inherited tfsec’s policy library. The size and quality of the built-in policy library is the main differentiator between tools.

Graph-based analysis

Standard policy checks look at individual resources in isolation. Graph-based analysis looks at relationships between resources. This catches a class of misconfigurations that single-resource checks miss.

Example: an EC2 instance connects to a network interface, which is in a subnet, which is in a VPC. A graph-based check can verify that this entire chain is properly configured – that the subnet is private, the VPC has flow logging, and the network interface has the right security group attached. Checkov is the only open-source tool with graph-based policies (800+ of them).

Framework-specific parsers

Each IaC framework has its own syntax and semantics. Terraform HCL is different from CloudFormation YAML is different from Kubernetes manifests. IaC scanners need parsers for each format that understand the resource types, attribute names, and relationships specific to that framework.

This is why framework support varies between tools. Writing a parser for Terraform is not the same effort as writing one for Bicep or Pulumi. Broader framework support usually means each individual parser gets less depth.

Custom policies

Built-in policies cover common misconfigurations, but every organization has specific requirements. Custom policies let you encode your own standards.

The major policy languages:

• Python or YAML – Checkov supports both. YAML policies are declarative and easy to write. Python policies offer full programmatic flexibility.
• Rego – KICS, Trivy, and Terrascan use Rego, the Open Policy Agent language. Powerful but has a learning curve.
• OPA/Rego – Snyk IaC supports custom rules in Rego on paid plans.

If your team already uses OPA for Kubernetes admission control, Rego-based tools fit naturally. If not, Checkov’s YAML format has a gentler onboarding curve.

IaC frameworks covered

IaC security tools do not all support the same frameworks. Here is what the ecosystem covers.

Terraform

The most widely scanned IaC framework. Every tool in this space supports Terraform HCL. Some also scan Terraform plan output (JSON), which captures the resolved values after variable interpolation and module expansion. Plan scanning is more accurate than static HCL scanning because it sees the actual values that will be deployed. For a hands-on walkthrough of setting up Terraform scanning with CI/CD pipeline examples, see our Terraform security scanning guide.

CloudFormation

AWS-specific. Scanned by all major tools. Includes both YAML and JSON formats. AWS SAM templates are also covered by most scanners since SAM compiles down to CloudFormation.

Kubernetes manifests

YAML files that define pods, deployments, services, network policies, and other Kubernetes resources. Scanners check for privileged containers, missing resource limits, hostPath mounts, missing security contexts, and other Kubernetes-specific misconfigurations.

Helm charts

Helm templates are rendered into Kubernetes manifests before scanning. Most tools handle this rendering internally. Checkov, KICS, Trivy, and Kubescape all support Helm charts.

Dockerfiles

Checked for running as root, using the latest tag, exposing unnecessary ports, adding secrets in build layers, and missing health checks. Dockerfile scanning overlaps with container security but fits in the IaC scanning workflow because Dockerfiles are committed alongside infrastructure code.

ARM templates and Bicep

Azure-specific. ARM templates (JSON) are supported by most tools. Bicep (the newer Azure IaC language that compiles to ARM) has narrower support. Checkov and KICS handle both.

Ansible

Ansible playbooks and roles can be scanned for insecure module usage, hardcoded credentials, and privilege escalation. Checkov, KICS, and Trivy support Ansible scanning.

Others

KICS has the widest coverage at 22+ frameworks, including OpenAPI specs, gRPC, Pulumi, Crossplane, Google Deployment Manager, and GitHub Actions workflows. Checkov covers OpenTofu, Kustomize, Serverless Framework, and AWS CDK.

IaC security vs CSPM

IaC security and CSPM (Cloud Security Posture Management) solve the same underlying problem – cloud misconfiguration – but at different stages of the lifecycle.

IaC security operates pre-deployment. It scans your code before anything reaches the cloud. The feedback loop is fast: a developer writes Terraform, the CI pipeline scans it, misconfigurations are flagged in the pull request. Nothing insecure gets deployed in the first place.

CSPM operates post-deployment. It connects to your live cloud accounts (AWS, Azure, GCP) through APIs and continuously monitors the actual state of your infrastructure. It catches drift (someone changed a security group through the console), resources created outside of IaC, and misconfigurations that IaC scanning missed.

They are not competing approaches. IaC security is preventive. CSPM is detective. A mature cloud security program runs both.

Some tools bridge the gap. Snyk IaC offers drift detection that compares your Terraform state against your live cloud environment. Checkov integrates with Prisma Cloud, which provides CSPM alongside IaC scanning. Trivy can scan running Kubernetes clusters directly, which is closer to runtime monitoring than static scanning.

The practical advice: start with IaC scanning because it is free, fast, and catches the most common issues. Add CSPM when you need visibility into what is actually running and want to detect changes made outside your IaC workflow. For teams evaluating broader cloud security platforms, our CSPM vs CNAPP comparison covers when a standalone CSPM tool is enough versus when you need a full CNAPP platform.

Top IaC security tools

The IaC security space is unusual in that all the best tools are free and open-source. Here are the ones worth evaluating. For full reviews and comparisons, see the IaC security tools page.

Open-source

• Checkov – 3,000+ policies for Terraform, CloudFormation, Kubernetes, Helm, and 10+ other frameworks. Graph-based cross-resource checks are unique to Checkov. Maintained by Palo Alto Networks (Prisma Cloud). The deepest IaC-specific scanner available. 8,500+ GitHub stars.

• KICS – 2,400+ Rego-based queries covering 22+ IaC platforms. Widest framework coverage of any scanner. Built by Checkmarx. Good if you use less common IaC formats like OpenAPI, Pulumi, or Crossplane. 2,600+ GitHub stars.

• Trivy – IaC scanning plus container image vulnerabilities, dependency CVEs, secrets detection, SBOM generation, and Kubernetes cluster scanning in one binary. Absorbed tfsec. If you want one tool instead of five, Trivy minimizes sprawl. 31,700+ GitHub stars. See our Checkov vs Trivy comparison for a detailed head-to-head.

• Kubescape – CNCF incubating project focused on Kubernetes security. Scans manifests, Helm charts, and running clusters against CIS, NSA-CISA, and MITRE ATT&CK frameworks. Includes runtime threat detection. 11,200+ GitHub stars. Best choice for teams where Kubernetes is the primary concern.

• Terrascan – 500+ OPA/Rego policies, Kubernetes admission controller, drift detection. Maintained by Tenable. Note: the project was archived in November 2025. The codebase remains available under Apache 2.0, but there will be no new releases. Consider Checkov, KICS, or Trivy as actively maintained alternatives.

Commercial

• Snyk IaC – Part of the Snyk platform. Freemium model with a generous free tier. Inline fix suggestions in IDEs and pull requests. Paid plans add cloud environment scanning with drift detection, custom rules, and compliance reporting. Good for teams already using Snyk for SCA or container scanning.

Getting started

If you have never run IaC scanning before, here is a practical path.

Pick one tool. If you use Terraform, start with Checkov. Install it with pip install checkov and run checkov -d . in your Terraform directory. If you want broader coverage beyond IaC, install Trivy and run trivy config . on the same directory. Both take under two minutes to set up.

Review the initial results. Your first scan will produce findings. Go through them. Most will be real issues you did not know about. A few will be false positives or findings that do not apply to your environment. Suppress those so they do not clutter future results.

Add it to CI. Run the scanner on every pull request that touches IaC files. Start in warning mode – report findings but do not block merges. Let the team see the value before enforcing gates.

Enable quality gates. Once the team trusts the results, block merges on high and critical findings. Keep medium-severity findings as warnings. This is where IaC scanning pays off: misconfigurations stop reaching production entirely.

Write custom policies. Every organization has requirements that generic policies do not cover. Internal naming conventions, required tags, mandatory encryption keys from your KMS. Checkov custom policies in YAML are the easiest to write. KICS and Trivy use Rego if your team is already in the OPA ecosystem.

Map to compliance frameworks. If you have compliance requirements (CIS, SOC 2, PCI DSS, HIPAA), configure your scanner to report against those frameworks. Checkov has built-in compliance mappings. This turns IaC scanning from a security tool into an audit tool.

FAQ

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.