Checkov Integration with DefectDojo

Checkov Integration with DefectDojo

Checkov is an open source static analysis tool for infrastructure as code (IaC), created by Bridgecrew, which Palo Alto Networks acquired in 2021. It scans Terraform, CloudFormation, Kubernetes manifests, Helm charts, Dockerfiles, ARM and Bicep templates, serverless configurations, and other formats for misconfigurations, using a large library of built-in policies mapped to cloud security best practices. Each failed check identifies the resource, file, and line range along with a link to the policy's guideline. Checkov writes results in several formats, including the JSON report that DefectDojo imports.

Checkov Integration with DefectDojo

We run Checkov against every repository that holds Terraform or Kubernetes manifests, because the cheapest time to fix an open storage bucket or an over-privileged pod is before it's deployed. Importing Checkov results into DefectDojo gives each failed check an owner, a location in the code, and an SLA. Infrastructure findings sit on the same Asset as the application's code and dependency findings, and when the platform team fixes a module, the next reimport closes the Finding.

Why Checkov Matters

Cloud breaches often trace back to configuration rather than code: public storage, permissive security groups, missing encryption, or logging turned off. Checkov catches those at the source.

• It scans the IaC files themselves, so issues are found in pull requests rather than after resources exist in a cloud account.
• One tool covers many frameworks, which suits teams that mix Terraform, Kubernetes, Helm, and Dockerfiles in one repository.
• Each finding names the resource (for example aws_s3_bucket.logs) and the file and line range where it is defined.
• Every check links to a guideline explaining the risk and the fix.
• Checkov's output is per run. Without a platform behind it, nobody tracks which misconfigurations were accepted on purpose and which are simply unfixed.

Advantages of This Integration

What we gained by running Checkov through DefectDojo:

• Findings tied to resources. The Terraform or Kubernetes resource name is stored as the Finding's component, so you can filter and report by resource.
• Lifecycle on reimport. Reimporting into the same Test mitigates checks that now pass, adds new failures, and reactivates any that regress.
• Deduplication. Checkov findings are hashed on title, CWE, line, file path, and description, so repeated scans of unchanged files don't create duplicates.
• Documented exceptions. Risk acceptance with an expiry and a reason gives intentional deviations, such as a deliberately public bucket for a static site, a record that outlives the pipeline run.
• Shared ownership. Infrastructure findings can be assigned to platform teams and pushed to Jira, while appearing on the Asset that the application team owns.
• One risk view. IaC findings sit next to SAST, SCA, container, and DAST findings for the same Asset.

How This Integration Works

DefectDojo imports Checkov results with the Checkov Scan scan type, which reads Checkov's JSON output.

1. Produce a JSON report. Run Checkov against the directory that holds your IaC and write JSON:

checkov -d ./infrastructure -o json > checkov-report.json

When Checkov scans a single framework, the report is one JSON object with a check_type, results, and summary. When it scans several frameworks at once, the report is a JSON array with one object per framework. The parser handles both and records each finding's check type in the description.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Checkov Scan, and upload the file. For automation, use the API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Checkov Scan" \
  -F "file=@checkov-report.json" \
  -F "product_name=platform-infra" \
  -F "engagement_name=CI" \
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Checkov Scan" \
  --report-path "./checkov-report.json" \
  --product-name "platform-infra" \
  --engagement-name "CI" \
  --auto-create-context

3. Reimport on each run. Send later reports to /api/v2/reimport-scan/ against the same Test so fixed misconfigurations are mitigated and the history stays in one place.

Data Granularity: What Gets Imported

Only failed_checks are imported. Passed checks, skipped checks (including those suppressed with inline skip comments), and parsing errors are not. The parser does not set a CWE.

Use Cases

In a pull request pipeline: CI runs Checkov on every change to the infrastructure repository and reimports into the main branch Test after merge. A gate can check DefectDojo for new High findings while known, accepted deviations stay out of the way.

For a platform team serving many apps: Shared Terraform modules are scanned in their own Asset, while each application's IaC is scanned into the application's Asset. Platform engineers see module-level issues once instead of once per consumer.

Kubernetes manifest reviews: Teams scanning Helm charts and manifests filter on the check type in the description to see container security settings, such as privileged pods or missing resource limits, separately from cloud findings.

Compliance evidence: When checks include benchmark mappings, the mitigation field records them, and DefectDojo's history shows when each misconfiguration was found and fixed.

Operational Tips

• Plan for the default severity. Open source Checkov output often has no severity, in which case every finding arrives as Medium. Set severity during triage, or adjust SLA policy so Medium IaC findings get realistic deadlines.
• Prefer DefectDojo risk acceptance over inline skips for decisions you want to audit. Skipped checks never reach DefectDojo, so there is no record of who accepted them or why.
• Scan from the same root directory each time. File path and line are dedupe fields, and paths change if the working directory changes.
• Expect churn when resource blocks move. The first line of the resource is part of the dedupe key, so reformatting a file can close and reopen findings.
• Use --framework to split large repositories into one import per framework if you want separate Tests for Terraform and Kubernetes.
• Tag imports with the environment or module (for example tags=terraform,prod) for filtering in metrics.