IaC security scanning tools: Practitioner’s guide to the 2026 landscape

Why IaC security scanning is non-negotiable in 2026

Infrastructure as code has transformed how organizations deploy cloud environments – and how attackers exploit them. A misconfigured S3 bucket in a Terraform file, an overly permissive IAM role in a CloudFormation template, or a publicly exposed Kubernetes service in a Helm chart reaches production just as quickly as correct code.

The risks are real. The Cloud Security Alliance ranked misconfiguration and inadequate change control as the top cloud threat in 2024, up from third place in its previous report. The compromise of the tj-actions/changed-files GitHub Action in March 2025, affecting over 23,000 repositories and exposing CI/CD secrets in workflow logs, demonstrated that the pipelines deploying your infrastructure are themselves a target. The Trivy supply chain compromise in March 2026 (more on that below) extended the same lesson: the tools scanning your infrastructure are themselves an attack surface.

IaC security scanning tools address the misconfiguration problem by catching issues before they reach production – analyzing Terraform, CloudFormation, Kubernetes manifests, Helm charts, and Dockerfiles against security policies during development and in CI/CD pipelines. This guide compares the leading tools, covers honest maintenance status, and explains the integration patterns that make IaC scanning effective at scale.

IaC security scanning tools analyze infrastructure-as-code configuration files – Terraform HCL, CloudFormation YAML/JSON, Kubernetes manifests, Helm charts, Bicep, ARM templates, Ansible playbooks, and Dockerfiles – for security misconfigurations, compliance violations, and exposed secrets before that infrastructure is deployed. They perform static analysis of configuration code against policy libraries (CIS Benchmarks, NSA-CISA guidelines, NIST controls, or custom OPA/Rego policies), and integrate into CI/CD pipelines to fail builds on critical violations before insecure infrastructure reaches production.

How IaC security scanning works – the two main approaches

Before evaluating specific tools, it helps to understand the architectural divide that shapes the entire tool landscape: pre-deployment static scanning versus live environment scanning:

• Pre-deployment static scanning analyzes IaC configuration files before they are applied to infrastructure – in a developer’s editor, on a pull request, or in a CI/CD pipeline before terraform apply or kubectl apply. This approach catches misconfigurations at the point where they’re cheapest to fix: before any infrastructure exists.
• Live environment scanning (CSPM/drift detection) scans already-deployed cloud resources – existing S3 buckets, running Kubernetes clusters, deployed IAM policies – for misconfigurations and drift from the declared IaC state. It catches misconfigurations that bypassed pre-deployment scanning, resources provisioned outside IaC workflows, and manual changes that introduced configuration drift.

Most mature security programs use both approaches. Here’s an at-a-glance table showing differences between the two:

Open-source IaC security scanning tools

This section covers the major open-source tools along with their current maintenance status – the information practitioners actually need when choosing what to build pipelines around.

Checkov: The most widely used open-source IaC scanner

Checkov, maintained by Palo Alto Networks under the Prisma Cloud umbrella, is the de facto standard for open-source IaC security scanning. It ships more than 1,000 built-in policies covering Terraform, CloudFormation, Kubernetes, ARM templates, Bicep, Docker, Ansible, and more. One of Checkov’s more useful architectural decisions is its graph-based scanning: rather than evaluating each resource in isolation, it detects security issues across interconnected resources – a public S3 bucket attached to a Lambda execution role is flagged as a single compound finding rather than two separate issues.

Custom policies are written in Python or YAML, which keeps the learning curve manageable for teams without Rego experience. SARIF output feeds directly into the GitHub Security tab.

Best for: General-purpose IaC scanning across multiple frameworks; teams wanting maximum policy breadth without writing custom rules.

Frameworks supported: Terraform, CloudFormation, Kubernetes, ARM, Bicep, Ansible, Serverless, Helm, Docker, OpenAPI specs

Policy language: Python / YAML (custom checks)

License: Apache 2.0

Maintenance status (2026): Actively maintained; multiple releases per month

Usage examples:

# Basic Checkov scan of a Terraform directory
checkov -d /path/to/terraform/ --framework terraform

# Scan with severity-based filtering
checkov -d . --framework terraform --check HIGH,CRITICAL

# Output as SARIF for GitHub Security tab
checkov -d . --output sarif --output-file-path results.sarif

Trivy: Unified IaC, container, and Kubernetes scanning

Trivy (Aqua Security) began as a container vulnerability scanner and has grown into a comprehensive security tool covering filesystems, container images, Kubernetes clusters, and IaC templates in a single binary. That breadth is genuinely useful: teams running Trivy for container scanning can extend the same tool and the same CI/CD step to cover IaC without adding another dependency.

One important note on the broader tool landscape: tfsec, a once-popular dedicated Terraform scanner, was merged into Trivy’s IaC scanning mode (trivy config). Aqua has been clear that no new features are coming to tfsec. If your pipelines are running tfsec today, trivy config provides the same checks plus everything Trivy adds on top.

Best for: Teams wanting unified IaC, container, and Kubernetes scanning from a single tool; DevOps teams already using Trivy for container scanning.

Frameworks supported: Terraform, CloudFormation, Kubernetes, Bicep, Helm, Docker

Live cluster scanning: Yes – trivy k8s cluster scans a running Kubernetes cluster for misconfigurations

License: Apache 2.0

Maintenance status (2026): Actively maintained; supply chain incidents from March 2026 fully remediated

Usage examples:

# Scan Terraform configuration
trivy config ./terraform/

# Scan Kubernetes manifests
trivy config ./k8s/

# Scan a running Kubernetes cluster
trivy k8s cluster --report summary

# Scan with severity filter
trivy config --severity HIGH,CRITICAL ./terraform/

Note on supply-chain incidents: Trivy’s GitHub Actions and Docker Hub images were compromised by threat actor TeamPCP in March 2026 and subsequently remediated. Safe versions are trivy-action v0.35.0 and setup-trivy v0.2.6. See the SHA-pinning guidance in the CI/CD section below.

KICS: Widest IaC format coverage

KICS (Keeping Infrastructure as Code Secure), maintained by Checkmarx, supports more than 20 IaC formats – the widest format coverage in the open-source category – including Terraform, Pulumi, Ansible, CloudFormation, Kubernetes, Docker, and more. Its query engine is built on OPA/Rego, which is the right choice for teams that already use Open Policy Agent elsewhere and want to write custom security policies in a consistent language. The query catalog runs to more than 2,400 built-in checks.

KICS is actively maintained. Teams evaluating it should note that KICS is also the scanning engine within Checkmarx One, which provides the commercial support path if needed.

Best for: Teams needing the widest IaC format coverage, including less common formats like Pulumi; teams that write custom Rego policies.

Frameworks supported: Terraform, Kubernetes, CloudFormation, Bicep, Pulumi, Ansible, Docker, Helm, and 15+ additional formats

Policy language: OPA/Rego

License: Apache 2.0

Maintenance status (2026): Actively maintained; April 2026 supply chain incident remediated

Usage examples:

# Scan Terraform with KICS
kics scan -p ./terraform/ -o ./results/

# Filter by specific query IDs (use UUIDs from the KICS query catalog at docs.kics.io)
kics scan -p . --include-queries "e69890e6-fce5-461d-98ad-cb98318dfc96"

Note on supply-chain incidents: The KICS Docker Hub image and GitHub Action were compromised by the same threat actor (TeamPCP) in April 2026 and subsequently remediated. The same SHA-pinning mitigation applies – see the CI/CD section below.

Kubescape: Purpose-built Kubernetes security

Kubescape (ARMO, CNCF Incubating project) is purpose-built for Kubernetes security, covering manifests, Helm charts, and running clusters. The tool’s scope expanded significantly with Kubescape 4.0, announced during KubeCon + CloudNativeCon Europe 2026 in March, which brought Runtime Threat Detection to general availability. That puts Kubescape in the same conversation as Falco for runtime cluster monitoring, alongside its original shift-left scanning role.

Kubescape’s compliance coverage is Kubernetes-specific and thorough: CIS Kubernetes Benchmark, NSA-CISA Kubernetes Hardening Guide, MITRE ATT&CK for Kubernetes, and SOC 2 controls. Its RBAC analysis is particularly useful – identifying over-broad ClusterRoleBindings, service accounts with cluster-admin privileges, and unscoped permissions is exactly the kind of check that generic IaC scanners underserve.

Best for: Kubernetes-heavy teams needing deep RBAC analysis, CIS Kubernetes Benchmark coverage, and runtime threat detection in a single tool.

What Kubescape checks:

• Pod security: privileged containers, host path mounts, dangerous capabilities, missing security contexts
• RBAC: over-broad ClusterRoleBindings, service accounts with cluster-admin, unscoped permissions
• Network policy gaps and services exposed beyond intended scope
• CIS Kubernetes Benchmark, NSA-CISA hardening guide, MITRE ATT&CK for Kubernetes, SOC 2

License: Apache 2.0 (CNCF Incubating)

Maintenance status (2026): Actively maintained; 4.0 released March 2026

Usage examples:

# Scan local Kubernetes manifests
kubescape scan ./k8s-manifests/

# Scan running Kubernetes cluster
kubescape scan cluster

# Scan against specific framework
kubescape scan framework nsa ./k8s/

Prowler: Live cloud environment scanning

Prowler operates on already-deployed cloud resources across AWS, Azure, GCP, and Kubernetes rather than static IaC files. That distinction matters: Prowler’s job is finding drift between what IaC declares and what production actually looks like, and auditing resources provisioned outside IaC workflows entirely. Its check library covers CIS Benchmarks, PCI-DSS, HIPAA, NIST 800-53, SOC 2, and GDPR across all four cloud providers.

For teams running mature IaC pipelines, Prowler operates as the continuous validation layer – confirming that what pre-deployment scanning approved is still what production contains. Manual changes, console modifications, and infrastructure provisioned by other teams all show up in Prowler’s findings.

License: Apache 2.0

Maintenance status (2026): Actively maintained

Tools to avoid starting new pipelines with

Terrascan (archived): Tenable archived the tenable/terrascan GitHub repository on November 20, 2025. It is now read-only and accepts no further updates, issues, or pull requests. The last release, v1.19.9, shipped in September 2024. That means no security updates, no support for new Terraform language features, and no coverage of compliance benchmarks published after that date. Tenable’s commercial focus has moved to Tenable Cloud Security (CNAPP). If you’re running Terrascan, migrate to Checkov or Trivy. Do not start new pipelines on Terrascan.

tfsec (merged): Aqua Security has merged tfsec functionality into Trivy’s IaC scanning mode. tfsec receives no new features. If you’re using tfsec, migrate to trivy config – same checks, plus everything else Trivy adds: container scanning, SBOM generation, Kubernetes cluster scanning.

Commercial IaC security scanning tools

Snyk IaC: Focused on developer experience

Snyk IaC’s main strength is its integration into the broader Snyk platform. If you’re already using Snyk for software composition analysis (SCA), adding IaC scanning produces a unified developer-facing security view with consistent fix guidance across dependency and infrastructure findings. The IDE integration and inline remediation hints reflect Snyk’s developer-first design philosophy.

Supports: Terraform, CloudFormation, Kubernetes, ARM, Helm

Best for: Teams using Snyk for SCA who want unified developer-facing security; teams prioritizing developer experience over policy flexibility.

Pricing: Free tier available with limited monthly scans; commercial tiers for enterprise features.

Prisma Cloud: Enterprise CNAPP with IaC scanning

Prisma Cloud (Palo Alto Networks) wraps Checkov’s open-source engine with enterprise features: centralized policy management, compliance reporting, audit trails, and integration with the broader cloud-native application protection platform (CNAPP) suite. For teams already running Checkov open-source who need enterprise governance, compliance reporting, and centralized policy management, Prisma Cloud provides an upgrade path.

Wiz, Orca, Sysdig: CNAPP platforms with IaC scanning

Wiz, Orca Security, and Sysdig bundle IaC scanning as one component of a broader cloud security platform alongside CSPM, runtime protection, and container security. If IaC scanning is one requirement in a broader cloud security platform evaluation, these warrant consideration. If the specific requirement is IaC scanning depth and flexibility, evaluate them as platform decisions rather than scanner decisions.

IaC scanner selection guide – the two-tool pattern

The practitioner reality is that most teams run two tools, not one:

1. A fast linter for developer-facing feedback (TFLint for Terraform, kubeval for Kubernetes) – runs in seconds, catches syntax errors and basic configuration issues at PR time without blocking the workflow
2. A broader scanner in CI – runs deeper policy checks, CIS Benchmarks, and compliance frameworks before deployment

Here’s a decision matrix to help you with tool choice:

One important limitation all of these tools share: static IaC analysis catches misconfigurations in configuration code. It does not test whether those misconfigurations are actually exploitable in the deployed application. That gap is covered in the next section.

The layer IaC scanning alone misses: application security integration

IaC security scanning closes one critical layer of the attack surface: misconfigured infrastructure that would produce vulnerable cloud resources. But IaC scanning on its own has a clear structural boundary – it cannot test application behavior.

Consider two scenarios that static IaC analysis cannot catch:

• Scenario 1: Compliant infrastructure, vulnerable application. An S3 bucket is correctly configured – private, encrypted, no public access. The web application reading from it has a path traversal vulnerability that allows attackers to read arbitrary S3 keys. The infrastructure is perfectly configured. The application is vulnerable. Checkov and Trivy have no visibility into this: they scan the Terraform file, not the running application.
• Scenario 2: Correct IaC declaration, runtime drift. Terraform declares a security group restricting database access. A manual change in the AWS console opens a port that was never in the Terraform state. Pre-deployment IaC scanning cannot detect this – it scanned the Terraform file before the manual change occurred. Live environment scanning (Prowler, CloudSploit) would catch the drift. Dynamic application security testing (DAST) would confirm whether the now-exposed database is exploitable.

Closing both gaps requires an application security platform that operates across the full stack – one that can scan infrastructure code, test the running application, and correlate findings from both layers in a single risk view.

Invicti provides that solution. The Invicti Application Security Platform includes native IaC scanning as a pre-activated capability – no separate tooling or pipeline configuration required. It analyzes Terraform, CloudFormation, Kubernetes manifests, Helm charts, Dockerfiles, Ansible, and Pulumi files directly from within the platform, surfacing infrastructure misconfigurations alongside the DAST, SAST, SCA, container security, and secrets findings that make up a complete application security picture.

For teams that want IaC findings in their existing AppSec workflow rather than as a separate pipeline concern, this is the integration point: the same platform scanning the deployed application also scans the infrastructure code that deployed it.

For those already running Checkov, Trivy, KICS, or other scanners in CI, Invicti ASPM can also ingest those external findings. Rather than replacing an existing IaC scanner with Invicti, you can bring your IaC findings, wherever they come from, into the same risk view as your application security findings.

When an IaC finding flags an overly permissive IAM role, and a DAST finding confirms a server-side request forgery (SSRF) vulnerability in the application using that role, the ASPM layer surfaces both as a compound risk: the application vulnerability combined with the permissive IAM role produces a potential AWS credential exfiltration path that neither scanner would surface alone. That compound risk assessment is what neither a standalone IaC scanner nor a standalone DAST tool can provide – it requires both datasets in the same platform.

This is the coverage model that bridges the gap between cloud security (infrastructure team) and application security (development and AppSec team) – bringing both layers into a single risk management platform where findings are prioritized by actual compound risk rather than managed in separate dashboards.

Integrating IaC scanning into CI/CD – practical patterns

Supply chain security for IaC scanning actions

The Trivy and KICS supply chain compromises described above exploited a single vulnerability class: GitHub Actions and Docker Hub images referenced by mutable tags. When tags can be force-pushed to point at malicious commits, any pipeline using @master, @v1, or latest is exposed. The fix is to pin every action and container image to a full commit SHA – content-addressed references that cannot be moved:

# UNSAFE — mutable tag, the exact attack surface exploited in March 2026 
- uses: aquasecurity/trivy-action@master 
# SAFE — pinned to an immutable commit SHA 
- uses: aquasecurity/trivy-action@# e.g. commit SHA for v0.35.0

To get the correct SHA, navigate to the action’s releases page on GitHub and copy the full commit SHA for the release you want. Tools like StepSecurity’s Harden-Runner and OpenSSF Scorecard can automate auditing and pinning across all workflows in a repository. For Docker-based steps, use image digests (in the form of image: bridgecrew/checkov@sha256:<digest>) rather than tags.

The two-stage CI/CD pattern

Stage 1 – PR/commit (fast feedback):

# .github/workflows/iac-security.yml
name: IaC Security Scan

on:
  pull_request:
    paths:
      - '**.tf'
      - '**.yaml'
      - '**.yml'
      - 'Dockerfile*'
      - '**/k8s/**'

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@99bb2cabc06bd4285c27f95e00e4b2b6a9e1a3d  # v12.1347.0
        with:
          directory: .
          framework: terraform,kubernetes,dockerfile
          soft_fail: false  # Block PR on failures
          output_format: sarif
          output_file_path: results.sarif
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@45775bd8235c68ba998cffa5171334d58593da47  # v3
        with:
          sarif_file: results.sarif

Stage 2 – full scan before deployment:

  trivy-iac:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
      - name: Run Trivy IaC scan
        uses: aquasecurity/trivy-action@6e7b7d1fd3e4fef0c5fa8cce1229c54b2c9bd0d8  # v0.35.0
        with:
          scan-type: 'config'
          scan-ref: '.'
          severity: 'HIGH,CRITICAL'
          exit-code: '1'  # Fail pipeline on HIGH/CRITICAL
          format: 'sarif'
          output: 'trivy-results.sarif'

GitLab CI equivalent:

checkov:
  image: bridgecrew/checkov:latest
  stage: security
  script:
    - checkov -d . --framework terraform --output sarif --output-file-path gl-sast-report.sarif
  artifacts:
    reports:
      sast: gl-sast-report.sarif
  rules:
    - changes:
        - "**/*.tf"
        - "**/*.yaml"

Severity gating strategy

A consistent gating policy matters as much as the tools themselves. A reasonable default:

• Critical findings: block deployment (fail CI/CD, no override)
• High findings: block deployment, or require explicit override with written justification
• Medium findings: report but don’t block; track in issue tracker
• Low findings: informational only

Teams frequently start with soft-fail mode to baseline the existing finding volume before enabling hard failures. Building up to hard failures on Critical and High is more sustainable than starting with maximum enforcement and immediately generating exceptions for everything.

IaC scanner comparison – complete reference table

Conclusion: Scan the configuration, validate the whole application

IaC scanning tools are a non-negotiable first layer – catching misconfigurations in infrastructure code before they reach production, at the point where they’re cheapest to fix. But as the scenarios earlier in this guide illustrate, a clean IaC scan doesn’t mean a secure application: compliant infrastructure can still serve a vulnerable app, and a correct Terraform declaration can’t account for what someone changed in the console last Tuesday.

The teams getting the most out of IaC scanning are the ones who treat it as an input to a broader security program, not a destination. That means correlating infrastructure findings with application-layer results, validating misconfiguration exploitability at runtime, and prioritizing remediation based on compound risk – not managing a separate dashboard for every scanner in the pipeline.

Invicti includes IaC scanning as a built-in platform capability alongside DAST, SAST, SCA, container security, and secrets detection. Teams that also run dedicated IaC scanners in CI can bring those findings into the same platform, correlating external tool output with Invicti’s own results in the ASPM layer.

Next steps

• Read more about IaC security best practices
• See how Invicti’s built-in IaC scanning works and read the IaC docs
• Request a demo to see Invicti’s AppSec platform in action – including IaC scanning