Checkov for coding agents

When a coding agent writes or edits infrastructure-as-code (IaC), code that defines infrastructure, it can add insecure settings to cloud resources. Checkov is a command-line scanner that checks IaC files against security and compliance rules. The agent can run Checkov on its local changes, review the findings, and report or fix problems before anyone uses the configuration to create cloud resources.

Checkov supports Terraform and Kubernetes. It also supports CloudFormation, Helm, Docker, and other formats. The Checkov overview describes its built-in checks and its support for custom policies. A policy is a rule that checks whether a resource setting meets a security requirement.

Install and scan local files

Install Checkov with Python’s package installer, then scan your Terraform directory. The commands below install Checkov in a virtual environment for this project and scan ./infra; replace that placeholder path with your directory.

python -m venv .venv
source .venv/bin/activate
python -m pip install checkov

checkov --version
checkov -d ./infra --framework terraform

Checkov’s repository installation instructions document installation options. The -d flag selects a directory, and --framework terraform tells Checkov which IaC format to scan. Checkov's command-line reference explains these options and lists the supported output formats.

The scan reads local configuration and reports policy results. It does not run Terraform or change cloud resources. You need access to the Python package source to install Checkov. The local scan shown here has no sign-in step and does not connect to Prisma Cloud.

Read the findings

By default, Checkov prints a human-readable report in the terminal. To request machine-readable output, use the documented --output flag:

checkov -d ./infra --framework terraform --output json

Checkov also documents SARIF and JUnit XML output formats. SARIF is a standard format for security findings that code-hosting and analysis tools can consume; JUnit XML is commonly used by test-reporting tools. Choose a format when another tool needs to process the results. For an agent reviewing a change interactively, the default terminal report is often easier to inspect.

The report shows which checks passed or failed and identifies the affected resource or file location. A failed check is a reason to inspect the relevant configuration and rule, not proof that the resource is exploitable. In continuous integration (CI), automated checks use Checkov's exit status, the code it returns when it finishes. An agent should read the report rather than treat every nonzero status as a scan crash. Checkov documents exit and output behavior in the CLI command reference.

Use Checkov in an agent task

You can ask an agent to review Terraform it has just written for a storage bucket with unsafe access settings. The agent can scan the directory, identify failed checks, and explain which source lines need attention. If the agent edits the files, ask it to run the same scan again and check the revised configuration.

A suitable prompt is:

Run Checkov against ./infra using the Terraform framework. Summarize each failed check with its check ID, affected file or resource, and the configuration that triggered it. Do not change files or deploy anything. If Checkov reports a failure, explain a focused fix and ask before editing.

This example only asks Checkov to report findings. The prompt tells the agent not to change files. If you later authorize edits, the agent should make the smallest relevant change and rescan. A clean scan means the selected checks passed. It does not prove the infrastructure is secure in every context or that the deployed resources match the files.

Know what the scan cannot see

Checkov analyzes infrastructure code before deployment, so a local scan cannot show the current state of cloud resources. Checkov’s Prisma Cloud integration adds capabilities such as runtime scanning and drift detection, but those require a separate integration rather than the local commands shown here.

Check each policy result against the needs of the deployment. An organization may intentionally allow a setting that a default rule flags, or a rule may not cover a risk relevant to a particular deployment. Ask the agent to quote the finding, then inspect the source configuration before you accept a proposed change or decide an exception is safe.