12 IaC Scanning Tools Across Four Categories to Help You Choose One
IaC scanning is also not one job: catching a public S3 bucket before merge and understanding what a change reaches once it ships are different challenges, and no tool in this roundup does both.
IaC scanning tools help developers check Terraform, CloudFormation, OpenTofu, or Kubernetes manifests for a public S3 bucket, an overly permissive IAM policy, or a hardcoded API key before any of it reaches a live environment.
IaC scanning tools are one slice of a much broader infrastructure-as-code tools landscape. Even within that slice, "IaC scanning tools" isn't a single product category. An open-source CLI scanner you self-host for free, a scanning feature built into the CI/CD platform you already run pipelines through, a full cloud-native application protection platform (CNAPP) with scanning as one module among several, and a dedicated commercial scanner built specifically around code and infrastructure security all provide overlapping but different solutions.
Treat them as interchangeable, and you risk ending up adopting the wrong one for the constraint you're trying to overcome: budget, an existing platform relationship, a multi-cloud footprint, or a specific compliance requirement.
This article contains twelve current tools into four categories, with a verified comparison table and category details.
It also covers which open-source names are still actually maintained, what GitLab's built-in scanning runs under the hood, and where a graph-aware execution layer fits once a scan comes back clean.
What is IaC scanning, and why do you need it?
What IaC scanning actually checks
An IaC scan is an automated, static analysis of infrastructure definition files – Terraform, OpenTofu, CloudFormation, Kubernetes manifests, or Azure Resource Manager templates – run before any of it gets applied to a live environment to reduce potential risks and security issues.
A scanner parses the IaC files and evaluates each resource block against a library of rules, flagging anything that matches a known pattern for a security misconfiguration, such as a storage bucket without encryption, a security group open to 0.0.0.0/0, or an access key sitting in plain text inside a variables file.
Although IaC scanning gets lumped with static application security testing (SAST), there is a distinction:
- SAST analyzes application source code for logic vulnerabilities, like SQL injection or cross-site scripting.
- IaC scanning analyzes infrastructure configurations for configuration risk in the cloud resources that code will eventually create. Different inputs, different rule sets, and in most pipelines, different stages entirely.
Why IaC scanning is important to Terraform and OpenTofu teams
A misconfigured resource in a Terraform module has a ripple effect throughout your whole infrastructure. Reference that module fifteen times across as many environments, and the same missing encryption flag or overpermissive IAM policy ships fifteen times over, often before anyone notices the pattern.
That specific risk is the one you can use IaC scanning to catch before it becomes an issue: not a single bad click, but a template error that reproduces itself everywhere the template gets used.
The standard risk list is familiar to anyone who has sat through a cloud security review: overpermissive IAM roles and security groups, unencrypted storage, secrets hardcoded into .tfvars files or leaked through CI logs, and compliance violations against frameworks like CIS Benchmarks or PCI DSS.
None of that should be unfamiliar, but also none of it needs a sophisticated attacker to turn into an incident. It's the everyday cost of shipping infrastructure fast enough that you can no longer do a manual review of every resource block, which is when you need to automate scanning.
How IaC scanning fits a CI/CD pipeline
Most teams integrate IaC scanning at the pull request stage: a scan runs as part of the CI/CD pipeline, findings surface as inline PR comments or a failed build check, and a merge either waits on a fix or an explicit override.
Policy-as-code is what causes this to scale past a vendor's default rule set. Open Policy Agent (OPA) and its Rego language show up as the common underlying standard across several of the tools below, enabling a team to codify its own security policies instead of accepting whatever a tool ships with out of the box.
Wired in early enough in the software development lifecycle, scanning can become part of your everyday developer workflow rather than a separate gate someone has to remember to run.
The table below sorts all twelve tools by category (Terrascan, which you may have been expecting to see, has been archived so is no longer included).
| Tool | Category | 1-sentence description |
|---|---|---|
| Checkov | Open-source and general-purpose | Broad, actively maintained static analysis across Terraform, CloudFormation, Kubernetes, and more, with graph-based checks that reason about resource relationships. |
| tfsec / Trivy | Open-source and general-purpose | tfsec has folded into Trivy, the actively maintained successor that adds container and SBOM scanning alongside IaC checks. |
| KICS | Open-source and general-purpose | Checkmarx-maintained, broad-format open-source scanner that also happens to be the engine running under GitLab's built-in IaC scanning. |
| GitLab IaC scanning | CI/CD-native and platform-integrated | Built-in pipeline feature available on every tier that executes the KICS analyzer under the hood. |
| Wiz | CNAPP | Correlates IaC findings with live cloud and runtime attack-path data inside a broader CNAPP. |
| Orca Security | CNAPP | Agentless CNAPP that scans IaC as part of a wider cloud workload visibility platform. |
| CrowdStrike Falcon Cloud Security | CNAPP | IaC scanning delivered as one module of Falcon's broader cloud security platform, under the same console as Falcon endpoint security. |
| Sysdig | CNAPP | Pairs OPA-based IaC policy checks with drift detection that compares deployed configuration back against the original template. |
| Upwind | CNAPP | Feeds runtime signal back into IaC scan prioritization, with unusually candid vendor content about scanning's own limits. |
| Snyk IaC | Dedicated commercial | Developer-first IaC scanning integrated into IDE, CLI, and SCM workflows alongside Snyk's other application security products. |
| Checkmarx IaC Security | Dedicated commercial | Commercial wrapper around the same KICS engine covered above, with Checkmarx One's unified enterprise reporting and governance layered on top. |
| Stategraph | Graph-native execution layer with built-in scanning | Bundles Checkov for automatic misconfiguration scanning, then layers blast-radius context on every finding, i.e., how much infrastructure depends on it, that a standalone scanner can't give you. |
Open-source and general-purpose IaC scanning tools
This category is where teams without budget for a commercial platform yet, or those building a custom pipeline on top of open primitives, should start: free, self-hosted CLI scanners with no vendor relationship required.
Checkov
Best for: Teams that need the broadest policy coverage across the most IaC formats in a single, actively maintained open-source scanner.
Checkov runs static analysis against Terraform, CloudFormation, Kubernetes manifests, Bicep, Serverless Framework configuration, and a handful of other formats through one Python-based policy engine.
That breadth enables a team to run a single scanner across most of what it actually deploys, instead of stitching together one tool per format.
Checkov started life at Bridgecrew, later acquired by Palo Alto Networks and folded into Prisma Cloud, though the open-source project itself has stayed free throughout.
Its graph-based checks are what set it apart from a simple rule-per-resource scanner: rather than evaluating each resource block in isolation, Checkov builds a graph of relationships between resources and can catch a security group that looks locked down on its own but is exposed through the load balancer it's attached to.
The project remains under active development, with commits landing within the last week of this article's research.
Features
- Custom policies written in Python or YAML for rules specific to an organization's own risk tolerance.
- Thousands of built-in checks spanning CIS Benchmarks, HIPAA, and PCI DSS out of the box.
- Native CI integrations for GitHub Actions, GitLab CI, and Jenkins, so a scan runs without custom pipeline glue.
Pros and cons
| Pros | Cons |
|---|---|
| Broadest multi-format coverage of the open-source tools here | Can be noisy out of the box until policies are tuned to actual risk tolerance |
| Actively maintained, with commits landing within the last week | Graph-based checks add scan time on very large configurations |
Trivy/tfsec
Best for: Teams after fast, Terraform-aware static analysis.
tfsec's original pitch was speed and focus: a lightweight scanner built specifically for Terraform, running quickly in CI without a broader tool's scope. That project is now part of Trivy.
Trivy, from the same maintainers, absorbed tfsec's IaC checks into a much broader tool that also scans containers, filesystems, and software bills of materials (SBOMs) for security vulnerabilities. Trivy is where you will find new checks and CVE coverage.
Features
- Unified scanning across containers, filesystems, and IaC misconfigurations in one CLI instead of several separate tools.
- Inline HCL suppression comments carried over from tfsec, so existing suppression patterns keep working after migrating.
- SBOM generation alongside IaC checks, useful for teams already tracking software supply chain data.
- Broad IaC format support, covering Terraform, CloudFormation, Kubernetes, and Dockerfile in the same scan.
Pros and cons
| Pros | Cons |
|---|---|
| Consolidation into one actively maintained, actively growing tool | Teams with existing tfsec-specific CI configs need to migrate command syntax |
| Trivy's broader scope catches issues Terraform-only scanning missed | The tfsec name and binary still work today, which can mask that it isn't where development happens |
KICS
Best for: Teams looking for an open-source scanner with genuinely broad IaC-format support, maintained by a company with a commercial reason to keep it current.
KICS, short for Keeping Infrastructure as Code Secure, covers Terraform, Ansible, CloudFormation, Kubernetes, Dockerfile, and Azure Resource Manager templates, among other formats, through a single open-source scanner.
Checkmarx has maintained the project since its creation and continues funding development, which shows up as regular commits.
KICS is the same engine GitLab runs under the hood for its own built-in IaC scanning, so adopting KICS directly and relying on GitLab's native scanning aren't that different.
Features
- Customizable, query-based policies for teams that want to extend or override the default rule set.
- Simple installation via standard package managers, without a heavier platform to stand up first.
Pros and cons
| Pros | Cons |
|---|---|
| Broad format support with active, well-funded maintenance | Smaller community and star count than Checkov or Trivy despite comparable format coverage |
GitLab IaC scanning: CI/CD-native and platform-integrated
GitLab's IaC scanning doesn't fit neatly into "open-source" or "CNAPP." It's a built-in pipeline feature of a platform many Terraform and OpenTofu teams already run CI/CD through, which makes it worth its own category rather than a footnote in someone else's.
GitLab IaC scanning
Best for: Teams already running GitLab CI/CD who want IaC scanning without adding a separate vendor or tool to their pipeline.
Per GitLab's own documentation, IaC scanning runs automatically in the test stage once enabled through a CI/CD template or component, and it executes the KICS analyzer to do the actual scanning. Supported formats span Terraform, CloudFormation, Ansible, Azure Resource Manager templates in JSON (Bicep files need converting first), Kubernetes, Dockerfile, OpenAPI, and Google Deployment Manager.
Results appear as pipeline job artifacts on every tier (Free, Premium, and Ultimate), which means a team gets real coverage without paying for anything beyond what it's already likely to be running.
The deeper reporting sits behind Ultimate specifically: merge-request integration, the vulnerability report, and approval workflows are gated to that tier, while Free and Premium users see findings but have to dig for them in job output rather than an integrated report.
The analyzer is KICS, so GitLab's built-in scanning inherits the same rule set covered above under a different name, wrapped in GitLab's own configuration layer.
Features
- Custom rulesets via a version-controlled sast-ruleset.toml file to disable or override individual KICS rules without forking anything.
- Offline and air-gapped configuration support for GitLab Self-Managed instances without direct internet access.
- Automatic vulnerability resolution when a rule is disabled or removed, so findings don't linger as stale noise in the vulnerability report.
Pros and cons
| Pros | Cons |
|---|---|
| Zero additional tool or vendor relationship for teams already on GitLab | Deeper reporting and MR integration require Ultimate |
| Version-controlled rule overrides via sast-ruleset.toml | Teams outside GitLab entirely get no benefit from this category at all |
CNAPP platforms with IaC scanning built in
A cloud-native application protection platform (CNAPP) treats IaC scanning as one module among several: posture management, runtime detection, and vulnerability management, all correlated together.
A pre-deployment finding has greater impact once it's tied to what's actually running in production, which is also where these platforms blur the line between static scanning and live cloud security posture management.
Wiz
Best for: Teams that want IaC scanning correlated directly with live cloud and runtime context inside a broader CNAPP.
Wiz Code scans Terraform, CloudFormation, Kubernetes manifests, and ARM templates, and its distinguishing move is connecting those code-level findings to cloud exposure and attack-path data from the rest of the Wiz platform.
A misconfiguration that's theoretically risky reads differently once it's tied to whether the resource in question is actually internet-reachable.
That correlation only really works if a team adopts more of Wiz's platform than the scanning module alone.
Features
- IDE and pull-request integration for inline feedback before code merges.
- Policy-as-code enforcement applied consistently across code and already-deployed cloud resources.
- Remediation guidance tied to the specific file and line that produced a finding.
Pros and cons
| Pros | Cons |
|---|---|
| Cross-context prioritization surfaces findings that are actually reachable, not just theoretically risky | Full platform value requires adopting Wiz's broader CNAPP, not just the scanning module |
| Consistent policy enforcement across code and already-deployed resources | Pricing requires a sales conversation rather than published tiers |
Orca Security
Best for: Teams drawn to IaC scanning as part of an agentless CNAPP that avoids deploying scanning agents into every environment.
Orca built its cloud workload visibility around what it calls SideScanning: an agentless approach to reading cloud environments without installing anything inside them. IaC scanning sits on top of that architecture as a shift-left extension of Orca's broader posture and vulnerability coverage.
For a team wary of yet another agent to patch and maintain across every environment, that agentless model is the main difference between Orca and most of the other CNAPPs in this list.
Features
- Agentless architecture reduces deployment overhead compared to agent-based competitors.
- Risk prioritization that weighs which findings correspond to real, reachable exposure rather than theoretical risk.
- Broad multi-cloud provider support across the major hyperscalers.
Pros and cons
| Pros | Cons |
|---|---|
| No agents to deploy or patch across environments | IaC scanning is one module of a much larger platform pitch |
| Prioritization based on real, reachable exposure | Evaluating the scanning module in isolation from the rest of Orca's CNAPP is difficult |
CrowdStrike Falcon Cloud Security
Best for: Teams already using CrowdStrike's Falcon platform for endpoint security who want IaC scanning under the same vendor and console.
Falcon Cloud Security folds IaC scanning in as one capability inside CrowdStrike's broader CNAPP, paired with the same threat intelligence that powers Falcon's endpoint and identity products.
It covers Terraform, CloudFormation, Kubernetes, and ARM templates, enforced through policy-as-code rules that live in the same console as the rest of a team's CrowdStrike deployment.
The real benefit for users is consolidation: one vendor, one console, and one support relationship for a team that already trusts CrowdStrike for endpoint security and doesn't want a second scanning vendor to manage separately.
Features
- Policy-as-code enforcement across IaC templates from within the existing Falcon console.
- Shared identity and threat intelligence with CrowdStrike's endpoint and identity products.
Pros and cons
| Pros | Cons |
|---|---|
| Single-console consolidation for teams already on Falcon | Limited standalone value for teams not already invested in the broader CrowdStrike ecosystem |
Sysdig
Best for: Teams after IaC scanning tied to a closed-loop drift-detection model that compares deployed cloud configuration back against the original template.
Sysdig's policy-as-code engine runs on OPA and evaluates IaC templates against pre-built policy mappings for CIS, NIST 800-53, SOC 2, PCI DSS, and HIPAA.
What sets it apart from a scan-and-forget model is post-deployment drift comparison: Sysdig checks what's actually running in the cloud against the template that supposedly produced it, closing a loop many other scanners leave open.
However, a team using Sysdig purely for pre-merge IaC checks is using a fraction of what the platform is built to do.
Features
- Pre-built policy mappings to CIS, NIST 800-53, SOC 2, PCI DSS, and HIPAA out of the box.
- Native CI/CD integrations with GitHub Actions, GitLab CI, Jenkins, CircleCI, and Azure DevOps.
- Risk-based alert consolidation to cut duplicate findings that trace back to the same root cause.
Pros and cons
| Pros | Cons |
|---|---|
| Strong compliance-framework mapping out of the box | Full value only shows up once a team adopts Sysdig's runtime monitoring, not scanning alone |
| Closed-loop drift comparison most pure scanners don't offer | The same closed-loop model means evaluating scanning in isolation undersells the platform |
Upwind
Best for: Teams that want IaC scanning explicitly paired with runtime insight from day one, rather than treating it as a standalone pre-deployment gate.
Upwind's own position is that IaC scanning is necessary but insufficient on its own: it can't catch configuration drift or an active runtime threat, only what's wrong with a template before deployment. This viewpoint is core to how Upwind pitches the rest of its platform.
Upwind feeds runtime signal back into scan prioritization, so a finding that corresponds to something actually running gets weighted differently than one sitting in a template nobody has deployed yet.
Features
- Custom policy validation for org-specific requirements, like mandatory storage encryption.
- Contextual, runtime-informed prioritization that cuts false positives compared to static severity scoring alone.
- CNAPP-native correlation between IaC templates and the live resources they actually produced.
Pros and cons
| Pros | Cons |
|---|---|
| Candid about scanning's own limits, which is a useful trust signal, while also trying to overcome these limits | A newer, smaller platform with less independent track record than the other CNAPPs here |
Dedicated commercial IaC and cloud security scanners
This category sits apart from a full CNAPP suite, referring to commercial platforms built specifically around code and IaC security scanning, which is generally lighter to adopt for a team that wants deep IaC, secrets, and dependency scanning without buying an entire cloud security platform.
Snyk IaC
Best for: Developer-first teams wanting IaC scanning integrated tightly into IDE, CLI, and SCM workflows alongside Snyk's other application security products.
Snyk IaC scans Terraform, CloudFormation, Kubernetes, Helm charts, and ARM templates, and supports custom policies written in Open Policy Agent's Rego language alongside its own built-in rulesets.
It also ships drift management, comparing deployed infrastructure back against the IaC that supposedly describes it, a capability that shows up more often in CNAPP platforms than in a dedicated scanner.
Where Snyk differentiates from the CNAPPs above is workflow integration. Findings surface directly in a developer's editor as inline fix suggestions, not only in a separate dashboard someone has to go check, consistent with Snyk's broader developer-first positioning across its other application security products.
Features
- CIS Benchmark-backed rulesets combined with Snyk's own threat research.
- Custom policy support via Open Policy Agent for organization-specific rules.
- In-line fix suggestions surfaced in the developer's editor rather than only in a dashboard.
Pros and cons
| Pros | Cons |
|---|---|
| Strongest developer-workflow integration of the dedicated scanners here, IDE, CLI, and SCM all natively supported | Full drift management and enterprise reporting sit behind paid tiers |
| Drift management pulls in a capability more common to CNAPPs than dedicated scanners | Snyk's core platform is closed source despite free-tier availability |
Checkmarx IaC Security
Best for: Enterprise application-security teams standardizing on Checkmarx's broader platform (SAST, software composition analysis, secret detection, and API security) who want IaC scanning under the same governance layer.
Checkmarx's commercial IaC Security product is built on the same KICS engine covered in the open-source category above, now wrapped inside Checkmarx One's unified triage, reporting, and enterprise support.
For a security team already running Checkmarx across application code, dependencies, and APIs, adding IaC under the same dashboard means one place to triage findings instead of a separate tool with its own login and its own report format.
Features
- Unified risk view alongside Checkmarx's other application security products in one dashboard.
- Enterprise-grade RBAC and audit reporting layered on top of raw KICS output.
- Dedicated support and SLA as part of the commercial platform.
Pros and cons
| Pros | Cons |
|---|---|
| Enterprise governance and unified reporting across the whole application security surface | Teams wanting only IaC scanning get the same underlying engine as the free KICS project, at commercial platform pricing |
Stategraph: built-in scanning with blast-radius context
Stategraph bundles Checkov, so every state gets scanned for misconfigurations automatically, the same job every tool above does.
What sets it apart is graph context: Stategraph stores state as a dependency graph rather than a flat file, so every finding also answers the question a standalone scanner can't: how much of your infrastructure depends on the misconfigured resource?
Best for: Enterprise Terraform and OpenTofu teams that want built-in misconfiguration scanning with blast-radius context, as well as a graph-aware layer for what happens once a change actually ships, including during an incident.
Stategraph stores the Terraform and OpenTofu dependency graph in a database instead of a flat state file, so a plan or apply scopes to the affected subgraph rather than refreshing everything a workspace manages.
Independent changes run in parallel instead of queuing behind a single global lock, and a change spanning multiple states commits as one atomic transaction with resource-level locking rather than a workspace-wide one.
Its security capabilities layer directly on top of that graph.
Checkov is bundled inside Stategraph, version-pinned and verified, with no separate tool to install or CI step to maintain, and runs automatically on state import, on apply, on a 24-hour default schedule, and at plan time for the security-impact delta – alongside on-demand scans from the API or CLI.
Every finding gets enriched with blast-radius data: how many resources and modules sit downstream of the misconfigured resource, sourced from the dependency graph rather than the flat file a standalone scanner reads.
stategraph tf plan extends that further, showing which findings a pending change adds or resolves before it applies, without blocking or gating the apply itself; Stategraph surfaces impact rather than enforcing a policy.
That graph context, plus resource-level access control and querying live infrastructure state for audit evidence, is what a scan-only tool can't offer even when it's checking the same Terraform files.
Features
- Built-in Checkov scanning on state import, apply, and on a schedule, with blast-radius context on every finding that a standalone scanner can't provide.
- SQL queries over the live infrastructure graph, not a grep across scattered .tfstate files.
- Non-destructive
.tfstateimport, exportable back to plain .tfstate at any time. - Self-hosted or BYOC deployment for teams with data-residency requirements.
Pros and cons
| Pros | Cons |
|---|---|
| Built-in Checkov scanning plus blast-radius context none of the scanners above provide | Scans configuration only, not live cloud, and doesn't map findings to compliance frameworks like CIS or SOC 2 |
| Blast-radius visibility none of the scanners in this article provide | Some repo shapes need adjustment before they fit the graph model |
| Parallel execution cuts plan and apply time at scale | |
| Resource-level locking removes global-lock contention during incident response | |
| Reversible import means no lock-in |
Conclusion
Most tools in this roundup do one job well: catching a misconfiguration before merge. Stategraph is the exception, bundling Checkov for that same job and then adding what a standalone scanner can't: blast-radius context on every finding, and a graph-aware layer for what a change actually reaches once it ships, including during an incident.
Whichever scanner from this list fits your needs, pipeline, budget, and platform, Stategraph is worth a look for the rest.
Try Stategraph free to see what a graph-aware plan looks like against your own state.
IaC scanning FAQs
What are the best IaC scanning tools?
There isn't a single best IaC scanning tool. You can split the list into four different product categroies solving different constraints: open-source scanners you self-host for free, CI/CD-native scanning built into a platform like GitLab, full CNAPP suites that correlate scanning with runtime context, and dedicated commercial scanners built specifically around code and infrastructure security.
Is IaC scanning the same as SAST?
No. Static application security testing (SAST) analyzes application source code for logic vulnerabilities like SQL injection or cross-site scripting.
IaC scanning analyzes infrastructure definition files for configuration risk, such as an overpermissive IAM role or a public storage bucket, not application logic. Different input, different rule sets, and in most pipelines, they run as separate stages entirely.
Does GitLab's built-in IaC scanning replace a dedicated tool like Checkov or Snyk?
For a lot of teams, yes, at least for baseline coverage. GitLab's scanning runs KICS, the same engine covered in this article's open-source category, so a team already on GitLab gets real scanning without adding anything new.
What GitLab's Free and Premium tiers don't include is the merge-request integration and vulnerability report that Ultimate unlocks. Also, a dedicated tool may offer format-specific depth GitLab doesn't.
Does Stategraph replace a dedicated IaC scanner?
For baseline coverage, yes. Stategraph bundles Checkov and runs it automatically on state import, apply, and a schedule, so a team gets real scanning without wiring up a separate tool or CI step.
What it adds beyond that is graph context: every finding carries blast-radius data showing how many resources across how many states depend on it, and stategraph tf plan shows which findings a change adds or resolves before it applies.
Teams that need compliance-framework mapping like CIS or SOC 2, or checks beyond what Checkov covers, may still want one of the dedicated scanners above alongside it.