vs Checkov & Trivy

Read this if you run Checkov or Trivy in CI today. You keep the scanner and its pipeline. Compliance.tf adds a layer in front of it: modules that arrive with the controls of the framework you picked, and a provider that checks hand-written aws_* resources before Terraform calls AWS. This page is for the platform lead who owns the Terraform standards and the security engineer who owns the controls.

Summary

Dimension	Compliance.tf	Checkov / Trivy
When it acts	`terraform init` (modules are served with controls) and `terraform plan` (module validations, provider checks)	CI scan of HCL or plan JSON, after the code is written
What it covers	Modules from the compliance.tf catalog, and hand-written `aws_*` resources through the provider	All Terraform resources, plus CloudFormation, Kubernetes, Dockerfiles and more
Hand-written resources	The compliance.tf provider for AWS checks them before apply; `soft_fail` warns by default, `hard_fail` fails the plan	Scanned like any other resource
Framework-specific enforcement	Yes: one registry endpoint per framework, controls mapped to clause IDs on the framework pages	Checkov checks link to guidelines, and its framework mappings live in its commercial platform, Prisma Cloud; Trivy has `--compliance` reports for some benchmarks. The scan itself is the same whichever framework you report against
Sets the secure value	Yes, as a module default or validation	No: reports a finding for someone to fix
Operational rules (lifecycle, allowed regions, instance types)	Yes: download-time rules from an org Baseline or a named ruleset	Only as custom checks you write
Custom checks	No: controls are fixed per framework; turn individual controls on and off per module	Yes: Checkov custom checks in Python or YAML; Trivy custom checks in Rego
Exceptions	`?disable=` in the module `source` on a framework endpoint (reviewed in code); waivers with an expiry on a project environment	Inline skip comments or ignore files in the repository
Governance and evidence	Versioned snapshots per environment, approval before production, audit trail of posture changes	Scan results and CI logs; history is whatever your CI keeps
Licence and cost	Paid SaaS with a free trial; the provider's built-in CIS baseline is free	Open source (Apache 2.0); Checkov's commercial platform is Prisma Cloud

What each tool solves

Compliance.tf prevents a misconfiguration from being written for the resources it covers. A module served from soc2.compliance.tf already carries the SOC 2 controls: S3 encryption, access logging and a public access block are defaults or validations, so a non-conforming value fails at terraform plan. Resources you declare directly are checked by the provider before Terraform calls AWS.

Checkov and Trivy scan infrastructure as code. They read Terraform HCL or plan JSON and report findings against a library of built-in checks. They find problems before terraform apply, after the code exists.

Where compliance.tf is stronger

No finding to triage for covered controls. The module ships the required value, so the scanner has nothing to report for that control and nobody writes a fix.
No policies to write for covered controls. You change a source line and run terraform init. There is no custom check or .checkov.yaml to maintain for those controls.
The framework decides the control set. The same module interface serves a different set of controls per endpoint: soc2.compliance.tf for SOC 2, pcidss.compliance.tf for PCI DSS v4.0. Each control links to the clauses it maps on its framework page.
Org rules and governance come with it. Operational rules (prevent destroy, ignore tag changes, allowed regions) are applied at download time, and on a project environment the posture is a versioned snapshot promoted through an approval step and recorded in the audit trail.

Where Checkov and Trivy are stronger

Breadth. They scan every resource in the plan, including modules outside the compliance.tf catalog (terraform-aws-notify-slack, terraform-aws-atlantis) and resource types the provider's checks do not cover. Their built-in check libraries span IAM, networking, logging and many AWS services.
Beyond Terraform. Checkov also scans CloudFormation, Kubernetes manifests, Dockerfiles, Helm charts and ARM templates. Trivy also scans container images, filesystems and git repositories.
Custom checks. You can write your own checks for anything in the plan.
Integrations. Both have mature CI integrations, and Checkov has IDE extensions.
Free and self-contained. Both are Apache 2.0 with no registry dependency. Compliance.tf is a paid SaaS registry that your terraform init depends on.
Values compliance.tf does not validate. If someone passes an insecure value to a module input that compliance.tf does not check, a scanner reading the plan can still flag it.

Use both together

Use compliance.tf modules for the resources they cover and the provider for the aws_* resources you write by hand. Run Checkov or Trivy in CI against the full plan.

The scan then does two jobs. It confirms that the enforced values made it into the plan, and it covers everything compliance.tf does not: modules outside the catalog, resource types outside the provider's checks, and other IaC formats. Preventive layer plus detective layer.

To try it, change one module's source and keep your existing pipeline: Get started.

Compare approaches
Turn controls on and off
CI/CD integration
Rule catalog
Make the case: build the internal argument for adopting it