Checkov vs KICS: Graph Checks or Rego Queries

These two land on the same shortlist because they answer the same request. A platform team wants an open source scanner that reads Terraform, Kubernetes manifests and CloudFormation, runs in CI without a server, and fails a pull request when someone opens a security group to the world. Both ship a large maintained rule library, both detect secrets in scanned files, both emit SARIF, and both are backed by a commercial security vendor that builds a broader platform on top.

The difference that decides the choice is what a rule is. In Checkov a rule is a Python class or a YAML definition evaluated against a resource graph, so policies can reason about how resources connect. In KICS a rule is a Rego query evaluated against a normalized JSON document, packaged with its own passing and failing test samples. Everything else in this comparison follows from that: who can write the custom checks you will eventually need, which formats get deep coverage, and how the tool behaves once it is blocking merges.

The short answer #

Pick Checkov if your estate is mostly Terraform and Kubernetes, your platform engineers are more comfortable in Python or YAML than Rego, and you want checks that understand relationships between resources. Pick KICS if your configuration spans Ansible, Docker Compose, OpenAPI, Pulumi or other formats beyond the core three, or if your organization already maintains Rego for OPA elsewhere. Running both is reasonable during an evaluation, or in a mixed estate where Checkov owns the Terraform repositories and KICS covers the long tail, but two scanners on the same files mostly doubles your suppression work.

How they differ #

Policy model and custom checks #

Checkov builds a graph of resources and their references, then evaluates checks against it. A YAML policy can express attribute conditions and connection conditions, for example that every bucket must be referenced by a logging configuration, or that an instance must not attach to a security group with unrestricted ingress. When YAML runs out of expressiveness, you write a Python class with full access to the parsed resource. For most platform teams that is a short path: YAML for the common cases, Python for the awkward ones, both in languages the team already reads.

KICS takes each file, converts it into a common internal JSON model, and runs Rego against that model. Every query lives in its own directory with metadata and positive and negative samples, which makes the shipped library easy to audit: you can see exactly what a rule flags before you enable it. The friction shows up when you write your own. You need Rego, and you need to know how KICS represents the specific format you are targeting. Debugging a query that silently matches nothing usually starts with dumping the normalized payload to see what the parser actually produced.

This axis favours Checkov for teams without Rego skills and for policies about resource relationships. It favours KICS for teams that already run OPA and want one policy language across admission control, CI and scanning.

Framework coverage and depth #

Both cover Terraform, CloudFormation, Kubernetes, Helm, Dockerfiles and ARM templates. Checkov also handles Bicep and Serverless framework definitions, and it can scan a Terraform plan JSON file, which resolves variables, module outputs and computed values that source scanning cannot see. That plan support matters more than any format list for a Terraform shop, because it removes a whole class of false positives on resources that are correctly configured through variables.

KICS reaches further across formats: Ansible playbooks, Docker Compose, OpenAPI definitions, Google Deployment Manager, Pulumi, CDK output, SAM, Knative and gRPC configurations. For an estate that accumulated tooling over many years, that breadth means one scanner instead of three. Checkov's format list keeps growing too, so check any long tail format against both. Depth is uneven, though. Terraform and Kubernetes queries are well developed, while some of the less common formats carry thin rulesets, so coverage of a format does not guarantee meaningful checks for it. Whether KICS can consume plan output for your setup is worth confirming against its documentation before you rely on it.

This axis favours Checkov for depth on Terraform and KICS for breadth across a heterogeneous estate.

Behaviour in a pull request workflow #

Both run as a CLI or container in GitHub Actions, GitLab CI, Jenkins and Azure DevOps, and KICS also integrates with Bitbucket Pipelines. Both write SARIF, so findings can appear as annotations on the diff through GitHub code scanning rather than as a log nobody opens. Both let you control which severities fail the build, which is the setting that decides whether the gate survives its first month.

The differences are in the developer loop around the gate. Checkov offers a pre-commit hook and an IDE extension, so a developer can see the same finding in their editor before pushing, and it supports inline skip comments that carry a justification next to the resource. It also supports a baseline file, letting you record existing findings and fail only on new ones. KICS is primarily a CLI and pipeline tool. It supports inline ignore comments and excluding queries by identifier or category, and its results include the expected versus actual value, which shortens the conversation when a developer asks why a check fired. On speed, KICS is written in Go and tends to start and finish faster, while Checkov's Python runtime and graph construction add time on large monorepos.

This axis favours Checkov where you want feedback before the pull request exists and a baseline to adopt against, and KICS where CI runtime on a large repository is the constraint.

Where each one falls short #

Checkov is loud on first run. The default policy set fires on choices many teams deliberately accept. Month three is where skip comments either carry real justifications or turn into a copy pasted habit that nobody reviews. Graph construction also slows scans on very large repositories, which pushes teams toward scanning only changed directories and then missing cross-module issues. Static parsing still cannot see remote module contents or data sources without the plan file, so the teams that skip plan scanning inherit the blind spots.

KICS disappoints teams who read its format list as a promise of equal depth. The first custom rule is also where the friction lands: Rego plus the normalized model is a real on-ramp, and if only one engineer understands it, the custom policy set stops growing when they move on. Like any static scanner it cannot resolve values determined at apply time, which produces false positives on resources configured through variables, and unless you wire it into a local hook, developers first meet a finding after they have already pushed.

Pick Checkov if / Pick KICS if #

Pick Checkov if:

• Most of your infrastructure is Terraform and you can generate a plan file in CI.
• You need policies about relationships, such as a resource that must be referenced by another.
• Your platform team writes Python or YAML comfortably and nobody owns Rego.
• You want the same findings in the editor and pre-commit hook as in the pipeline.
• You are adopting against a large existing estate and need a baseline to enforce only new violations.

Pick KICS if:

• Your configuration spans Ansible, Docker Compose, OpenAPI or Pulumi alongside Terraform and Kubernetes.
• Your organization already maintains Rego for Gatekeeper or Conftest and wants one policy language.
• You want every shipped rule to come with test samples you can read before enabling it.
• Scan time on a large repository is holding up pull requests.
• You run Bitbucket Pipelines and want a supported integration.

Frequently asked questions #

Can I migrate custom policies from one to the other?

Not directly. Checkov policies are Python or YAML against its graph, and KICS queries are Rego against its normalized model, so each rule has to be rewritten. Keep your custom set small and well documented, and the migration stays manageable either way.

Does either replace an admission controller?

No. Both scan files before merge and neither sits in the Kubernetes API path. Resources applied by hand or by a pipeline that skipped the scan never pass through them, so pair either one with Kyverno or Gatekeeper if you need enforcement in the cluster.

Which produces fewer false positives?

Neither wins by default, and the tuning you do matters more than the tool. For Terraform, Checkov scanning a plan file avoids the variable resolution problems that affect any source-only scan. Measure both against a representative repository and count the findings you would genuinely suppress.

Do I need the commercial platforms behind them?

Not to scan. Both open source tools gate pull requests on their own. The vendor platforms add centralized dashboards and correlation with other scanners, which matters once you run many repositories and need one view of findings.

Full profiles: Checkov and KICS.