Migrating off Terrascan

Last Updated on September 5, 2026 by Arnav Sharma

Terrascan sat in a lot of CI pipelines for years as the quiet gate that scanned Terraform, Kubernetes, and CloudFormation before anything reached a cloud account. That era is over. Tenable archived the tenable/terrascan repository on 20 November 2025, and the project is now read-only, with no further releases, issues, or pull requests accepted. If you are running it in production, migrating off Terrascan is no longer a backlog item you can defer to next quarter. This guide walks through what changed, how to choose a replacement, and how to swap the tool out of your workflow without breaking the build.

The advice here comes from having actually run these scanners in anger across mixed cloud estates, not from a feature matrix. The tools that replace Terrascan behave differently in subtle ways, and the migration that looks trivial on a slide can stall for a week when your custom policies do not port cleanly. The goal is to get you to a maintained scanner with equivalent or better coverage, while preserving the parts of your setup that were working.

Why Terrascan reached the end of the road

Terrascan started at Accurics, was acquired by Tenable in 2021, and grew into a Cloud Native Computing Foundation project with more than 500 out-of-the-box policies. It leaned on the Open Policy Agent engine, so teams could write custom checks in the Rego query language, and it covered a wide spread of formats: Terraform, Kubernetes, Helm, Kustomize, Dockerfiles, and AWS CloudFormation. It was free under the Apache 2.0 license and slotted into GitHub Actions, GitLab CI, Jenkins, and pre-commit hooks. For a stretch it was a reasonable default.

Tenable’s commercial attention moved to Tenable Cloud Security, its broader cloud-native application protection platform. The final Terrascan release was v1.19.9 in September 2024. Terrascan reached end of service on 30 September 2025 and was pulled from all Nessus versions, and the GitHub repository followed into archive status on 20 November 2025. Tenable now points users toward Tenable Cloud Security for infrastructure as code scanning going forward.

What “archived” actually means for your pipeline

An archived repository does not stop working. Your existing Terrascan binary still runs, still parses your Terraform, and still emits the same violations it did last year. The problem is slower and more corrosive than a hard break.

A scanner frozen at a November 2025 snapshot of cloud security knowledge degrades in coverage every month, because the cloud providers do not freeze with it. New provider resource types, new API surfaces, and newly disclosed misconfigurations simply fall outside what the tool knows to check. The software still runs, but it is no longer maintained software, and no security updates will land. Around 500 Rego policies shipped at the point of archival, and that number is now fixed. Treat the frozen CLI as a reference implementation rather than a control you can rely on for current risk, and remember that any policy data it references is equally static. That is the core reason migrating off Terrascan matters: the tool is not broken today, but the gap between what it checks and what you actually deploy widens continuously.

Migrating off Terrascan starts with a capability inventory

Before you select a replacement, catalogue what your current scan genuinely does. Most teams inherited a Terrascan configuration years ago and have never audited which of its features they depend on. Porting blindly to a new tool either drops coverage you needed or drags along configuration you never used.

Map what your current scan actually covers

Pull your Terrascan invocation apart and write down each capability in use. The command usually looks something like terrascan scan -i terraform -t aws -o sarif -d ., where the flags define the input type, the cloud target, the output format, and the directory to scan. Work through this checklist:

• Which IaC formats you actually feed it (Terraform only, or Kubernetes and CloudFormation too).
• Whether you use the bundled policies, custom Rego, or both.
• Whether you run the Kubernetes admission controller for runtime enforcement.
• Whether you use the container image vulnerability lookup via the registry integration.
• Which output your CI consumes (human, json, yaml, xml, or sarif).
• Any in-file skip instrumentation or config-file policy suppression you rely on.

This inventory is the input to every decision that follows. Doing it as a manual review of your own pipeline, rather than trusting an assumption about what the scan covers, is the point. A team that only ever scanned Terraform HCL with the built-in ruleset has a trivial migration. A team leaning on custom Rego and the admission controller has real work ahead, because that scan data and the processing logic behind it both have to move.

Choosing a replacement: Checkov, Trivy, or KICS

Three maintained open-source scanners cover the ground Terrascan used to. There is no single correct answer; the right target depends on the inventory you just built. The table below compares them on the axes that matter for a Terrascan migration.

Consideration	Checkov	Trivy	KICS
Maintainer	Palo Alto Networks (Prisma Cloud)	Aqua Security	Checkmarx
Built-in policies	1,000+ Terraform policies, ~800 graph-based cross-resource checks	~1,500 rules (inherited from tfsec)	2,400+ Rego queries across 22+ platforms
Custom policy language	YAML and Python	Rego	Rego
Framework breadth	Terraform, Kubernetes, Helm, CloudFormation, ARM, Serverless, more	Terraform, CloudFormation, ARM, Helm, plus containers, secrets, K8s	22+ IaC platforms
Standout strength	Graph-based cross-resource analysis	One binary for IaC, containers, and secrets	Widest raw format coverage
Best fit	Terraform depth, replacing built-in coverage	Preserving Rego, consolidating container scanning	Mixed IaC estates, Rego familiarity

Each tool maps to a different Terrascan usage profile. The sections below match them to the inventory categories.

If you relied on built-in policy coverage

Most Terrascan deployments used the bundled 500-odd policies and never wrote a line of custom Rego. For that profile, Checkov is the closest functional replacement. It covers the same Terraform and Kubernetes ground with a substantially larger policy library, it is maintained under the Prisma Cloud umbrella with multiple releases a month, and its command-line interface is free with no scan limits.

The headline capability Terrascan never had is graph-based analysis. Checkov builds a graph of your resources and validates cross-resource properties: it can confirm that an instance’s security group, in a specific subnet, in a specific virtual private cloud, is configured correctly as a chain rather than checking each attribute in isolation. No Rego-based scanner reproduces that. If your risk model includes relationships between resources, this alone can justify the move.

If you invested in custom Rego

Teams that wrote custom OPA policies for Terrascan face the portability question head-on. Rego does not port to Checkov’s YAML or Python formats for free; you rewrite that logic. If preserving your Rego investment is the priority, Trivy is the more direct path. Trivy accepts Rego for custom infrastructure as code policies, so the policy language carries forward with adjustments rather than a full rewrite.

Trivy brings a second advantage. It is a single binary that scans IaC misconfigurations, container images, filesystem secrets, and live Kubernetes clusters. Teams that ran Terrascan for IaC and a separate scanner for containers can consolidate to one tool. Trivy absorbed the entire tfsec check library, so its misconfiguration coverage is mature and actively maintained.

If you need the Kubernetes admission controller

Terrascan’s ability to act as a Kubernetes admission controller, blocking non-compliant resources at deployment time, was one of its more distinctive features. If you depended on it, none of the three static scanners is a drop-in for that specific runtime-enforcement role. Plan to replace it with a purpose-built admission tool such as an OPA Gatekeeper or Kyverno deployment, and keep the static IaC scan as a separate pre-deployment gate. Conflating the two is the most common way this migration goes wrong.

Porting your policies and custom rules

Policy portability is where migration timelines slip. Budget for it explicitly rather than discovering the gap mid-cutover.

If you move to Checkov, your custom Rego becomes custom Checkov policies. Simple attribute and connection checks translate cleanly into Checkov’s declarative YAML, which handles the majority of common custom rules. More complex logic that needs programmatic control moves into Checkov’s Python policies. A representative Checkov YAML custom policy defines an id, a name, a category, a description, the resource types in scope, and a condition block, and it reads far more like configuration than code. To move an existing rule you export the intent of the Rego check, then modify the structure to fit Checkov’s schema.

If you move to Trivy or KICS, your Rego largely survives. Both accept Rego, so the policy logic is preserved and you adjust the evaluation context rather than rewriting from scratch. This is the single biggest reason a Rego-heavy team should look hard at Trivy before defaulting to Checkov.

Whichever target you choose, do not migrate policies you no longer need. The inventory step exists partly to let you retire dead rules. A migration is the cleanest opportunity you will get to prune the ruleset, and carrying forward suppressions and skips that no longer apply just imports old debt into a new tool.

Swapping the CLI and CI/CD commands

Once the target tool and policy plan are settled, the mechanical swap is the easy part. The pattern is the same across CI systems: replace the Terrascan command, update the action or container image reference, and confirm the output format your downstream jobs consume still parses.

Task	Terrascan	Checkov	Trivy
Scan a directory	terrascan scan -i terraform -d .	checkov -d .	trivy config .
Emit SARIF for code scanning	terrascan scan -o sarif -d .	checkov -d . --output sarif	trivy config --format sarif .
Target a cloud provider	terrascan scan -t aws -d .	policy selection via config	config-level rule selection
Initialise or update policies	terrascan init	bundled, auto-updated per release	bundled, auto-updated per release

A few practical notes on the swap. If a pipeline still calls the old binary on a runner that no longer has it installed, the job fails outright, so grep your CI configuration for every Terrascan invocation before you flip the switch rather than after. Where you scan matters as much as which tool: running the scanner against static HCL catches a class of issues, but running Checkov against a Terraform plan file in JSON catches misconfigurations that only appear once variables, modules, and data sources resolve. The plan-based scan does its processing on data that has been fully resolved, so it reflects what will actually deploy. Many mature teams run a fast static scan on every pull request for quick feedback, then a deeper plan-based scan after merge before apply. Let the scanner generate its findings automatically in CI rather than relying on anyone to run it manually.

For KICS specifically, one 2026 caution applies. The KICS GitHub Action and Docker Hub images were affected by the TeamPCP supply-chain attacks in March and April 2026, so pin to verified image digests rather than floating tags such as latest. This is good hygiene for any pinned tool, but it is worth calling out explicitly here.

A staged migration workflow

Trying to cut over in a single pull request invites a bad afternoon. A staged workflow lets you build confidence before you remove the old gate. Run the process in this order:

1. Inventory the current Terrascan configuration and capabilities, as covered above.
2. Select the target tool against that inventory.
3. Stand up the new scanner in parallel, in non-blocking or soft-fail mode, so it reports findings without failing builds.
4. Reconcile the two result sets. Where the new tool flags something Terrascan did not, decide whether it is a genuine new finding or noise to suppress. Where Terrascan flagged something the new tool misses, that is a policy you need to port or rewrite.
5. Port and test custom policies against representative modules until the new tool’s output matches your intent.
6. Flip the new scanner to blocking mode and remove the Terrascan step in the same change, so there is never a window with two blocking gates fighting each other.

Running both scanners side by side during the reconciliation phase is the single most valuable step. It converts an abstract “do the results match” question into a concrete diff you can triage finding by finding, and it is how you catch the coverage gaps that a feature comparison never surfaces. It also lets you manage the cutover as a controlled transition, handling each divergence on its own merits, so the new gate starts failing builds automatically only once you trust it.

Common migration mistakes to avoid

A handful of errors show up repeatedly when teams move off Terrascan. Each is avoidable with the inventory and staged rollout above.

• Treating the frozen Terrascan CLI as good enough indefinitely. It runs, but its coverage decays against a moving cloud, and a passing scan means less every month.
• Assuming custom Rego ports to Checkov for free. It does not. If Rego portability matters, that alone can point you to Trivy or KICS.
• Dropping the Kubernetes admission controller silently. If you used it, replace the runtime-enforcement role deliberately rather than losing it in the shuffle.
• Cutting over in one blocking change with no parallel-run period. You lose the reconciliation diff that tells you what coverage actually changed.
• Carrying forward every legacy suppression and skip. A migration is your best chance to prune. Importing old exceptions into a new tool just relaunches old debt.
• Treating a passing scan as compliance. Default rule sets are a baseline, not your policy. Layer your organisation-specific rules on top deliberately.

Migrating off Terrascan is not difficult work, but it rewards a methodical approach. Inventory first, choose against that inventory, run in parallel, port policies with intent, then cut over cleanly. Do that and you land on a maintained scanner with coverage that keeps pace with the cloud, rather than a frozen tool quietly falling behind.