Policy as Code and Static Analysis

The idea in one sentence

Static analysis tools catch known-bad patterns in your HCL before a plan ever runs, while policy-as-code tools evaluate the actual computed plan against organizational rules and mechanically block it from being applied if it violates them.

Static analysis before plan even runs

terraform validate only checks that your HCL is syntactically well-formed and internally consistent — types match, required arguments are present, references resolve. It has no idea whether a t2.micro instance type is a sensible choice or whether an S3 bucket should really be publicly readable. Two categories of tool fill that gap, and both run fast, before anything is planned or applied:

• tflint is provider-aware. It ships plugin rule sets (an AWS plugin, an Azure plugin, and so on) that catch mistakes validate cannot see, because they require knowing what a real AWS API actually accepts — a deprecated instance type, an invalid ARN pattern, an argument that a provider has quietly stopped supporting.
• A security and misconfiguration scanner in the checkov family pattern-matches the HCL itself against known bad configurations: an S3 bucket with public read access, a security group open to 0.0.0.0/0 on a sensitive port, an unencrypted EBS volume. tfsec covered similar ground and its checks have since been folded into Trivy; checkov remains a widely used, actively maintained choice for this layer.

tflint --init
tflint

# 1 issue(s) found:
#
# Warning: "t1.micro" is an invalid value as instance_type (aws_instance_invalid_type)
#
#   on main.tf line 12:
#   12:   instance_type = "t1.micro"

checkov -d .

# Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access."
#   FAILED for resource: aws_s3_bucket.reports
#   File: /main.tf:5-8

Both tools run against the raw configuration — no AWS credentials, no plan, no state. That is exactly why they belong as the very first gate in a pipeline: they are cheap, fast, and catch an entire class of mistake before Terraform ever talks to AWS.

Policy-as-code at plan time: Sentinel and OPA with conftest

Static analysis stops at the code. It has no way to answer a question like “does this plan create more than five m5.xlarge instances in the production account” — that number does not exist until a plan has actually been computed. Policy-as-code tools close that gap by evaluating the plan’s machine-readable output, not the HCL:

• Sentinel is HCP Terraform’s built-in policy engine. It is tightly integrated with HCP Terraform and Terraform Enterprise runs — policies are attached to a workspace or organization and evaluated automatically as part of every run there.
• Open Policy Agent (OPA), used through the conftest CLI, is the more provider-agnostic, open-source alternative: it works against any CI system, with or without HCP Terraform, by evaluating a JSON document you hand it.

The shared idea is the same either way: someone writes a policy once — “no security group may allow ingress from 0.0.0.0/0 on port 22,” “every resource must carry a cost-center tag” — and it is evaluated automatically against every plan from then on, blocking a violating plan from ever being applied. It is a mechanical, always-enforced version of what a human reviewer would otherwise have to remember to check by eye, every single time, without fail.

terraform plan -out=plan.tfplan
terraform show -json plan.tfplan > plan.json
conftest test plan.json

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_security_group_rule"
  resource.change.after.cidr_blocks[_] == "0.0.0.0/0"
  resource.change.after.from_port <= 22
  resource.change.after.to_port >= 22
  msg := sprintf("%s allows ingress from 0.0.0.0/0 on port 22", [resource.address])
}

conftest reads the same plan.json that a person could read by hand, and rejects the run the moment deny produces any message — no plan matching that rule ever reaches apply.

Two complementary layers, not redundant ones

It is tempting to see tflint/checkov and Sentinel/OPA as doing the same job twice, but they check fundamentally different things:

• Static analysis checks the code itself, independent of what is actually changing. It would flag a public S3 bucket the same way whether this run creates one bucket or a hundred.
• Policy-as-code checks the actual planned change, and can reference real, computed values that only exist once a plan exists — an actual instance count, an actual tag value, an actual CIDR block that only got resolved after variable interpolation and module composition ran. A rule like “block any plan that would leave fewer than two instances behind a load balancer” simply has no equivalent at the raw-HCL level; there is no way to know the instance count without computing a plan first.

Both stages belong in the same pipeline, back to back: cheap static checks first, catching whole classes of mistake instantly; policy evaluation against the computed plan second, catching the specific, situational violations that only show up once Terraform knows exactly what it is about to do.

flowchart LR
  hcl["HCL code"] --> lint["tflint / checkov: static checks"]
  lint -->|passes| plan["terraform plan"]
  plan --> policy["Sentinel / OPA + conftest: policy check"]
  policy -->|passes| apply["apply"]
  policy -->|violates a rule| blocked["Blocked, never applied"]

HCL passes through static analysis, then a plan is computed and checked against policy before apply is allowed

🏗️ The one-line takeaway

tflint (provider-aware rule sets catching mistakes terraform validate cannot see) and a checkov-family scanner (pattern-matching the HCL for known misconfigurations like a public S3 bucket) run first, fast and cheap, against the raw code before anything is planned. Sentinel (built into HCP Terraform) and Open Policy Agent with conftest (open-source, provider-agnostic) run second, evaluating the actual machine-readable plan output against written policy, and mechanically block a violating plan from ever being applied. The two layers are complementary: static analysis checks the code regardless of what is changing, while policy-as-code checks the specific computed change, including values — like an actual instance count — that only exist once a plan has been run.

What can tflint and checkov catch that plain terraform validate cannot

Nothing, terraform validate already checks everything tflint and checkov check Provider-aware and security-focused issues, like a deprecated instance type or a publicly readable S3 bucket, since validate only checks syntax and internal consistency Whether a resource will be replaced instead of updated in place Whether an apply will succeed against the real AWS account

What is the key difference between what static analysis tools check and what policy-as-code tools like Sentinel or OPA check

Static analysis and policy-as-code tools check exactly the same things, just with different syntax Static analysis checks the raw HCL code regardless of what is changing; policy-as-code evaluates the actual computed plan, including values that only exist once a plan has been produced Policy-as-code tools only run after apply, as an audit step Static analysis tools require AWS credentials and policy-as-code tools do not

Which policy could only be enforced against a computed plan, not against raw HCL alone

Every S3 bucket resource block must set an acl argument No security group resource may be defined with an open CIDR range in its HCL A plan must not leave fewer than two instances behind a load balancer, since the actual planned instance count only exists after a plan is computed Every resource type must use snake_case naming

How does Sentinel differ from Open Policy Agent with conftest

They are identical tools with different names Sentinel is HCP Terraform built-in policy engine tightly integrated with HCP Terraform and Enterprise runs, while OPA with conftest is an open-source, provider-agnostic alternative usable in any CI system Sentinel only works with checkov, and OPA only works with tflint OPA can only evaluate raw HCL, never a computed plan

Submit

Mark as complete