Why do teams run Checkov or Trivy against `terraform show -json` plan output instead of the raw HCL, and what does that cost them?

## Two different documents A static scanner such as Checkov or Trivy can point at either of two things, and the difference decides how much you can trust a green result. **The HCL** is what a human wrote. It is full of indirection by design: `var.`, `local.`, `for_each`, `dynamic` blocks, and `module` blocks pulling code from a registry. A scanner parsing it has to resolve as much of that as it can and then guess about the rest. **The JSON plan** is what Terraform decided will happen: ```bash terraform plan -out=tfplan terraform show -json tfplan > tfplan.json checkov -f tfplan.json ``` By this point every variable has a value, every local is evaluated, every `for_each` is expanded into concrete instances, and every module's resources are present with their effective attributes. The scanner reads facts rather than expressions. A note on the commands, because it is a common mix-up: `terraform plan -json` streams machine-readable *log* events, not a plan document. The document comes from `terraform show -json` applied to a saved plan file. ## Why the resolved view matters The canonical miss: a module takes `encrypted = var.encrypt_volumes` with a default of `false`, and a root module that never sets it. Scanning the module's HCL, the encryption attribute is an unresolved reference; a scanner that cannot evaluate it either stays quiet or fires on every caller. In the plan JSON the attribute is simply `false`, and the check is a straightforward comparison. The same argument applies to third-party modules. Most real estates get their networking and databases from registry modules, and the control-relevant attributes are set deep inside code the team did not write. Those resources appear in the plan document like any other — which means plan scanning covers the parts of your infrastructure an HCL scan of your own repository never looks at. Structurally, `terraform show -json` gives you `planned_values` — the full desired state of every resource in the configuration, changing or not — alongside `resource_changes`, which lists only what will change, plus the `configuration` and prior state. Scanning `planned_values` therefore evaluates your whole estate on every run, not just the diff, which is what you want for compliance evidence. ## What it costs 1. **Position in the pipeline.** Plan JSON requires `terraform init`, provider credentials, backend access and a plan that actually succeeds. It cannot be a pre-commit hook or a check on an untrusted fork. HCL scanning runs in a second, anywhere, with nothing configured — which is exactly why teams keep both rather than replacing one with the other. 2. **Unknown values.** Anything Terraform marks as known only after apply is opaque in the plan. A rule that depends on such an attribute cannot be evaluated, and how a given scanner treats that — skip or flag — determines whether you get a blind spot or noise. 3. **Traceability.** Findings arrive keyed to plan addresses like `module.network.aws_security_group.this[0]`, not to a file and line. Mapping them back to reviewable source takes extra configuration, and without it developers get findings they cannot act on. 4. **The artifact is sensitive.** JSON plan output carries the concrete values of resource attributes, including ones your configuration treated as sensitive. Treat `tfplan.json` as a secret: do not publish it as a world-readable build artifact, and delete it with the workspace. 5. **Coverage differences.** Not every rule a scanner ships works on both targets. Some checks are written against configuration structure and simply do not fire against a plan document, so switching targets silently changes which rules run. ## The tools themselves Checkov scans directories of HCL with `-d` and plan files with `-f`. Trivy's misconfiguration scanning covers Terraform configuration and plan JSON as well; tfsec, which many teams still name in interviews, has had its checks consolidated into Trivy by its maintainers, so a modern answer should mention that rather than proposing tfsec as a new adoption. ## How to answer Lead with the one-sentence reason — resolved values versus unresolved references — then show you know it is a trade rather than an upgrade: HCL scanning is early, free and credential-free but partially blind; plan scanning is accurate and complete but late, credentialed, and produces an artifact you have to protect. Teams that care run both, at different stages, for different reasons.