KubeHunter Integration with DefectDojo

KubeHunter Integration with DefectDojo

kube-hunter is an open source tool from Aqua Security that hunts for security weaknesses in Kubernetes clusters. It probes a cluster the way an outside or in-cluster attacker would, either remotely against a node address, across network interfaces or a CIDR range, or from inside a pod, and reports exposed services such as the Kubelet API and weaknesses tracked by kube-hunter IDs (KHV050 and so on). Aqua has stated that kube-hunter is no longer under active development and points users to Trivy for Kubernetes scanning. Existing kube-hunter reports remain importable into DefectDojo in JSON format.

KubeHunter Integration with DefectDojo

We ran kube-hunter against our clusters because it shows what an attacker can reach from the network or from a compromised pod, which configuration checks alone don't. Importing its JSON report into DefectDojo turns each weakness into a Finding on the cluster's Asset, with the kube-hunter ID, the evidence it collected, and a link to the matching Aqua vulnerability page. Platform engineers get owners and SLAs for each issue, and the next scan shows which ones are actually closed.

Why KubeHunter Matters

Kubernetes exposes several control plane and node services, and a single misconfiguration can open a path from one pod to the whole cluster.

• kube-hunter tests from an attacker's point of view: what is reachable remotely, and what a pod can see and do.
• Each weakness carries a category drawn from attacker tactics (for example credential access or lateral movement), which helps explain impact to non-specialists.
• Passive hunting is the default. Active hunting, which can change cluster state, is opt-in with --active.
• KHV IDs link to Aqua's vulnerability database pages with explanations and remediation.
• Because the project is no longer actively developed, its checks won't cover newer Kubernetes issues. DefectDojo keeps the history of what it found while you move to a maintained scanner.

Advantages of This Integration

What we gained by importing kube-hunter results into DefectDojo:

• Cluster findings with owners. Each weakness becomes a Finding on the cluster's Asset, assignable to the platform team, with notes and a status history.
• Evidence kept with the finding. kube-hunter's evidence goes into Steps to Reproduce, so whoever fixes it can see what was observed.
• Deduplication. DefectDojo hashes title and description, and the parser also drops exact repeats within a single report.
• SLAs. kube-hunter severities map to DefectDojo's scale, so cluster weaknesses follow the same SLA rules as application findings.
• Continuity during migration. When you replace kube-hunter with a maintained scanner, both sets of results can sit on the same Asset, so you can confirm coverage before retiring the old one.

How This Integration Works

DefectDojo imports kube-hunter output with the KubeHunter Scan scan type.

1. Run kube-hunter with JSON output. For a remote scan of a node:

kube-hunter --remote 10.0.0.1 --report json > kube-hunter.json

Use --cidr for a network range, or run kube-hunter as a Kubernetes Job with --pod to test from inside the cluster and collect the JSON from the pod logs. Make sure the saved file contains only the JSON report. The parser reads the vulnerabilities array and requires each entry to have hunter, category, location, description, evidence, avd_reference, and severity fields. A report missing any of them is rejected with a message naming the missing attributes.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select KubeHunter Scan, and upload the file. To automate (Community Edition and DefectDojo Pro):

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=KubeHunter Scan" \
  -F "file=@kube-hunter.json" \
  -F "product_name=prod-cluster-east" \
  -F "engagement_name=Cluster Assessment" \
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "KubeHunter Scan" \
  --report-path "./kube-hunter.json" \
  --product-name "prod-cluster-east" \
  --engagement-name "Cluster Assessment" \
  --auto-create-context

3. Reimport after changes. After hardening the cluster, run the same scan mode and reimport into the same Test with /api/v2/reimport-scan/ so fixed weaknesses are mitigated.

Data Granularity: What Gets Imported

The nodes and services sections of the report (discovered masters, Kubelet and API server endpoints) are not imported as findings or endpoints.

Use Cases

For a periodic cluster assessment: The platform team runs kube-hunter remotely against each cluster every quarter and reimports into one Test per cluster. DefectDojo shows which weaknesses were fixed since the last assessment and which are overdue.

To test pod-level exposure: Running kube-hunter as a Job inside a namespace shows what a compromised workload could reach, such as the service account token or the Kubelet API. Those findings go to the team that owns the namespace's security settings.

During a scanner migration: A team moving from kube-hunter to Trivy imports both for a few cycles onto the same Asset. Comparing the two lists in DefectDojo shows whether anything kube-hunter caught has no equivalent in the new tool.

For audit history: Because kube-hunter results live in DefectDojo with dates and status, the record of what was found and fixed remains available after the tool itself is retired.

Operational Tips

• Watch the Location field in pod mode. It includes the kube-hunter pod's name (for example "Local to Pod (kube-hunter-5pmjs)"), and since location is part of the description hash, each run from a new pod can create new findings instead of matching old ones.
• Keep remote and pod scans in separate Tests. They report different locations, and mixing them makes reimport mitigate the wrong findings.
• Review evidence before sharing. Evidence lands in Steps to Reproduce and can include sensitive values observed during the hunt, such as token material. Restrict access to the Asset accordingly.
• Use active hunting (--active) only on clusters where state changes are acceptable, and import those results into a separate Test so they don't mix with passive scans.
• Tag each import with the cluster name and scan mode (for example tags=prod-east,remote) so metrics can be split by environment and by vantage point.
• Plan a replacement. Since kube-hunter is no longer maintained, use DefectDojo's history to confirm a maintained Kubernetes scanner covers the same ground before you stop running it.