What is policy as code?

Policy as code is writing the rules your infrastructure must follow — no public buckets, encryption on every database, no SSH open to the internet, required tags — as code that a tool evaluates automatically, instead of a wiki page a reviewer is expected to remember. The policies live in version control, are reviewed like other code, and run in CI against every change.

What is the difference between Checkov and OPA?

Checkov is a scanner with over a thousand built-in checks for Terraform, CloudFormation, Kubernetes, Dockerfiles and CI configs; you run it and get pass/fail per resource with no policy writing. OPA (Open Policy Agent) is a general policy engine: you write your own rules in Rego and evaluate them against any JSON input, such as a Terraform plan or a Kubernetes admission request. Many teams run both.

When should policy as code run?

At three points: in the pull request, so the author sees the failure before merge; against the Terraform plan, which catches values only known after variables resolve; and at deploy or admission time (Sentinel in Terraform Cloud, OPA Gatekeeper or Kyverno in Kubernetes) as a hard gate. Scanning the source alone misses anything computed.

What does a failed check mean?

A resource in your code or plan violates a policy: Checkov reports it as a failed check with an id like CKV_AWS_20, the resource address, the file and line range and a guideline link. It is a finding to fix or to suppress with a written reason — not proof of an incident.

How do you suppress a policy-as-code finding?

With an inline comment that names the check and gives a reason, so the exception is reviewed with the code: `#checkov:skip=CKV_AWS_18:access logs not needed for public assets` in Checkov, `#trivy:ignore:AVD-AWS-0089` in Trivy, `# kics-scan ignore-line` in KICS. Suppressed checks should still be counted in the report.

Policy as code

Policy as code is writing the rules your infrastructure must follow as code that a tool checks automatically. "No public S3 buckets." "Every database encrypted at rest." "No security group open to 0.0.0.0/0 on port 22." Instead of a checklist a reviewer is meant to remember, each rule is a policy file in version control. It runs in CI against every change, and a violation fails the build or opens a finding.

Two kinds of tool

Kind	Examples	You write	Good for
Scanner with checks	Checkov, Trivy (`config`), KICS, tfsec	Nothing to start; suppressions	Broad baseline across clouds and formats
Policy engine	OPA / Rego, Sentinel, Kyverno, Conftest	Every rule	Your org's own rules, admission control

Checkov ships over a thousand checks for Terraform, CloudFormation, Kubernetes manifests, Helm, Dockerfiles and GitHub Actions. tfsec's checks now live in Trivy, which scans the same files with trivy config. OPA evaluates Rego rules against any JSON. Point it at terraform show -json output or a Kubernetes admission request. Sentinel is HashiCorp's engine, built into Terraform Cloud and Enterprise between plan and apply.

Where it runs

Pull request. Scan the changed Terraform or manifests so the author sees the failure before merge.
Against the plan. checkov -f plan.json --framework terraform_plan or a Rego rule over the plan JSON. This catches values that only exist once variables and modules resolve, which a source scan misses.
At the gate. Sentinel in Terraform Cloud, OPA Gatekeeper or Kyverno as a Kubernetes admission controller. The change is refused, not just reported.

Reading the results

Every scanner reports the same shape. A policy id (CKV_AWS_20, AVD-AWS-0086), the resource that failed (aws_s3_bucket.exports), the file and line, and a link to the rule's guideline. Severity varies. Trivy and KICS always set one. Open-source Checkov leaves it null unless you connect Prisma Cloud.

Suppressions are part of the result. A finding skipped with a reason (#checkov:skip=CKV_AWS_18:public assets bucket) is a decision someone made. A good report counts skipped checks next to failed and passed ones, so a reviewer can see what was waived, not just what's left.

The raw output is the problem. Checkov's CLI prints a block per check into a CI log, and its JSON is meant for machines. The people who accept the risk — platform leads, auditors gathering SOC 2 evidence, the client who asked for an infrastructure review — need the failures grouped by policy with the code in view, in a document they can comment on.

Try it

Comma is free: unlimited reports, unlimited commenters, unlimited revision history.

Open the Checkov report viewer →

Checkov report viewer · Terraform plan viewer · SARIF viewer
Share a Checkov report · Share a tfsec report · Share a KICS report
Terraform plan · SARIF · Glossary

Policy as code

Two kinds of tool

Where it runs

Reading the results

Try it

Related