On November 20, 2025, Tenable archived Terrascan — one of the three most-cited open-source Terraform scanners of the last five years — leaving its GitHub repository read-only with no further issues, pull requests, or releases. Teams that built CI gates around it now have to migrate, and Tenable's own guidance points them toward Checkov, Trivy, or KICS. That churn is a useful reminder of what actually matters in infrastructure-as-code (IaC) compliance: not which specific binary you run, but whether your pipeline evaluates the computed resource plan — not just raw HCL or YAML — against named CIS Benchmark and SOC 2 control IDs, before terraform apply or a CloudFormation deploy ever touches a real account. Checkov alone ships more than 1,000 built-in policies spanning Terraform, CloudFormation, Kubernetes, Helm, and Serverless. Open Policy Agent's Rego language backs Conftest, KICS, and Trivy's IaC engine alike, while HashiCorp Sentinel does the equivalent job natively inside Terraform Cloud and Enterprise. This piece walks through how to wire policy-as-code into a real pipeline so compliance failures block a merge instead of surfacing as a finding three weeks after the resource already exists.
Why scan the Terraform plan instead of the raw HCL?
Scanning the plan matters because raw HCL doesn't show you the resource Terraform is actually going to create — modules, provider defaults, and variable interpolation all resolve later. The standard pattern is terraform plan -out=tfplan, then terraform show -json tfplan > plan.json, then evaluating that JSON with a policy engine like Conftest. The JSON plan reflects every default value a module silently applies, so a policy checking "S3 buckets must have encryption enabled" catches a bucket that inherits encryption from a shared module just as reliably as one that sets it inline. Scanning source HCL directly, by contrast, can miss violations hidden behind variables that only resolve at plan time, and it can also false-positive on modules that look risky in isolation but are configured safely by the caller. This is why Rego-based tools (Conftest, KICS, Trivy) and Sentinel both standardize on the plan JSON as their unit of evaluation, not the .tf source tree.
Which tools actually remain viable after Terrascan's archival?
Checkov (maintained by Bridgecrew, part of Palo Alto Networks) and Trivy (Aqua Security) are the two open-source options actively developed for Terraform and CloudFormation scanning today. Aqua merged its earlier tfsec engine directly into Trivy and now recommends Trivy for all new adoption rather than a standalone tfsec install. Checkov supports custom rules written in YAML or Python and includes CIS-aligned and SOC 2-aligned check categories out of the box, covering both Terraform and native CloudFormation templates without a translation step. For commercial Terraform Cloud or Enterprise users, HashiCorp Sentinel provides the same pre-apply enforcement natively, evaluated as part of the run pipeline before any apply is permitted. KICS, from Checkmarx, is a Rego-based alternative that also scans both formats. Terrascan's archival doesn't mean projects using it stop scanning today — it means new adoption and long-term maintenance now sit with Checkov, Trivy, or KICS, per Tenable's own migration notice.
How do you map a scan result to an actual CIS or SOC 2 control?
You map it by writing or selecting policies keyed to a specific control ID, not a generic "security best practice" label, so a failure is auditable back to a named requirement during an audit. The CIS Amazon Web Services Foundations Benchmark, for example, includes specific numbered controls like requiring MFA for the root account and disabling public read access on S3 buckets by default — Checkov's built-in check IDs (its CKV_AWS_* series) map directly to many of these numbered CIS controls, and Rego policies in Conftest or KICS can be written the same way, one policy file per control. SOC 2 doesn't publish machine-checkable rules the way CIS does — it's audited against the AICPA's Trust Services Criteria — so mapping IaC checks to SOC 2 means grouping infrastructure controls (encryption at rest, logging enabled, network segmentation) under the specific Trust Services Criteria they support, then keeping that mapping in the policy repo so an auditor can trace a passing CI run back to a control claim.
What should hard-fail the pipeline versus just warn?
High-severity, control-mapped violations — a public S3 bucket, a security group open to 0.0.0.0/0 on a sensitive port, an unencrypted RDS instance — should hard-fail the pipeline and block merge, because these map directly to CIS control failures an auditor or attacker can both point to. Lower-severity or organization-specific conventions (missing resource tags, non-standard naming) are better run as advisory checks that report but don't block, so teams don't route around a strict gate out of frustration and disable the whole pipeline. Checkov, Conftest, and Sentinel all support this severity split natively — Conftest's Rego policies can emit deny rules (hard fail) separately from warn rules, and Sentinel has three enforcement levels (advisory, soft-mandatory, hard-mandatory) built for exactly this purpose. The discipline that matters is deciding the split in advance, against your named control set, rather than tuning it reactively after a noisy first rollout.
Where does this fit for teams already tracking SOC 2 or CIS at the GRC layer?
IaC policy gates catch the infrastructure-configuration half of a control; they don't replace the evidence-collection and audit-readiness work a GRC platform does across the rest of the environment. A pipeline that blocks a Terraform apply on an unencrypted S3 bucket is enforcing a control at commit time, but a SOC 2 Type II audit still needs continuous evidence that the control held over the entire audit period, across every system in scope, not just the ones that went through a Terraform pipeline. Safeguard's compliance platform scores organizations across 197 frameworks (SOC 2 Type II among them), continuously collecting evidence from connected integrations rather than requiring a point-in-time manual pull. Teams running Checkov, Conftest, or Sentinel gates on their IaC pipelines get a cleaner starting position for that broader evidence story — fewer infrastructure misconfigurations to explain away later — but the IaC gate and the GRC evidence layer are solving two different halves of the same compliance problem, and neither substitutes for the other.