compliance.tf

compliance.tf vs Checkov / Trivy

What each tool solves

compliance.tf prevents non-compliant configurations for the modules it covers. Controls are embedded in the module code. When a developer uses a compliance.tf module, configurations like S3 encryption, access logging, and public access blocking are enforced as defaults or validated at terraform plan time. Non-compliance produces an error before any resource is created.

Checkov and Trivy scan infrastructure-as-code for security misconfigurations. They analyze Terraform HCL files or plan JSON output and report findings against a library of built-in checks. They catch problems before terraform apply, but after the code has been written.

Where compliance.tf is stronger

When using a compliance.tf module, a developer cannot plan a non-compliant S3 bucket — the module enforces encryption, logging, and versioning through defaults and input validation. The non-compliant configuration never exists, so there is no scan finding to triage.

This also means no custom policies to write. You don't need custom Checkov policies or a .checkov.yaml for the controls compliance.tf covers. Change the module source URL, run terraform init, and controls are active.

  • Framework-specific enforcement. The same module interface serves different control sets depending on the registry endpoint. soc2.compliance.tf enforces SOC 2 controls; pcidssv40.compliance.tf enforces PCI DSS v4.0. Checkov tags checks with framework references, but the scan output is the same regardless of which framework you need.

Where Checkov / Trivy is stronger

Checkov and Trivy scan every Terraform resource, not just the 51 modules in the compliance.tf catalog. Compliance.tf enforces controls from inside its modules, so anything declared outside one is out of scope: resources you write directly in your configuration rather than through a catalog module, and modules that are not in the catalog (terraform-aws-notify-slack and terraform-aws-atlantis, for example). Checkov and Trivy catch misconfigurations in both places that compliance.tf has no opinion on. Checkov alone includes 1,000+ built-in checks across IAM, networking, logging, and dozens of AWS services. Trivy covers a similarly broad range.

  • Both tools work beyond Terraform. Checkov scans CloudFormation, Kubernetes manifests, Dockerfiles, Helm charts, and ARM templates. Trivy scans container images, filesystems, and git repositories in addition to IaC.
  • Established CI/CD integrations. Checkov has native GitHub Actions, GitLab CI templates, IDE plugins, and PR comment bots. Trivy integrates with container registries and CI pipelines.
  • Free and open source. Checkov (Apache 2.0) and Trivy (Apache 2.0) have no subscription cost and no registry dependency. Compliance.tf is a paid SaaS with a private registry that your Terraform workflow depends on.
  • If a developer passes an insecure value to a module variable that compliance.tf does not validate, Checkov can still flag it. Both tools see the full plan output, including resources and configurations that modules do not control.

When to use both together

Use compliance.tf modules for the resources they cover (S3, RDS, ECS, EKS, VPC, Lambda, and 45 more). Compliance controls are enforced automatically — encryption, logging, access restrictions, and framework-specific requirements are built into the module.

Run Checkov or Trivy in your CI pipeline to scan the full Terraform plan. This catches everything compliance.tf does not cover: resources you declare directly instead of through a catalog module, modules outside the catalog, and misconfigurations in your own code that sits outside module boundaries.

Compliance.tf modules are designed to satisfy the Checkov checks that correspond to their controls. The CI scanning step then does two jobs: it verifies that enforcement worked, and it covers everything outside the module catalog.

Combined architecture: preventive layer (compliance.tf) + detective layer (Checkov/Trivy) = defense in depth.

compliance.tf modules and Checkov / Trivy together Flowchart: a developer writes Terraform against compliance.tf modules; terraform plan validates the module controls and also feeds its plan JSON to a Checkov or Trivy scan in CI; apply proceeds when controls are valid and the scan findings are clean. OUTPUTS PLAN JSON FINDINGS CLEAN Developerwrites Terraform compliance.tf modulesmodule source · plan time terraform plan Controls validatederrors on violation Checkov / TrivyCI scan · all resources Findings reportedoutside the catalog terraform applycompliant deployment LEGENDAuthorPreventive layerTerraform stepDetective layer (CI)

Summary

Dimensioncompliance.tfCheckov / Trivy
When it actsterraform plan time (enforced in module source)CI/CD scan time
What it covers51 modules in the catalogAll Terraform resources, plus CloudFormation, K8s, Docker
How controls are maintainedMaintained by compliance.tf, upstream-compatibleCommunity + custom rules; you maintain custom policies
Framework-specific enforcementYes — different registry endpoint per frameworkPartial — framework-tagged checks, but same scan output
Catches misconfiguration in user code outside modulesNoYes
Custom policy supportNo (controls are fixed per framework)Yes (custom checks in Python/YAML)
Open sourceNo (paid SaaS registry)Yes (Apache 2.0)
CostPaid subscription (free trial available)Free (open source); paid for Prisma Cloud / Bridgecrew platform

Need to make the case to your team? Internal advocacy guide.

On this page

Ask AI about this

Help improve this page