Checkov
Checkov is an open-source static code analysis tool designed to scan infrastructure as code (IaC) files, container images, open-source packages, and CI/CD pipeline configurations for security misconfigurations, vulnerabilities, and compliance violations across platforms including Terraform, CloudFormation, Kubernetes, Helm, ARM Templates, Dockerfile, and Serverless frameworks. The tool leverages over 750 built-in policies aligned with industry standards such as CIS Benchmarks, PCI-DSS, HIPAA, and AWS Foundational Security Best Practices, while supporting custom policy creation and graph-based scanning to analyze resource relationships and dependencies for comprehensive security assessment.
Checkov Integration with DefectDojo
Checkov is one of the most widely adopted open-source infrastructure as code security scanners — built by Bridgecrew (now part of Palo Alto Networks) and designed to find security misconfigurations in Terraform, CloudFormation, Azure ARM templates, Kubernetes manifests, Helm charts, Dockerfiles, Ansible playbooks, and more before they reach production. For platform and security engineering teams managing cloud infrastructure through code, Checkov provides fast, comprehensive policy evaluation across dozens of cloud providers and services with no licensing cost and seamless CI/CD integration. The operational challenge is universal: Checkov findings live in scan output and pipeline logs unless a vulnerability management platform captures and manages them. Integrating Checkov with DefectDojo moves IaC security findings into a persistent lifecycle — tracked, assigned, SLA-enforced, and reportable across every IaC repository in your organization — turning policy scan results into a managed remediation program.
Why Checkov Matters
Checkov's adoption in infrastructure security programs is driven by its breadth of IaC format support, the depth of its built-in policy library, and the flexibility of its custom policy engine.
- Checkov's built-in policy library covers over 1,000 checks across AWS, Azure, GCP, Oracle Cloud, Alibaba Cloud, and Kubernetes — spanning IAM configurations, encryption settings, network security, logging and monitoring, secrets management, container security, and compliance framework controls including CIS Benchmarks, PCI DSS, HIPAA, SOC 2, and NIST
- It supports every major IaC format in a single tool: Terraform (.tf files and Terraform plan JSON), CloudFormation templates (YAML and JSON), Azure Bicep and ARM templates, Kubernetes manifests, Helm charts, Dockerfiles, Ansible, and Serverless Framework configurations — eliminating the need for separate scanners per IaC technology
- Custom policies can be written in Python or YAML, allowing teams to encode organization-specific security standards, internal compliance requirements, and architectural guardrails alongside the built-in check library
- Checkov produces output in multiple formats including JSON, JUnit XML, SARIF, and a compact CLI format — the JSON output is what DefectDojo consumes for structured finding import
- It integrates natively with Terraform plan files (scanning planned infrastructure changes rather than just current configuration), enabling pre-deployment policy evaluation against what will be created, not just what exists in code
- As an open-source tool with active development and a large community, Checkov maintains currency with new cloud service releases and IaC format updates faster than most commercial alternatives
Advantages of This Integration
Checkov finds IaC security policy violations before infrastructure is deployed. DefectDojo tracks whether those violations were remediated before they reached production — and maintains the record of every decision made along the way.
- Persistent finding records across IaC scan cycles: Each time Checkov scans an IaC repository, reimporting into DefectDojo updates existing findings rather than generating a disconnected new record set. Misconfigurations that persist across multiple commits are visible by age; findings resolved by a configuration fix are automatically closed; long-lived policy violations surface through SLA breach tracking — none of this context is available from raw Checkov output.
- SLA enforcement for infrastructure misconfigurations: DefectDojo applies configurable SLA policies by severity across all imported Checkov findings. High severity misconfigurations — unencrypted S3 buckets, publicly accessible databases, overly permissive IAM roles — get tight remediation targets. Medium severity findings get longer windows. Breach tracking surfaces overdue items in dashboards without manual status chasing across repositories.
- Cross-repository IaC portfolio visibility: Security teams managing IaC across multiple repositories — application Terraform modules, shared infrastructure modules, Kubernetes configuration repositories, Dockerfile repositories — get aggregated findings in DefectDojo filtered by severity, check ID, cloud provider, and age. This aggregate view drives architectural remediation decisions and shared module security updates that individual scan outputs would never surface as a coordinated pattern.
- Risk acceptance with documented rationale: Not every Checkov finding warrants remediation. Some represent intentional architectural decisions — a public S3 bucket serving static web content, a security group rule with broad access for a specific integration, an unencrypted internal log store. DefectDojo captures risk acceptance decisions with justification, approver identity, and expiration dates — persistent across reimports and auditable for compliance review.
- False positive management across custom environments: Checkov's built-in checks occasionally flag configurations that are intentional and appropriate in a specific organizational context. Findings marked as false positives in DefectDojo are retained across reimports — the next Checkov scan won't re-open them, and the documented rationale is available for review without requiring scanner-side suppression in every repository.
- Cross-team remediation routing: IaC misconfigurations span multiple owners — Terraform findings may go to platform engineering, Kubernetes findings to the cluster operations team, Dockerfile findings to application developers, CloudFormation findings to the cloud architecture team. DefectDojo's assignment model routes each finding to the right owner with context, without a manual triage handoff for every scan cycle.
- Compliance framework mapping tracking: Checkov maps findings to CIS Benchmarks, PCI DSS, HIPAA, SOC 2, and NIST controls in its output. DefectDojo retains these mappings on imported findings, enabling filtering and reporting by compliance framework — useful for demonstrating IaC security coverage in audit and compliance contexts.
How This Integration Works
Checkov produces JSON output via its CLI that DefectDojo's Checkov parser consumes directly.
Step 1 — Install Checkov and run a scan
Install Checkov via pip:
pip install checkov
Run against an IaC directory or file and capture JSON output:
# Scan a Terraform directory
checkov -d ./terraform --output json > checkov-results.json
# Scan a specific file
checkov -f ./terraform/main.tf --output json > checkov-results.json
# Scan Kubernetes manifests
checkov -d ./k8s --framework kubernetes --output json > checkov-results.json
# Scan Dockerfiles
checkov -d . --framework dockerfile --output json > checkov-results.json
# Scan CloudFormation templates
checkov -d ./cloudformation --framework cloudformation \
--output json > checkov-results.json
# Scan a Terraform plan file (JSON format)
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json
checkov -f tfplan.json --output json > checkov-results.json
# Scan multiple frameworks in one pass
checkov -d . --framework terraform,kubernetes,dockerfile \
--output json > checkov-results.json
# Exclude specific checks (e.g., checks not applicable to your environment)
checkov -d ./terraform \
--skip-check CKV_AWS_18,CKV_AWS_52 \
--output json > checkov-results.json
# Run with a custom check directory alongside built-in checks
checkov -d ./terraform \
--external-checks-dir ./custom-checks \
--output json > checkov-results.json
For CI pipeline integration:
# Capture JSON output regardless of exit code # Checkov exits non-zero when policy violations are found checkov -d . --output json > checkov-results.json || true
Step 2 — Import into DefectDojo
Use Checkov Scan as the scan type:
curl -X POST https://<defectdojo-host>/api/v2/import-scan/ \
-H "Authorization: Token <your-api-token>" \
-F "scan_type=Checkov Scan" \
-F "file=@checkov-results.json" \
-F "engagement=<engagement-id>" \
-F "product=<product-id>" \
-F "active=true" \
-F "verified=false"
Step 3 — Reimport for recurring scans
For repositories scanned on every commit or pull request, use the reimport endpoint to update existing findings rather than accumulate redundant test records:
curl -X POST https://<defectdojo-host>/api/v2/reimport-scan/ \
-H "Authorization: Token <your-api-token>" \
-F "scan_type=Checkov Scan" \
-F "file=@checkov-results.json" \
-F "test=<test-id>"
DefectDojo marks findings absent from the new scan as resolved, creates records for new findings, and leaves previously false-positived or risk-accepted findings untouched.
Data Granularity: What Gets Imported
|
Field |
Source in Checkov Output |
Notes |
|---|---|---|
|
Title |
check_id + check_name |
e.g., "CKV_AWS_21: Ensure all data stored in the S3 bucket is securely encrypted" |
|
Severity |
severity |
HIGH, MEDIUM, LOW — mapped from Checkov check severity ratings |
|
Check ID |
check_id |
Checkov policy identifier e.g., CKV_AWS_21, CKV_K8S_14, CKV_DOCKER_2 |
|
Description |
check_result.evaluated_keys + check description |
Policy description and evaluated resource configuration |
|
Resource |
resource |
The specific IaC resource that failed the check |
|
File Path |
file_path |
Path to the IaC file containing the misconfigured resource |
|
File Line Range |
file_line_range |
Start and end lines of the resource block in the file |
|
Code Block |
code_block |
The specific IaC code that triggered the finding |
|
Guideline |
guideline |
Link to Checkov's documentation for the check |
|
Framework |
Inferred from check ID prefix |
CKV_AWS_* → Terraform/CloudFormation AWS, CKV_K8S_* → Kubernetes, etc. |
|
Compliance Mappings |
check_result.results.compliance |
CIS, PCI DSS, HIPAA, NIST control references where Checkov provides them |
|
Resource Config |
resource_config |
The full evaluated resource configuration (for Terraform plan scans) |
Use Cases
In a Terraform pull request pipeline: Checkov scans run on every pull request that modifies Terraform files. Results import into DefectDojo via the API after the scan completes. Platform engineers and the security team triage new High severity findings before the PR is merged — unencrypted storage, missing logging configuration, overly permissive security groups. Previously risk-accepted findings — an intentional public subnet configuration for a load balancer — don't re-appear in the active triage queue, keeping the review focused on genuine new policy violations rather than re-litigating architectural decisions on every PR.
For a Kubernetes manifest security review program: A platform engineering team manages Kubernetes manifests for 30 microservices across multiple clusters. Checkov scans run against the manifest repository on every commit. DefectDojo aggregates findings across all 30 services, giving the security team a ranked view of which services have containers running as root, which lack resource limits, which have privilege escalation enabled, and which are missing security context configurations. Findings are assigned to individual service teams with SLA targets — replacing ad-hoc security review cycles with a continuous, tracked program.
During a Dockerfile security hardening initiative: A security team discovers that Dockerfiles across their application portfolio consistently fail checks for pinned base image digests (CKV_DOCKER_7), non-root user configuration (CKV_DOCKER_2), and HEALTHCHECK instruction presence (CKV_DOCKER_6). Checkov scans across all Dockerfile repositories import into DefectDojo, establishing a baseline of findings across the portfolio. The initiative tracks remediation per repository with a defined target closure date — progress visible in a single DefectDojo dashboard view rather than scattered across dozens of individual tickets.
For Terraform plan scanning in a multi-account AWS environment: Rather than scanning static Terraform configuration files — which may not reflect what will actually be deployed given variable values and module compositions — the platform team runs Checkov against terraform plan JSON output in CI. This catches policy violations in the planned infrastructure change before it's applied. Findings import into DefectDojo per deployment pipeline, with risk acceptances for known exceptions documented once and honored across subsequent plan scans without repeated triage.
For IaC compliance evidence across regulated environments: A financial services organization needs to demonstrate that cloud infrastructure provisioning meets CIS Benchmark and PCI DSS controls. Checkov's compliance framework mappings carry through to DefectDojo findings, enabling filtered reporting by framework control. DefectDojo's engagement history — showing scan dates, finding counts, and remediation records — provides structured evidence of continuous IaC security policy evaluation for compliance audits without manual extraction from CI pipeline logs.
Operational Tips
- Use || true to decouple scan exit code from pipeline failure: Checkov exits non-zero when any policy violation is found. Using || true captures the JSON output for DefectDojo import regardless of violation count. Handle pipeline gate logic separately — blocking merges only on new High severity findings that aren't already tracked in DefectDojo as accepted — rather than failing the pipeline on every check violation including accepted and informational findings.
- Separate IaC framework findings into distinct DefectDojo engagements: Terraform, Kubernetes, Dockerfile, and CloudFormation findings have different remediation owners, timelines, and organizational contexts. Running Checkov per framework with --framework flags and importing into separate DefectDojo engagements keeps ownership and SLA policies clean — platform engineering owns Kubernetes findings, infrastructure teams own Terraform findings, application developers own Dockerfile findings.
- Use --skip-check sparingly and document skipped checks in DefectDojo: Checkov supports skipping specific check IDs globally via --skip-check. For checks that are skipped because they're genuinely not applicable to your environment (not because the finding is inconvenient), document the rationale as a risk acceptance in DefectDojo rather than silently excluding it at the scanner level. Scanner-side exclusions are invisible to auditors; DefectDojo risk acceptances are not.
- Scan Terraform plan output rather than static files where possible: Static Terraform file scanning catches many issues but misses misconfigurations that only manifest when variables are resolved and modules are composed. Scanning terraform plan -out=tfplan.binary && terraform show -json tfplan.binary output gives Checkov visibility into the actual infrastructure that will be deployed — a materially more accurate picture of real deployment risk.
- Tag findings by cloud provider and IaC framework on import: Tagging DefectDojo findings with the cloud provider (aws, azure, gcp) and framework (terraform, kubernetes, dockerfile, cloudformation) enables cross-repository filtering and reporting by technology stack — useful for understanding which infrastructure layer is driving the most policy violations across your estate.
- Use custom checks to encode organization-specific standards: Checkov's YAML-based custom policy engine allows teams to write checks for internal standards that the built-in library doesn't cover — required tagging schemes, approved AMI lists, mandatory encryption key policies, internal naming conventions. Custom check violations import into DefectDojo like any built-in check, giving organization-specific policy enforcement the same lifecycle management as CIS and PCI controls.
- Review PASSED findings periodically alongside FAILED findings: Checkov's JSON output includes both PASSED and FAILED results. DefectDojo imports only FAILED findings as active issues. Periodically reviewing PASSED findings from a recent scan confirms that previously remediated issues haven't regressed — complementing DefectDojo's reimport-based resolution tracking with a direct verification pass.