kubesec Integration with DefectDojo

kubesec Integration with DefectDojo

kubesec is an open source security risk analysis tool for Kubernetes resources from ControlPlane, released under the Apache 2.0 license. It scores object definitions such as Deployments and Pods against a fixed set of security rules, sorting each rule into critical, advise, or passed and adding up points into an overall score for the object. kubesec runs as a CLI, a container image, a kubectl plugin, an admission webhook, or a local HTTP server, and its scan command writes JSON by default.

kubesec Integration with DefectDojo

kubesec gives us a quick, opinionated read on how hardened each workload is, and DefectDojo is where we turn that read into tasks. Each critical rule an object trips and each piece of hardening it lacks becomes a Finding on the service's Asset. The object's kubesec score rides along in the description, so we can see both the individual gaps and how far a workload is from a clean bill of health. Reimporting after each change shows the score climbing and the open list shrinking.

Why kubesec Matters

kubesec focuses narrowly on workload security settings, and it is explicit about the difference between something dangerous and something merely missing.

• Its critical rules cover settings that weaken isolation, such as privileged containers and added dangerous capabilities.
• Its advise rules list hardening that would raise the score, such as running as a non-root user or a read-only root filesystem.
• Each rule includes a reason and a point value, so engineers can see why it matters and how much.
• It runs on manifest files, in a cluster's admission path, or as a kubectl plugin, so the same rules apply wherever a team needs them.

Advantages of This Integration

What DefectDojo adds:

• Severity that respects kubesec's buckets. Rules in the critical bucket import as High. Rules in the advise bucket import as Low, because they describe hardening the object doesn't have yet rather than a weakness it has. The passed bucket is not imported.
• Deduplication per rule, object, and file. The hash uses the rule ID, the object, and the manifest file, so repeat scans of the same manifest update existing Findings.
• Score context. Each Finding records the rule's points and the object's overall kubesec score.
• Reimport lifecycle. Fixing a setting and reimporting mitigates its Finding. A regression reactivates it.
• Shared SLAs and assignment. kubesec High findings fall under the same SLA rules as High findings from other tools, and can be assigned or pushed to Jira.

How This Integration Works

DefectDojo imports kubesec output with the kubesec Scan scan type.

1. Produce a JSON report. Scan a manifest:

kubesec scan manifest.yaml > kubesec.json

JSON is kubesec's default output format, so no extra flag is needed.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select kubesec Scan, and upload the file. 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=kubesec Scan" 
  -F "file=@kubesec.json" 
  -F "product_name=search-service" 
  -F "engagement_name=Workload Hardening" 
  -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 "kubesec Scan" 
  --report-path "./kubesec.json" 
  --product-name "search-service" 
  --engagement-name "Workload Hardening" 
  --auto-create-context

3. Reimport on change. Send later reports to /api/v2/reimport-scan/ for the same Test so fixed rules are mitigated.

Data Granularity: What Gets Imported

The parser does not set a mitigation field. For critical rules the fix is usually to remove the setting the selector names, and for advise rules to add the setting it names.

Use Cases

In a CI/CD pipeline: A team scans each manifest on every pull request and reimports into the service's Test. A new High finding means the change added something like a privileged container, and a pipeline step can check DefectDojo for it before merge.

For a hardening program: Security engineers import kubesec results for every service, then filter on Low findings from the advise bucket to plan hardening work. As teams add security contexts, the Findings close and the scores in the descriptions go up.

For platform standards: A platform team that provides base manifests runs kubesec against them and tracks the advise list as the gap between the base and the hardening standard.

For leadership reporting: kubesec findings sit alongside image and code findings, so a security lead can show which services still have critical workload settings without running a separate report.

Operational Tips

• Treat High and Low differently. High kubesec findings are settings that weaken isolation and deserve a short SLA. Low findings are hardening opportunities and fit a backlog.
• Use minimum_severity=High on import if you only want to track critical settings at first, and lower it when you start hardening work.
• Keep file paths stable between runs. The manifest file name is part of the hash, so renaming or moving a manifest creates new Findings and mitigates the old ones.
• Scan rendered manifests when using Helm or Kustomize, so results reflect what is actually deployed.
• If you use kubesec's hosted scanning service, don't send sensitive manifests to it. Running the CLI or container locally keeps manifests in your environment.
• Record accepted exceptions, like a node agent that needs host access, as risk acceptances with an expiration date.