kube-score Integration with DefectDojo
kube-score Integration with DefectDojo
kube-score is an open source static analysis tool for Kubernetes object definitions, developed in the zegl/kube-score project on GitHub and released under the MIT license. It reads YAML manifests, including rendered Helm output piped to it on standard input, and runs a set of checks covering security contexts, resource requests and limits, probes, network policies, and API version stability. Each check gets a grade rather than a severity. kube-score prints human-readable output by default and can also write JSON, CI, and SARIF formats.
kube-score Integration with DefectDojo
We run kube-score on every manifest change because it catches the configuration mistakes that turn into incidents later, and we import its JSON output into DefectDojo so those catches don't stay buried in CI logs. In DefectDojo, each failing check on each Kubernetes object becomes a Finding on the Asset that owns the service. Repeat runs don't duplicate anything, missing resource limits get an owner, and a warning that has been ignored for three months shows up in reporting instead of scrolling past in a pipeline.
Why kube-score Matters
Kubernetes manifests decide how much damage a compromised or misbehaving container can do. A pod without a security context, resource limits, or a network policy is a quiet risk that nobody notices until it matters.
- It works on files, so it needs no cluster access and fits early in a pipeline.
- It checks both security settings and reliability settings, which tend to be owned by the same platform team.
- Its comments explain the specific problem and the setting that fixes it, which developers can act on directly.
- It accepts rendered Helm templates, so charts can be checked as they will actually be deployed.
Advantages of This Integration
What DefectDojo adds on top of kube-score:
- Only real problems are imported. Passing checks (grade 10) and checks kube-score marks as skipped are left out, so the Test contains failures and warnings only.
- A clear severity scale. kube-score's grade 1 (critical) maps to High and grade 5 (warning) maps to Medium, which puts manifest issues on the same SLA ladder as other findings.
- Deduplication per object and check. The hash uses title, component name (the kube-score object name), and check ID, so the same check failing on the same object is one Finding across runs.
- Lifecycle on reimport. Reimporting into the same Test closes checks that now pass and reopens any that regress.
- Ownership and ticketing. Findings can be assigned to the team that owns a workload and pushed to Jira, with kube-score's fix guidance in the mitigation field.
How This Integration Works
DefectDojo imports kube-score output with the kube-score Scan scan type.
1. Produce a JSON report. Score your manifests and write JSON:
kube-score score manifests/*.yaml --output-format json > kube-score.json
For a Helm chart, render it first and pass the output on standard input:
helm template my-app ./chart | kube-score score - --output-format json > kube-score.json
2. Import it. In the UI, open the Engagement, choose Import Scan Results, select kube-score Scan, and upload the 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-score Scan"
-F "file=@kube-score.json"
-F "product_name=checkout-service"
-F "engagement_name=Kubernetes Manifests"
-F "auto_create_context=true"
DefectDojo Pro users can do the same with Universal Importer:
universal-importer import
--defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/"
--scan-type "kube-score Scan"
--report-path "./kube-score.json"
--product-name "checkout-service"
--engagement-name "Kubernetes Manifests"
--auto-create-context
3. Reimport on change. Send later reports to /api/v2/reimport-scan/ for the same Test so fixed checks are mitigated and history stays in one place.
Data Granularity: What Gets Imported
| DefectDojo Field | Source in kube-score Report | Notes |
|---|---|---|
| Title | check.name |
For example, the name of the failing check |
| Severity | grade |
1 becomes High, 5 becomes Medium; 10 and skipped checks are not imported |
| Description | Object name, check comment, target type, comment summaries | Each comment summary is prefixed with its container path when given |
| Mitigation | comments[].description |
kube-score's explanation of the setting to change |
| Component Name | object_name |
Kind, API version, namespace, and name of the object |
| File Path | file_name |
Manifest file the object came from |
| Line | file_row |
Omitted when kube-score reports row 0 |
| Vulnerability ID from Tool | check.id |
kube-score's check identifier |
| Finding type | Static | All kube-score findings are static |
| Deduplication | Hashcode | Title, component name, check ID |
When one check produces several comments on the same object (for example, both a limit and a request missing), they are combined into a single Finding rather than split.
Use Cases
In a CI/CD pipeline: Every pull request that touches manifests runs kube-score and reimports into a Test for that service. Reviewers see whether the change introduced new High findings, and a pipeline gate can query DefectDojo for them instead of parsing kube-score output itself.
For a platform team setting standards: A team publishing a base Helm chart used by 40 services scores each rendered chart and imports it into each service's Asset. If a default in the base chart fails a check, the shared fix closes findings across all of them on the next reimport.
Before a cluster upgrade: kube-score's stable version check flags objects using deprecated API versions. Tracking those as Findings gives the upgrade owner a list of which teams still have work to do.
For reporting: Manifest findings sit beside container image CVEs and code findings for the same Asset, so a security lead can report on a service's full risk, including how it is deployed.
Operational Tips
- Score rendered output, not raw templates. Running kube-score on Helm templates before rendering gives results for files that are never deployed as written.
- Decide how to treat reliability checks. Missing ephemeral storage limits and absent probes come in at the same grades as security checks, so use tags or risk acceptance if your SLA policy should only cover security.
- Use one Test per service or chart and reimport into it, so mitigations reflect real fixes.
- Expect line numbers only when kube-score knows them. Objects it can't locate in the source file come in without a line.
- If you suppress checks in kube-score with its ignore options, those checks will stop appearing and earlier findings for them will be mitigated on the next reimport. Record the reason in DefectDojo too.
- Tag imports with the chart version or Git ref so findings can be traced back to a specific release.