# Checkov review: static analysis for Terraform, Kubernetes and container images

> Checkov is an Apache-2.0 static analysis tool from Bridgecrew that scans Terraform, CloudFormation, Kubernetes and Dockerfile files against over 1000 built-in policies, and also runs SCA scans on images and packages. It is a strong fit for teams that already keep infrastructure in git, and a poor fit for anyone who wants runtime protection or a policy engine with no YAML to maintain.

**bridgecrewio/checkov** — Prevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.

- Repository: https://github.com/bridgecrewio/checkov
- Website: https://www.checkov.io/
- Stars: 9,046 · Forks: 1,423
- Language: Python
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/bridgecrewio-checkov

## The problem Checkov solves, and who ends up using it

A misconfigured S3 bucket or an open security group is usually written down in a file long before it exists in a cloud account. Checkov targets that gap. It reads infrastructure as code and reports policy violations while the change is still a pull request, rather than after apply. The README describes it as a static code analysis tool for IaC and a software composition analysis tool for images and open source packages.

The people who get value from it are platform and DevOps engineers who keep Terraform, CloudFormation, Kubernetes manifests, Helm charts, Kustomize overlays, Serverless framework files, Bicep or ARM templates in version control. The README also lists pipeline definitions: Argo Workflows, Azure Pipelines, BitBucket Pipelines, Circle CI, GitHub Actions and GitLab CI. That second list matters more than it looks. A team that scans both its Terraform and the workflow file that applies it covers the path from definition to execution.

It is a weaker fit for teams whose cloud resources are created by hand in a console, or by application code that never emits an IaC artifact. Checkov has nothing to parse in that case.

## How graph-based scanning works under the CLI

The README states that Checkov detects misconfigurations using graph-based scanning, and that it supports context-awareness policies based on an in-memory graph. That is the architectural difference from a linter that evaluates each file in isolation. A rule can be written against a relationship, for example a security group attached to an instance, rather than against a single resource block.

Policies come in two authoring formats. The README says Python format is supported for attribute policies, and YAML for both attribute and composite policies. Graph checks are also authored in YAML: setup.py contains a build step that globs checkov/*/checks/graph_checks/**/*.yaml, loads each file with yaml.safe_load and writes a JSON copy into the build directory. So the shipped package carries JSON graph checks, and the YAML sources are a development-time format.

The codebase is deliberately modular. pyproject.toml declares an import-linter contract named "common forbidden to import other modules", listing checkov.common as the source module and a long forbidden list that includes checkov.terraform, checkov.kubernetes, checkov.dockerfile, checkov.helm, checkov.cloudformation, checkov.secrets, checkov.sca_image and checkov.sast. Each scanner is a separate package that depends on shared code, not the other way around. For anyone writing a custom runner or a policy plugin, that boundary is the one to respect.

## Installing Checkov and running a first Terraform scan

The project publishes to PyPI, and the Dockerfile installs it with pip inside a python:3.11-slim base image. The simplest local install is therefore pip. Checkov requires Terraform >= 0.12.0 according to the badge in the README, though that badge describes the template versions it can parse, not a runtime dependency.

```bash
pip install checkov
```

After installation the checkov command is on your PATH. Point it at a directory of Terraform and it walks the files and reports policy results.

```bash
checkov -d .
```

The output is a table of passed and failed checks with policy IDs such as CKV_AWS_20. The README notes that output can be produced as CLI, CycloneDX, JSON, JUnit XML, CSV, SARIF, or GitHub markdown, which is what makes the tool usable in CI without parsing the human-readable table. The README does not show the exact flags for selecting an output format, so check the scan examples in the docs before wiring it into a pipeline.

For a single file rather than a directory, the CLI takes the file directly. The README documents scanning Terraform plan output as a separate mode, which is how you catch values that only resolve after variables and modules are evaluated. Container images are scanned with the same binary, since SCA scanning of images is listed as a feature.

## Suppression, false positives and the maintenance cost

Any scanner with over 1000 built-in policies will produce findings a team disagrees with. Checkov handles this with in-line suppression of accepted risks or false positives, plus a global skip from the CLI. That is the right mechanism, but it is also where the ongoing cost sits. Every suppression is a comment in a Terraform file that someone has to own, and the repository does not document an expiry or review mechanism for them.

The policy set itself moves. Releases 3.3.16, 3.3.17 and 3.3.19 landed within roughly three weeks of each other in August and September 2026, and the last push to main was on 2026-09-17. A pinned version is the only way to keep a pipeline deterministic, because a new minor release can add checks that fail a previously green build. The README links to a migration guide for v2 to v3, which signals that major upgrades are real work rather than a version bump.

The Dockerfile is also worth reading before you containerize it. It installs Helm and Kustomize by downloading install scripts over the network with retry loops, then removes curl, and it pins setuptools==78.1.1 and urllib3==2.2.2. That is a build that needs network access and will break if those upstream script URLs change.

## Checkov compared with a general-purpose policy engine

The most common alternative in this space is Open Policy Agent with Conftest, and the difference is where the policy logic lives. Conftest parses Terraform, Kubernetes YAML or Dockerfile into a generic document and evaluates Rego rules you write yourself. Checkov ships the rules. Over 1000 built-in policies cover AWS, Azure and Google Cloud, and the README links a policy index. You get coverage on day one and you inherit someone else's opinions about what a misconfiguration is.

That trade runs both ways. With Conftest you can express any rule your organisation needs, but you own every rule, its tests and its documentation. With Checkov you write YAML or Python policies in the project's own format, and the import-linter contract in pyproject.toml shows how tightly a custom runner is coupled to the internal package layout. Extending Checkov means working inside its structure; extending Conftest means writing Rego against a document.

A second distinction is scope. Checkov also performs software composition analysis on images and open source packages for CVEs, which a pure IaC policy engine does not do. If you already run a separate container scanner, that overlap is duplication rather than a feature.

## Licence, support and what the open source build does not promise

Checkov is Apache-2.0, which permits commercial use, modification and redistribution with the usual attribution and notice requirements. The README states the project is maintained by Prisma Cloud, and that Checkov powers Prisma Cloud Application Security. That relationship is worth understanding before adoption: the open source CLI and the commercial platform share a lineage, and the README links to Prisma Cloud trial and documentation pages from the repository front page.

What the repository does not document is a support commitment for the open source build. There is a SECURITY.md and a CODE_OF_CONDUCT.md at the top level, and a Slack community link in the README, but no stated SLA, no backport policy for older minor versions, and no documented deprecation window for policy IDs. If your compliance process depends on a specific check continuing to exist, that is an assumption you are making, not a guarantee the project publishes. Treat the licence as permission to use the code, not as a service agreement.

## Conclusion

Adopt Checkov if your infrastructure already lives in Terraform, CloudFormation, Kubernetes manifests or Dockerfiles and you want policy checks running in the same pipeline as the code. Do not adopt it as a runtime security control, and do not expect it to replace cloud provider config auditing after deployment. Before rolling it out, run it against one representative module and check how many findings are true positives, then decide which policy IDs you will suppress inline with checkov:skip and which you will fix. The Apache-2.0 licence means you can embed the CLI in internal tooling, but the repository does not document any warranty or support commitment from Prisma Cloud for the open source build.

## FAQ

### What is Checkov used for?

Checkov is a static code analysis tool for infrastructure as code and a software composition analysis tool for images and open source packages. It detects security and compliance misconfigurations in files such as Terraform, CloudFormation, Kubernetes manifests and Dockerfiles, and reports CVEs in packages and images.

### How can Checkov be used in Terraform?

Point the CLI at a directory or a single file and it parses the Terraform and evaluates it against the built-in policies. The README also documents a separate Terraform plan scanning mode, which evaluates the plan output rather than the source.

### How do I install Checkov?

The project publishes to PyPI, so pip install checkov is the documented route, and the Dockerfile shows the same install running inside a python:3.11-slim image. The README does not give platform-specific instructions for Windows, Ubuntu or macOS.

### Is Checkov open source and free?

Yes. The repository is licensed Apache-2.0, which permits commercial use and modification. The README separately promotes Prisma Cloud Application Security, a commercial platform that Checkov also powers, but the CLI itself is the open source component.

### What is a Checkov scan?

A Checkov scan parses the infrastructure files you point it at, evaluates them against the built-in policy set, and reports which checks passed and which failed. The README lists the available output formats as CLI, CycloneDX, JSON, JUnit XML, CSV, SARIF and GitHub markdown.

## Sources

- [bridgecrewio/checkov on GitHub](https://github.com/bridgecrewio/checkov)
- [License: Apache-2.0](https://github.com/bridgecrewio/checkov/blob/main/LICENSE)
- [Project website](https://www.checkov.io/)
- [README](https://github.com/bridgecrewio/checkov/blob/main/README.md)
- [Releases](https://github.com/bridgecrewio/checkov/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bridgecrewio-checkov