kube-bench Integration with DefectDojo

kube-bench Integration with DefectDojo

kube-bench is an open source tool from Aqua Security that checks whether a Kubernetes deployment follows the CIS Kubernetes Benchmark. It runs on cluster nodes, usually as a Kubernetes Job or directly on a host, and inspects the configuration of components such as the API server, controller manager, scheduler, etcd, and kubelet. Each check reports PASS, FAIL, WARN, or INFO with an audit command, the expected result, and remediation guidance, and the results can be written as JSON for import into DefectDojo.

kube-bench Integration with DefectDojo

We run kube-bench on every cluster after provisioning and after each control plane upgrade, because a single changed flag on the kubelet can undo months of hardening. The output is long, and the same WARN results show up every time. Importing it into DefectDojo turns each failed or warning control into a Finding on the Asset for that cluster, with the CIS remediation text as the mitigation, so we can assign fixes, accept the deviations we chose deliberately, and see the trend across clusters.

Why kube-bench Matters

Kubernetes ships with defaults that favor getting started over security, and managed and self-managed clusters drift as teams tune them.

• The CIS Kubernetes Benchmark is the most common baseline auditors and customers ask about, and kube-bench checks against it directly.
• Each result includes the audit command it ran, so an engineer can reproduce and confirm the finding.
• Remediation text tells the operator exactly which file or flag to change.
• Without tracking, a FAIL fixed on one cluster can quietly reappear on the next one built from an older template.

Advantages of This Integration

What we gained by routing kube-bench results through DefectDojo:

• Only actionable results imported. The parser takes FAIL and automated WARN results and drops PASS, INFO, and manual checks, so the finding list is what needs attention.
• Stable identity per control. Each finding stores the CIS test number as its vulnerability ID from tool, and deduplication hashes on title, that ID, and description.
• Remediation carried over. The benchmark's remediation text becomes the finding's mitigation.
• Deviation management. Controls you intentionally don't meet, such as settings your managed provider controls, can be risk-accepted with an expiration date instead of reappearing as noise.
• Trend and SLA reporting. Reimporting after each run mitigates fixed controls, and Medium SLAs apply to every FAIL, giving a clear measure of hardening progress.

How This Integration Works

DefectDojo imports kube-bench output with the kube-bench Scan scan type. The parser accepts both a JSON object with a top-level Controls key and a bare list of control groups.

1. Produce a JSON report. Run kube-bench with JSON output and write it to a file:

kube-bench --json --outputfile kube-bench.json

When running kube-bench as a Job inside the cluster, add --json to the container arguments and save the Job's log output to a file.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select kube-bench Scan, and upload the JSON file. For automation, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=kube-bench Scan" \
  -F "file=@kube-bench.json" \
  -F "product_name=prod-cluster-eu" \
  -F "engagement_name=CIS Benchmark" \
  -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 "kube-bench Scan" \
  --report-path "./kube-bench.json" \
  --product-name "prod-cluster-eu" \
  --engagement-name "CIS Benchmark" \
  --auto-create-context

3. Reimport per run. Reimport each new report into the same Test for that cluster, ideally one Test per node role, so fixed controls are mitigated.

Data Granularity: What Gets Imported

kube-bench does not assign severities, which is why the parser derives severity from status. The Totals block in the report is not imported.

Use Cases

After cluster provisioning: A platform team runs kube-bench on a new cluster before handing it to application teams, imports the results into that cluster's Asset, and closes or risk-accepts every FAIL before go-live.

After upgrades: Control plane and node upgrades can reset flags. A run and reimport after each upgrade shows any control that regressed as a reactivated finding.

For customer and audit questionnaires: When a customer asks how clusters align with the CIS Kubernetes Benchmark, DefectDojo shows open deviations, accepted exceptions with reasons, and closure dates by cluster.

When building node images: Teams that bake their own node images can stand up a short-lived test cluster in the image pipeline, run kube-bench against it, and reimport into a Test for the image line. A kubelet setting that slipped in a new image shows up as a reactivated finding before the image reaches production.

Across a fleet: With one Asset per cluster, security leads can compare open FAIL counts across environments and spot the clusters built from outdated templates.

Operational Tips

• Raise severity for controls that matter most to you. The parser rates every FAIL as Medium, so anonymous access or insecure API server flags look the same as lower-impact checks until you adjust them.
• Manual checks are skipped by design. Track the CIS manual controls separately if your audit requires evidence for them.
• On managed Kubernetes services, many control plane checks cannot be changed by you. Risk-accept those with a note naming the provider responsibility.
• Run kube-bench on each node role and keep each role's results in its own Test, since master and worker checks differ and reimporting one into the other would mitigate everything.
• Because the description includes the actual value, a control whose observed value changes can appear as a new finding. Review new findings after configuration changes with that in mind.
• Tag imports with the cluster version and benchmark version (for example tags=k8s-1.30,cis) so findings stay comparable as the benchmark changes.