Kubeaudit Integration with DefectDojo

Kubeaudit Integration with DefectDojo

Kubeaudit is an open source command line tool and Go package from Shopify for auditing Kubernetes clusters and manifests against common security concerns, such as containers running as root, privileged containers, missing capability drops, and deprecated API usage. It runs in three modes: against a manifest file, against a cluster through a local kubeconfig, or from inside a cluster. Results can be printed for people or written as JSON. Shopify archived the Kubeaudit repository on October 30, 2024, and its README recommends kube-bench as an actively maintained alternative.

Kubeaudit Integration with DefectDojo

Plenty of teams still have Kubeaudit wired into pipelines and cluster checks, and importing its JSON into DefectDojo keeps those results useful while they plan what comes next. Each audit result becomes a Finding with the resource it names in the title, so a privileged container in one Deployment and the same problem in another are tracked separately. Owners get assigned, SLAs apply, and when the team eventually moves to a maintained tool, the open Kubeaudit findings show exactly what the replacement needs to cover.

Why Kubeaudit Matters

Kubeaudit's auditors map directly onto settings that decide how far a compromised container can reach.

• It checks the pod and container security settings attackers care about: root users, privilege, capabilities, host namespaces, and service account token mounting.
• It works on files or live clusters, so the same checks cover what is in Git and what is actually running.
• Every result carries a level (error, warning, info) and a message describing what is wrong.
• Because the project is archived, its results deserve a home where they can be compared with output from whatever tool replaces it.

Advantages of This Integration

What DefectDojo adds when Kubeaudit results land there:

• Severity on the shared scale. Kubeaudit error maps to High, warning to Medium, and info to Info. Any other level falls back to Low.
• One Finding per resource and auditor. The title combines the audit result name with the resource name, so each affected object is its own piece of work.
• Reimport lifecycle. Reimporting a fresh audit into the same Test mitigates results that no longer appear and reactivates any that return.
• Fix guidance in place. The Kubeaudit message becomes the Finding's mitigation, so the developer sees what to change without opening the raw report.
• A migration record. Findings stay in DefectDojo with their history after Kubeaudit is retired, which makes it easy to confirm that a successor tool reports the same problems.

How This Integration Works

DefectDojo imports Kubeaudit output with the Kubeaudit Scan scan type. The parser reads the file one line at a time and expects one JSON object per line, which is what Kubeaudit's JSON output produces.

1. Produce a JSON report. Audit a manifest file:

kubeaudit all -f manifests/deployment.yaml --format json > kubeaudit.json

Or audit the cluster your current kubeconfig points to:

kubeaudit all --format json > kubeaudit.json

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Kubeaudit Scan, and upload the file. To automate it with 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=Kubeaudit Scan" 
  -F "file=@kubeaudit.json" 
  -F "product_name=prod-cluster" 
  -F "engagement_name=Kubernetes Audit" 
  -F "auto_create_context=true"

DefectDojo Pro users can run it with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Kubeaudit Scan" 
  --report-path "./kubeaudit.json" 
  --product-name "prod-cluster" 
  --engagement-name "Kubernetes Audit" 
  --auto-create-context

3. Reimport on a schedule. For a cluster audited regularly, send each new report to /api/v2/reimport-scan/ against the same Test.

Data Granularity: What Gets Imported

The parser does not set a file path, line number, CWE, or component, so in practice the title and description decide whether two results are the same Finding. The result's timestamp is not copied into the description, so repeat audits of an unchanged resource hash the same way.

Use Cases

For existing cluster checks: A team runs Kubeaudit nightly against each cluster through a local kubeconfig and reimports into a Test per cluster. DefectDojo shows which High findings are new since yesterday and which have been open past their SLA.

In a manifest pipeline: Pull requests that change Kubernetes manifests run Kubeaudit in manifest mode. Reimporting into the service's Test shows reviewers whether a change added a privileged container or dropped a security context.

During a tool migration: Before switching to a maintained scanner, a platform team imports a final Kubeaudit audit for each cluster. They then import the replacement tool's results into the same Assets and compare, so nothing Kubeaudit used to catch silently disappears.

For cluster upgrade planning: Kubeaudit's deprecated API auditor reports objects using APIs that are deprecated in newer Kubernetes releases, and tracking them as Findings gives each owning team a concrete to-do list.

Operational Tips

• Plan for the archive. Kubeaudit no longer receives updates, so new Kubernetes features and newly deprecated APIs won't be checked. Treat its results as one input while you evaluate a maintained replacement.
• Keep one Test per cluster or per manifest set. Titles don't include the namespace, so mixing clusters in one Test can make different resources with the same name look alike.
• Because the description is part of the hash, a changed Kubeaudit message for the same resource creates a new Finding. Expect some churn if you change Kubeaudit versions.
• Use minimum_severity=Medium on import if info-level results add noise.
• Record accepted exceptions (for example, a node agent that must run privileged) as risk acceptances in DefectDojo with an expiration date, so they come back for review.
• Tag imports with the cluster name and environment so findings can be filtered when one Asset spans several clusters.