Kubescape Integration with DefectDojo
Kubescape Integration with DefectDojo
Kubescape is an open source Kubernetes security tool, originally created by ARMO and now a Cloud Native Computing Foundation (CNCF) project. It scans live clusters, YAML manifests, and Helm charts for misconfigurations against control frameworks such as NSA-CISA hardening guidance and MITRE ATT&CK, and it can also scan images for vulnerabilities. Kubescape runs as a CLI or as an in-cluster operator, and the CLI can write its results as JSON.
Kubescape Integration with DefectDojo
We run Kubescape against every cluster and every chart change because Kubernetes misconfigurations are easy to introduce and hard to spot in review. Kubescape tells us which controls a workload fails. DefectDojo turns each failed control on each workload into a Finding that belongs to an Asset, gets an owner and an SLA, and closes when the next scan shows it fixed. Without that, a Kubescape report is a long JSON file that the platform team reads once and then forgets.
Why Kubescape Matters
Default Kubernetes settings favor getting workloads running over locking them down. Kubescape checks for the gaps that follow from that.
- It covers privileged containers, missing resource limits, host path mounts, overly broad RBAC, and similar posture issues.
- The same checks run against a live cluster and against manifests or charts in a repository, so problems can be caught before deployment.
- Controls map to published frameworks, which helps when a compliance team asks which hardening guidance is being enforced.
- A posture score is useful, but it doesn't say who owns the failing Deployment or whether last week's failure was fixed. That needs a tracking system.
Advantages of This Integration
What we gained by sending Kubescape results to DefectDojo:
- One Finding per control per workload. The parser titles each Finding with the control name and the resource, so the same control failing on two Deployments is two pieces of work with two owners.
- Deduplication tuned for posture data. DefectDojo hashes Kubescape Findings on title and component name (the full Kubernetes resource ID), so rescans of an unchanged cluster don't create copies.
- Reimport lifecycle. Controls that start passing are mitigated on reimport, new failures are added, and regressions are reactivated.
- Framework references attached. Each Finding links to the control's documentation and stores the control ID as a vulnerability ID, so you can filter by control across clusters.
- Continuous sync in DefectDojo Pro. The Kubescape connector reads posture results straight from the operator in the cluster, with no export step.
How This Integration Works
DefectDojo supports Kubescape through file import with the Kubescape JSON Importer scan type, and through a DefectDojo Pro connector.
Option 1: File import. Run Kubescape with JSON output. The Kubescape docs recommend the v2 format version for compatibility:
kubescape scan --format json --format-version v2 --output results.json
To scan manifests in a repository instead of a live cluster:
kubescape scan *.yaml --format json --format-version v2 --output results.json
Import the file in the UI (Import Scan Results on the Engagement, scan type Kubescape JSON Importer), through the API in Community Edition or DefectDojo Pro, or with Universal Importer in DefectDojo Pro:
curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
-H "Authorization: Token $DD_API_TOKEN" \
-F "scan_type=Kubescape JSON Importer" \
-F "file=@results.json" \
-F "product_name=prod-cluster-east" \
-F "engagement_name=Posture" \
-F "auto_create_context=true"
universal-importer import \
--defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
--scan-type "Kubescape JSON Importer" \
--report-path "./results.json" \
--product-name "prod-cluster-east" \
--engagement-name "Posture" \
--auto-create-context
Option 2: Kubescape connector (DefectDojo Pro). The connector reads the WorkloadConfigurationScan objects that the Kubescape operator stores in the cluster, through the operator's aggregated API. No ARMO SaaS account is needed. Prerequisites and setup:
- Install the Kubescape operator with configuration scanning enabled, and confirm results exist with
kubectl get workloadconfigurationscans -A. - Enter the cluster's API server URL (or a friendly identifier) in the Location field.
- Paste a kubeconfig with list and get access to
workloadconfigurationscansin thespdx.softwarecomposition.kubescape.ioAPI group. Optionally set a context and a cluster name. - Each namespace with posture results appears as a Record. Map the ones you want to DefectDojo Assets.
The connector derives Findings the same way as the parser: control name and workload identify the Finding, severity comes from the control's score factor, and the control ID becomes the vulnerability ID.
Data Granularity: What Gets Imported
The table describes the JSON file import.
| DefectDojo Field | Source in Kubescape Report | Notes |
|---|---|---|
| Title | Control name, resource type, resource name | Falls back to control name plus full resource ID; shortened to 150 characters |
| Severity | Control scoreFactor from summaryDetails |
0 to 4 Low, up to 7 Medium, up to 9 High, up to 10 Critical; Info if no control summary is found |
| Description | Resource ID, control description, category | Category includes subcategory when present |
| Mitigation | Control mitigation |
From the control summary |
| Steps to Reproduce | Failed rules for the control | Rules serialized as JSON |
| References | Control ID | Link to the control page on hub.armosec.io |
| Vulnerability IDs | controlID |
For example C-0057 |
| Component Name | resourceID |
Full Kubernetes resource identifier |
| Finding type | Static | All Kubescape Findings |
| Deduplication | Hash code | Title, component name |
Only controls with a failed status are imported. Passed rules are skipped, and older reports without per-control status are treated as failed when the rule did not pass.
Use Cases
For cluster posture ownership: A platform team schedules a nightly Kubescape scan per cluster and reimports it into a Test for that cluster. Each namespace team sees its own failing controls, and a fixed Deployment is mitigated on the next run without anyone closing tickets by hand.
In pull requests: Helm chart and manifest changes are scanned with Kubescape in CI. New failures show up in DefectDojo as new Findings before the change reaches a cluster, and the reviewer can see the failed rule in Steps to Reproduce.
With DefectDojo Pro across many clusters: Teams running the Kubescape operator map namespace Records to Assets and let the connector keep posture current, which avoids distributing kubeconfigs to CI jobs just to export reports.
For compliance evidence: Because control IDs are stored as vulnerability IDs, a security lead can report on a single control (for example privileged containers) across every cluster and show when each instance was fixed.
Operational Tips
- Use one Test per cluster or per chart and reimport into it. Kubescape output is a full snapshot, which suits the reimport model well.
- Severity comes from the control's score factor, and a control without a summary entry is imported as Info. If you see unexpected Info Findings, check that the report includes
summaryDetails. - Pin
--format-version v2in scripts so a Kubescape upgrade doesn't change the JSON layout under you. - Dedupe keys on the full resource ID. Renaming a Deployment or moving it to another namespace creates a new Finding, so expect churn after large refactors.
- Risk-accept controls that conflict with a deliberate design choice (a node agent that genuinely needs host access, for example) with an expiration date, rather than marking them false positive.
- The parser imports posture controls only. If you also scan images with Kubescape, import those vulnerabilities with a dedicated image scanner's parser.