Checkov vs Trivy vs Terrascan in 2026

Imagine a security team that runs tfsec against its Azure Terraform repository, gets 12 findings, fixes them, and merges with confidence. Two weeks later, Microsoft Defender for Cloud flags a storage account that allows anonymous blob reads. The scanner they trusted had stopped receiving new checks, and nobody on the team knew.

That scenario is illustrative, but the gap is real. The IaC scanning landscape moved, and a comparison written even a year ago can mislead you. Before you pick a scanner, you need to know which of these tools still receive updates at all.

Which Terraform security scanners are still maintained in 2026?

Checkov and Trivy are actively maintained, tfsec now lives inside Trivy, and Terrascan is archived. Pick between Checkov and Trivy for a new pipeline, and treat Terrascan as a migration task.

Check each project's releases page for current version numbers before you pin anything, because both active tools ship frequently.

How do the scanners differ in what they scan?

Static IaC scanning reads your .tf files, or a terraform plan JSON, and checks resource configuration against a ruleset before anything reaches a cloud account. The scanners differ in breadth and in how you extend them.

• Checkov is focused on IaC. It covers Terraform, CloudFormation, Kubernetes, ARM, Helm, and Serverless, and its Python and YAML custom checks include graph-based rules that reason across resources.
• Trivy is a general scanner. One binary covers IaC (trivy config), container images, filesystems, and Kubernetes. It has fewer IaC-specific policies than Checkov and lacks graph-based cross-resource checks, but custom policies use Rego.
• KICS is a third active option you may meet. It is an open-source scanner with a large query library and is a reasonable alternative if neither of the two above fits.

What changed with the tfsec-to-Trivy merger?

tfsec's rules now live inside Trivy, and the standalone tfsec repository points users to it. The merge began in 2023, but plenty of pipelines still call tfsec directly, which is the real 2026 problem: the old command works, yet new coverage lands only in Trivy.

Every tfsec check ID, for example AVD-AWS-0086, works unchanged inside Trivy. That means existing findings and compliance mappings carry over without a rule rewrite. If your CI parses tfsec's flags or output format, budget a small config update because Trivy's equivalents differ slightly.

📌 Remember: Pin the scanner version instead of using latest. A known regression in Trivy v0.60.0 caused panics on some Terraform configurations, and an unpinned image would have broken every pipeline overnight.

What happened to Terrascan?

Tenable archived Terrascan on November 20, 2025, and the repository is now read-only. It still runs, but nothing behind it is changing: no CVE fixes, no rule updates, and no coverage for new cloud resource types.

Terrascan's OPA/Rego engine was genuinely differentiated. Teams could reuse one policy language across Kubernetes admission control and Terraform scanning, and it shipped a drift-detection feature. That does not offset an archived repository. Treat it like any unmaintained dependency: acceptable for a short migration window, a growing liability after that. Teams that valued Rego can keep it with Trivy (Rego custom policies) or Open Policy Agent directly.

How does a real misconfiguration look in each scanner?

Both tools catch the classic mistakes, such as public storage, and report them with a check ID, a file, and a line number. Here is the storage account from the opening scenario, in a form both Checkov and Trivy will flag, followed by the fixed version:

When a finding is a genuine exception, suppress it inline with a reason so a reviewer can see the decision:

Trivy uses the same idea with ## trivy:ignore:AVD-AWS-0086 placed on the line above the resource. Review suppressions in pull requests, or they quietly become permanent blind spots.

How should you layer scanners in a pipeline?

A mature pipeline runs scanners at different stages instead of relying on one gate. Fast, narrow checks run on the developer's machine, a broader gate runs before merge, and a runtime control catches drift after deploy.

The commands for each stage:

Scanning the plan JSON matters because variables, modules, and conditionals are already resolved, so the scanner sees what will actually be applied. Both tools can emit SARIF (checkov -o sarif, trivy config -f sarif -o results.sarif) for GitHub or GitLab code scanning. If you use the Checkov GitHub Action, pin it to a release tag and not master.

Trade-offs and Alternatives

Choose on coverage and extensibility, not on which logo you prefer.

Checkov's breadth and cross-resource graph checks make it the stronger default when your repository mixes Terraform with Kubernetes manifests or CloudFormation: one CLI, one policy library, and one report format. Trivy earns its place as the fast gate, especially for teams already using it for container image scanning, since one binary then covers both jobs.

For runtime, an IaC scanner is the wrong tool. Admission controllers such as OPA Gatekeeper or Kyverno enforce policy on live Kubernetes resources, and cloud-native tools (Defender for Cloud, AWS Config, Security Command Center) catch drift after deploy.

Production Implementation Guidelines

For a new Terraform security pipeline started today, do not adopt Terrascan, because its archival means no future coverage for new AWS, Azure, or GCP resource types. Do not adopt standalone tfsec either. Move directly to trivy config.

For teams subject to PCI DSS or RBI requirements, run Checkov in CI as the policy gate and Trivy pre-commit for fast iteration. The two are complementary: one catches issues before a developer opens a pull request, the other catches what the first gate missed. A scanner helps you evidence controls, but passing it does not certify compliance, so map findings to your own control framework.

If you have existing Terrascan pipelines, plan a migration window instead of an emergency rip-and-replace. Run Checkov or Trivy alongside Terrascan for a sprint, compare findings, port any custom Rego policies, then remove Terrascan.

Finally, fail the build on HIGH and CRITICAL findings only at first. Teams that start with every severity blocking usually end up disabling the scanner, which is worse than no scanner.

Note

References and Further Reading

• Trivy Documentation - IaC scanning and tfsec migration guide
• Checkov Documentation - Policy library and CI/CD integration
• tfsec repository - Transition notes pointing to Trivy
• Terrascan repository - Archived by Tenable in November 2025