What Checkov is and why teams adopt it
Checkov is an open source static analysis tool from Prisma Cloud (Palo Alto Networks) that reads infrastructure as code and flags settings that are known to be risky: a storage bucket without encryption, a security group open to the internet, a Kubernetes container running as root. Because it works on files, it can run on a laptop or in a pull request in seconds and needs no cloud access.
Teams adopt it because fixing a misconfiguration in a pull request costs minutes, while finding it in production through an incident or an audit costs far more. The problem is that on an established codebase the first scan returns hundreds or thousands of findings, and a tool that fails every build is removed within a week. Our Checkov consulting is aimed at that exact moment: getting signal without stalling delivery. We describe the delivery side in Terraform security scanning with Checkov.
How we run Checkov in production
Where it runs
We use three points. A pre-commit hook gives fast local feedback. The pull request pipeline is the main control, with results annotated on the diff. A scheduled scan of the default branch catches new policies and updated rules against old code. For Terraform we usually scan the JSON plan in the pull request, because resolved values give fewer false results:
terraform plan -out tfplan
terraform show -json tfplan > tfplan.json
checkov -f tfplan.json \
--framework terraform_plan \
--baseline .checkov.baseline \
--soft-fail-on MEDIUM \
--output cli --output sarif
The baseline file records current findings so only new ones fail the check. Flag names and severity handling vary between versions and between the open source and platform editions, so we validate the command against the release you pin. In GitHub Actions the SARIF output feeds code scanning, and the same step works in GitLab CI or Atlantis workflows.
Policy selection
The default policy library is broad, which is useful and noisy at once. We enable the frameworks relevant to your cloud, review the checks that fire most, and either fix, skip with a reason or tune them. Checks tied to a specific compliance benchmark are kept where an auditor is likely to ask. Custom policies, written in Python or YAML, encode things the library cannot know, such as required tags, approved regions or mandatory encryption keys. Each custom policy gets a test, because an untested policy that wrongly blocks production changes is worse than none.
Rolling out without blocking developers
- Report only for two weeks. Publish findings grouped by check so everyone sees the top offenders.
- Fix the dangerous few. Public storage, open admin ports and unencrypted databases get addressed first.
- Baseline the rest. Existing findings go in the baseline and a burn-down backlog.
- Fail on new high-severity findings only. Medium and low findings are shown but do not block.
- Keep skips cheap but visible. A skip needs a check ID and a reason. Code owners approve it as part of normal review.
This approach keeps the review path fast, which is what developers care about, while making the security posture improve monotonically.
Tuning findings
Typical tuning decisions include skipping checks that duplicate controls elsewhere (for example, a logging check where a central account-level trail exists), scoping checks to production paths, and excluding test fixtures and examples. We also look for module-level fixes: when twenty findings come from one internal module, correcting the module removes all twenty. That is a strong argument for reusable Terraform modules with secure defaults.
Cost, capacity and day-2 operations
Because scans run in seconds, there is no capacity planning to speak of, but the pipeline design still matters. Scanning plans needs credentials to produce them, so we run plan generation with read-only roles and keep the scanner itself credential-free.
The tool is free, and compute cost is negligible. The real cost is attention: policy upkeep, reviewing skips, and handling upgrades that change check IDs or severities. We pin versions, upgrade on a schedule in report-only mode first, and diff the results so a new release does not suddenly fail every pull request. Skips are audited periodically against a list kept in the repository.
Honest limits
- Static only. Checkov cannot see console-created resources, drift, or values that exist only at apply time.
- False positives and negatives. Complex module composition and dynamic expressions can confuse any static scanner.
- No runtime view. For behaviour inside clusters see Falco; for known vulnerabilities see Trivy.
- Edition differences. Some features and policy sets belong to the commercial platform, so check what the open source version provides before relying on it.
- Not a substitute for design review. A passing scan does not mean the architecture is sound.
When to choose something else
If you want a single binary for images and IaC, Trivy’s configuration scanning may be enough. If you already use Open Policy Agent for Kubernetes admission, extending it to Terraform plans with Conftest keeps one policy language. If your estate is mostly hand-built in consoles, start with posture management and our ClickOps to Terraform migration path before scanning code that does not yet exist.
Working with us
We begin with a baseline scan and a short readout of the top causes, then wire the gate into your pipeline and train reviewers on skips. Book a consultation to scope it.
Official documentation: www.checkov.io