A misconfigured aws_s3_bucket resource or an 0.0.0.0/0 security group rule is cheap to fix in a pull request and expensive to fix once terraform apply has already created the resource — at that point it's a live incident, not a diff. That's the core argument for scanning Terraform before deployment rather than after. The tooling landscape shifted meaningfully in February 2023, when Aqua Security folded tfsec into Trivy: the standalone tfsec repository now only accepts dependency bumps, and all new Terraform misconfiguration rules ship through trivy config, which also covers CloudFormation, Kubernetes manifests, Helm charts, and Dockerfiles under one scanner. Legacy tfsec rule IDs still map onto Trivy's AVD (Aqua Vulnerability Database) rule IDs, so existing CI configs don't break outright, but teams still pinning tfsec as a standalone binary are running a project that's effectively frozen. Meanwhile HashiCorp's own Sentinel policy engine, built into Terraform Cloud and Enterprise's Team & Governance tier, runs after terraform plan and before apply, with direct access to the plan, state, and config data — a different enforcement point than a pre-commit scanner. This post walks through where each layer fits and how to chain them into one pipeline.
What actually counts as a Terraform misconfiguration?
A Terraform misconfiguration is a resource definition that's syntactically valid HCL but creates an insecure or non-compliant cloud resource — the plan succeeds, apply succeeds, and the vulnerability ships. The recurring categories across every major scanner's rule set are the same: security groups or NACLs open to 0.0.0.0/0 on ports like 22 or 3389, storage resources (S3 buckets, Azure Storage accounts, GCS buckets) provisioned without encryption-at-rest or with public-read ACLs, IAM policies using wildcard Action: "*" or Resource: "*" statements, logging and monitoring left disabled on resources like CloudTrail or VPC flow logs, and databases provisioned without encryption or with public endpoints exposed. None of these trip a syntax error or a terraform validate failure — HCL doesn't know your security group is dangerous, it only knows the block parses. That's the gap static IaC scanners are built to close: they parse the resource graph the way terraform plan does, then evaluate each resource against a rule set that encodes what "insecure" looks like for that provider and resource type.
How do tfsec, Checkov, and Terrascan differ in practice?
All three parse .tf files (or plan JSON) and flag misconfigurations without ever touching cloud credentials, but they differ in maintenance status and rule scope. Trivy's trivy config <path> command is now the actively developed successor to tfsec, sharing Aqua's AVD rule database across IaC formats beyond Terraform alone. Checkov, originally built by Bridgecrew and now maintained under Palo Alto Networks, remains an independently active scanner with its own policy-as-code rule set spanning Terraform, CloudFormation, Kubernetes, and Serverless Framework configs, and ships pre-commit hooks and GitHub Actions integrations out of the box. Terrascan, built on OPA/Rego policies, takes the same static-analysis approach but lets teams write or override rules directly in Rego rather than a tool-specific DSL. In practice, teams often run more than one: Trivy for broad multi-format coverage and its AVD database, Checkov for its policy suite and suppression workflow, or Terrascan when a team already has Rego expertise from Kubernetes admission control work.
What does Sentinel add once code reaches Terraform Cloud or Enterprise?
Sentinel adds an enforcement gate at the point where a plan is about to become real infrastructure, which a pre-commit or CI scanner can't fully replicate because it doesn't see the finalized plan output. Available on Terraform Enterprise and Cloud's Team & Governance tier and above, Sentinel policies run automatically after terraform plan and before apply, with read access to the plan, the resulting state, and the configuration itself — so a policy can inspect the actual resource values Terraform is about to create, not just the source HCL. HashiCorp's documentation defines three enforcement levels: hard-mandatory, which blocks the run with no override; soft-mandatory, which blocks by default but lets an authorized user override it; and advisory, which surfaces a warning without blocking anything. That tiering matters operationally — a team can run new rules as advisory to gather data on how many existing workspaces would fail, then promote proven rules to soft-mandatory, and reserve hard-mandatory for the small set of non-negotiable controls, like blocking public S3 ACLs outright.
How do Run Tasks connect third-party scanners into the same pipeline?
Run Tasks are Terraform Cloud/Enterprise's webhook-based integration point for external checks — cost estimation, drift detection, and third-party security scanning — that report a pass/fail result back into the run and display it inline in the run details, alongside the plan output and any Sentinel policy results. Unlike Sentinel, which is HashiCorp's own proprietary policy engine, Run Tasks let a team plug in whatever scanner they already run in CI — Trivy, Checkov, or an internal tool — so the same misconfiguration checks that gate a pull request also gate the Terraform Cloud run itself, rather than relying on CI alone and hoping nobody applies a plan generated outside that pipeline. This closes a real gap: a scanner wired only into GitHub Actions never sees runs triggered by the Terraform Cloud UI, the API, or a scheduled run, so teams that want one consistent gate regardless of trigger source pair Run Tasks with their CI-stage scanner rather than choosing one over the other.
Why is OPA/Rego relevant even outside Terrascan?
Open Policy Agent and its Rego policy language matter beyond Terrascan because they're the leading open-source alternative to Sentinel for teams that don't have (or don't want to pay for) Terraform Enterprise's governance tier, and because Rego policies written for Terraform plan JSON can be reused against Kubernetes admission control, CI/CD gates, and other systems that already speak OPA. A team can run terraform show -json to produce plan JSON, then evaluate that JSON against Rego policies with the standalone conftest tool or OPA directly — achieving a Sentinel-like plan-time gate without an Enterprise license, at the cost of building and maintaining the policy library yourself rather than relying on HashiCorp's built-in policy set.
How Safeguard fits into an IaC scanning workflow
Safeguard doesn't run a dedicated Terraform policy-as-code engine the way Sentinel or Terrascan do, so the misconfiguration checks described above still belong in a scanner like Trivy, Checkov, or Sentinel wired into your plan-time gate. Where Safeguard is directly relevant is the adjacent risk that IaC repositories routinely carry alongside misconfigurations: secrets. Safeguard's secrets scanning runs across your repositories the same way it does for application code, catching hardcoded database passwords, API keys, and cloud credentials that get pasted into .tf files or .tfvars during a rushed provisioning change — a common source of exposure that a misconfiguration-focused scanner like tfsec or Checkov isn't purpose-built to catch with the same depth. Pairing a dedicated IaC policy scanner for misconfigurations with Safeguard's secrets scanning across the same repositories gives you coverage for both failure modes without treating either as a substitute for the other.