Three tools have dominated pre-deployment IaC scanning conversations for years: Checkov, tfsec, and Terrascan. If you're revisiting this comparison in 2026, the picture looks different. Two of the three have stopped active development. The comparison that matters now is Checkov versus Trivy.

Checkov, maintained by Palo Alto Networks (Prisma Cloud), is at v3.2.526 and ships multiple releases per month. Trivy, from Aqua Security, absorbed the entire tfsec check library and now handles IaC scanning alongside container images, filesystem analysis, and Kubernetes auditing. tfsec still works, but Aqua has been clear: no new features are coming. Terrascan was officially archived by Tenable in November 2025.

If you're standing up a new IaC security pipeline or evaluating your current one, those facts matter more than the feature matrix that circulated three years ago.

At a glance Infrastructure as Code (IaC) security scanning analyzes Terraform, Kubernetes, CloudFormation, and other configuration files for misconfigurations before they deploy. As of May 2026: Checkov v3.2.526 (Palo Alto Networks, April 2026) and Trivy v0.70.0 (Aqua Security, April 2026) are the actively maintained open-source options. tfsec is deprecated (no new features; all checks migrated to Trivy). Terrascan was archived November 20, 2025 and is now read-only.

This post is part of a series on IaC scanning tools. Explore the full guide:

• What is an IaC scan tool?
• What is Checkov?
• What is tfsec?
• What is Terrascan?

What happened to tfsec and Terrascan

tfsec was the fastest Terraform-specific scanner. For teams with straightforward HCL pipelines, it was the obvious choice: simple to install, fast to run, and accurate enough for common misconfigurations. That's still true about the existing version. What changed is that Aqua Security merged all tfsec checks into Trivy in 2024 and explicitly redirected development there. The tfsec repository now shows "tfsec is now part of Trivy" at the top. No new checks are being added. Terraform features released after the merge aren't covered. For existing pipelines that depend on it, tfsec keeps running. For anything new, the path is Trivy.

The migration is a one-command change. Every tfsec check ID (for example, AVD-AWS-0086) works unchanged in Trivy, so findings map directly to any existing compliance baseline without manual re-mapping.

Terrascan took a different path. Tenable maintained it as an OPA-powered scanner covering Terraform, CloudFormation, Kubernetes, and ARM templates. The last release, v1.19.9, came out in September 2024. Tenable archived the repository on November 20, 2025; it is now read-only. That means no security updates, no new cloud provider API support, no fixes for newly identified CVEs.

Existing Terrascan pipelines continue to run. But a scanner frozen at a November 2025 snapshot of cloud security knowledge is degrading in coverage over time, because the cloud providers are not.

Related reading: What is an IaC scan tool?. Background on how pre-deployment scanning fits into an IaC security strategy before choosing a specific tool.

Checkov in 2026

Checkov is at v3.2.526 as of April 2026, maintained by Palo Alto Networks under the Prisma Cloud umbrella. It ships multiple releases per month. For context: Checkov is open source under Apache 2.0 and fully free regardless of whether you use Prisma Cloud commercially. Adoption doesn't create platform lock-in.

Version 3.x includes more than 1,000 built-in policies, including 800+ graph-based cross-resource checks. The graph analysis is the feature no other open-source scanner matches. A Checkov graph check can verify that an S3 bucket's access logging destination actually exists and is correctly configured: not just that the logging block is present, but that the target bucket exists and is in the same region. It validates relationships between resources, not just individual resource configurations in isolation.

Compliance framework mapping is a practical differentiator for teams with formal requirements. Checkov maps findings to CIS, SOC 2, HIPAA, PCI DSS, and NIST. Instead of manually tagging which policy violations affect your SOC 2 scope, Checkov outputs that categorization directly. For a security team that needs to report against a framework, that's meaningful reduction in manual work.

Custom policies are written in Python or YAML. The YAML option is worth knowing: it lets non-engineers author and maintain organizational standards without writing code. When the people who understand what a misconfiguration means in your environment are security engineers rather than platform engineers, YAML policies lower the barrier to getting their knowledge into the scanner.

Format coverage: Terraform, CloudFormation, Kubernetes (including Helm and Kustomize), Docker, Ansible, ARM Templates, Bicep, Serverless Framework, and OpenAPI. If your infrastructure spans multiple formats, Checkov handles the scope in a single scan.

One honest tradeoff: graph-based analysis adds scan time on large repositories. At 1,000+ resources, a full Checkov scan can take 2–4 minutes in CI without caching. The Checkov GitHub Action supports caching via actions/cache, worth configuring early if you're running it on a large monorepo.

env zero runs Checkov natively inside Composable Workflows. Compliance-mapped findings are part of the deployment audit trail rather than a separate CI artifact that someone has to check separately after a run.

Trivy in 2026

Trivy is at v0.70.0 as of April 2026. The IaC scanning capability (invoked as trivy config) inherited the full tfsec check library and has expanded from there. Trivy scans Terraform, CloudFormation, Kubernetes manifests, Helm charts, Dockerfile configurations, and Azure Bicep templates.

What Trivy does that Checkov doesn't: container image analysis, filesystem scanning for vulnerabilities and secrets, SBOM generation, and live Kubernetes cluster auditing. For teams that want one tool spanning the entire pipeline from IaC code to running cluster, Trivy is the practical choice. One binary, one CI job, one set of results covering IaC misconfigurations and outdated container base images in the same output.

The IaC scanning in Trivy is the same engine Aqua uses in their commercial security platform, so the check library receives regular updates tied to a commercial support commitment. The coverage isn't as deep as Checkov on cross-resource graph analysis; Trivy focuses on individual resource misconfiguration rather than dependency relationships between resources.

One honest note: Trivy's false-positive rate on IaC scanning is higher than Checkov's on certain cloud provider rules. During initial rollout, start with severity: 'CRITICAL,HIGH' only, review the baseline, then expand. Running with every severity enabled out of the gate tends to generate enough noise that teams add suppressions wholesale rather than fixing findings selectively.

A note for tfsec users: replace tfsec . with trivy config .. All check IDs are preserved, and findings from your existing baseline map directly to Trivy's output. The official migration guide covers output format differences and flag renames. Most teams complete the migration in under a day.

Related reading: The ultimate guide to Terraform drift detection. Pre-deployment scanning catches misconfigurations before they deploy. Drift detection catches what changes after, covering the changes that bypass the pipeline entirely.

Checkov vs Trivy: the 2026 comparison

The comparison is less "which is better" than "which surface are you prioritizing." Checkov wins on IaC depth, compliance reporting, and cross-resource logic. Trivy wins on breadth across the full pipeline from code to running cluster. env zero supports both in Composable Workflows, so the choice doesn't constrain which platform you run.

How to choose

Choose Checkov

Checkov is the right call when compliance reporting is a hard requirement. SOC 2, HIPAA, PCI DSS, and NIST are first-class outputs, not derived after the fact. It's also the better choice when your IaC spans many formats (Ansible, Bicep, OpenAPI, and Serverless alongside Terraform), or when you need graph-based cross-resource checks that validate whether referenced resources actually exist with the expected configuration. No other open-source scanner does that.

env zero's policy engine supports Checkov natively. Compliance-mapped findings flow into the deployment audit trail as part of Composable Workflows, so audit evidence is automatic rather than assembled manually after the fact.

Choose Trivy

Trivy is the better fit when your pipeline already runs container scanning and you want one tool rather than two. The breadth is genuine: IaC misconfigurations, container vulnerabilities, secrets in filesystems, and live Kubernetes cluster auditing all come from the same binary.

If you're migrating from tfsec, Trivy is the direct path. Same check IDs, same findings, one command change. If your team writes policies in Rego from Terrascan or OPA, Trivy accepts them for custom IaC policies.

Run both

Checkov and Trivy have non-overlapping check sets. Running both as parallel CI jobs catches more than either alone, and since both complete in seconds, the wall-clock cost is minimal. env zero supports both in the same Composable Workflow, so you don't have to choose at the platform level.

If you're on Terrascan

Checkov is the cleaner replacement for built-in check coverage. Trivy is the more direct path if you're preserving existing Rego policies.

The short version for most teams: Start with Checkov as your default IaC scanner. Add Trivy if you also need container image scanning in the same pipeline. If you're migrating from tfsec, go straight to Trivy and you'll be done in a day.

Related reading: Using Open Policy Agent with Terraform. If you're migrating from Terrascan and want to preserve Rego-based policies, this covers the OPA-as-Terraform-policy-engine pattern in detail.

Migrating from tfsec to Trivy

Aqua designed the tfsec-to-Trivy migration to be drop-in. The interface change is minimal:

# Before
tfsec .

# After
trivy config .

All tfsec check IDs (prefixed AVD-) carry over unchanged. If your CI configuration parses specific check IDs from tfsec output, those IDs appear verbatim in Trivy's output. The main differences are flag names: tfsec's --format options have slightly different names in Trivy. The official migration guide documents every flag change.

For GitHub Actions, replace the tfsec action with:

- name: Scan IaC with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    scan-type: 'config'
    hide-progress: false
    format: 'table'
    exit-code: '1'
    ignore-unfixed: true
    severity: 'CRITICAL,HIGH'

Set exit-code: '0' during the migration to surface findings without blocking PRs while your team reviews the baseline. Flip to '1' once critical findings are resolved.

Migrating from Terrascan

Terrascan's built-in policies and OPA/Rego custom rule support are both reproducible in Checkov or Trivy, depending on which path fits your pipeline.

For teams that relied primarily on Terrascan's built-in checks, Checkov covers the same IaC formats with broader format support and active maintenance. The Terrascan check library is still visible in the archived repository; you can map those policies to Checkov equivalents using the Checkov policy index.

For teams that built custom Rego policies in Terrascan, Trivy is the more direct replacement. The Rego syntax and OPA evaluation model are the same; the interface for loading custom policies differs. Running Trivy alongside your existing Terrascan setup for one sprint before removing Terrascan from the gate is a low-risk transition.

Migration checklist:

1. Inventory which Terrascan checks were actually blocking (not just informational).
2. For built-in checks: map them to Checkov or Trivy equivalents.
3. For custom Rego policies: transfer to Trivy's custom policy directory.
4. Run the replacement scanner alongside Terrascan for one sprint, compare outputs, then remove Terrascan.

Setting up a CI/CD gate

A minimal GitHub Actions workflow for a Checkov PR gate:

name: IaC security scan
on: [pull_request]

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Checkov IaC scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: .
          framework: terraform
          soft_fail: false
          output_format: github_failed_only

Use soft_fail: true while establishing the findings baseline, then flip it once critical findings are resolved. The github_failed_only output format keeps PR annotations readable.

For Trivy on the same pattern:

name: IaC security scan
on: [pull_request]

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Trivy IaC scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'config'
          format: 'table'
          exit-code: '1'
          severity: 'CRITICAL,HIGH'

If you run both in the same workflow, define them as parallel jobs. Total CI time stays roughly the same as running one scanner since both complete in seconds on standard infrastructure codebases.

Related reading: How policy-as-code enhances infrastructure governance with OPA. The upstream enforcement pattern that sits above scanner gate results in a mature IaC security program.

How env zero centralizes IaC security

Running Checkov or Trivy in CI catches misconfigurations. The harder problem at scale is that individual teams configure them differently. One team runs strict rules. Another added soft_fail: true last quarter because a release was blocked and never flipped it back. A third team skipped the scanner entirely during an incident and nobody noticed. The tooling is correct; the enforcement is inconsistent.

env zero solves this at the workflow level. Composable Workflows are YAML-defined pipeline templates that you define once and apply across all environments and teams. Checkov and Trivy run inside them as required gates, not optional CI scripts that teams inherit and configure independently. Every deployment passes through the same policy checks. Every result is logged. Without this, consistent enforcement across 10 teams means maintaining 10 separate CI configurations with no visibility into whether any of them are actually equivalent.

Ready-to-Use Policies give teams a starting baseline without writing policy logic from scratch: security, compliance, cost, and operational checks that activate immediately. For teams migrating from Terrascan, env zero's policy engine accepts Rego, so existing custom rules carry forward without rewriting.

The biggest gap most scanners leave is remediation. Finding a misconfiguration and creating a Jira ticket is not fixing a misconfiguration. Code Optimizer generates the fix as a pull request. The loop closes inside Git rather than in a ticketing system that someone has to act on separately.

Pre-deployment scanning only covers what goes through the pipeline. Automated drift detection covers the rest: the console change at 2am, the resource that predates your IaC coverage, the break-glass modification nobody documented. Checkov and drift detection are different layers of the same security program, not alternatives.

RBAC and encrypted state management sit alongside scanning, covering the credential and access risks that no IaC scanner addresses.

Related reading: 8 Terraform drift detection tools enterprise teams use in 2026. How drift detection extends the coverage that static scanning establishes, covering changes that bypass the pipeline.

Try it with env zero

Checkov and Trivy give you the detection layer. env zero adds consistent enforcement across every team, a full audit trail, and Code Optimizer to close the gap between finding a misconfiguration and fixing it in Git. You can wire Checkov into env zero using a ready-made workflow template and see results against your own Terraform in a free trial.

Start a free trial or book a demo. See also: Checkov and env0: shift-left IaC security in your CI/CD.

References

• Checkov GitHub: releases
• Trivy documentation: IaC scanning (Aqua Security)
• tfsec repository, now part of Trivy
• tfsec to Trivy migration guide
• Terrascan repository (archived November 2025)
• Checkov policy index: Terraform
• Spacelift: top Terraform scanning tools (2026)
• Infrastructure as Code 101

FAQ

Is tfsec still being maintained in 2026? No. Aqua Security merged the tfsec check library into Trivy in 2024 and redirected all development there. tfsec continues to function for existing installations, but no new checks are being added and Terraform features released after the merge aren't covered. For new pipelines, use trivy config instead.

Is Terrascan safe to use after being archived? Existing Terrascan pipelines continue to run and won't break immediately. The risk is coverage decay: a scanner frozen at November 2025 doesn't cover new cloud provider APIs, new CVEs, or changes in cloud service behavior since that date. For production pipelines where security coverage matters, plan a migration to Checkov or Trivy.

What replaced Terrascan? Checkov is the cleaner replacement for teams that used Terrascan's built-in checks. Trivy is the more direct replacement for teams that built custom OPA/Rego policies in Terrascan, since Trivy accepts Rego for custom IaC policies and the policy syntax carries forward without rewriting.

Can I run Checkov and Trivy together in the same pipeline? Yes. Both are fast, both output to SARIF and JUnit formats, and they have non-overlapping check sets. Running both catches more misconfigurations than either alone. Define them as parallel jobs in CI to avoid adding wall-clock time. This setup is appropriate when the additional coverage justifies the CI complexity.

Does any of this affect OpenTofu users? No. Checkov and Trivy both support OpenTofu configurations, since OpenTofu uses the same HCL syntax as Terraform. Verify specific feature support in each tool's documentation for newer OpenTofu syntax, but moving from Terraform to OpenTofu does not require changing your scanner.

What's the difference between Checkov and Trivy for cross-resource checks? Checkov's graph-based analysis validates relationships between resources. For example, a graph check can verify that the S3 bucket referenced in an access logging policy actually exists and is correctly configured as a log destination. Trivy's IaC scanning checks individual resources and does not perform cross-resource graph analysis. If cross-resource policy depth matters for your compliance requirements, Checkov is the better fit.

How does env zero handle Checkov and Trivy in deployment pipelines? env zero runs both natively in Composable Workflows. Checkov and Trivy policy gates are part of the deployment flow rather than standalone CI jobs, which means every deployment goes through the same policy checks and results are logged to the audit trail. Teams migrating from Terrascan can carry existing Rego policies forward since env zero's policy engine accepts Rego alongside Checkov's Python and YAML policy formats.