Polaris Integration with DefectDojo

Polaris Integration with DefectDojo

Polaris is an open source Kubernetes configuration validator from Fairwinds. It audits workloads against a configurable set of checks in three categories (Security, Reliability, and Efficiency), covering settings such as running as root, writable root filesystems, missing resource requests and limits, and missing health probes. Polaris runs as a CLI against manifest files or a live cluster, as a dashboard, or as an admission controller, and the CLI's audit command writes a JSON report that DefectDojo imports. This page covers the open source Polaris CLI from Fairwinds, not the Black Duck application security product of the same name or the hosted Fairwinds Insights service.

Polaris Integration with DefectDojo

Kubernetes makes insecure defaults easy. A Deployment without a security context runs happily as root, and nobody notices until an auditor or an attacker does. We run Polaris on every manifest change because its checks are clear and its fixes are usually a few lines of YAML. Importing Polaris audits into DefectDojo turns each failing check into a Finding on the right Asset, named down to the workload and container, so the team that owns a chart can see exactly what to change and we can see whether they did.

Why Polaris Matters

Most Kubernetes misconfigurations are not exotic. They are missing fields, and they repeat across every workload copied from the same template.

• It checks security settings like privilege escalation, host networking, and root filesystem access, alongside reliability and efficiency settings that affect availability.
• It runs against manifests with --audit-path, so no cluster access is needed in CI.
• It also audits a live cluster, which catches workloads deployed outside the normal pipeline.
• Checks are configurable, so a team can set each one to danger, warning, or ignore to match its own policy.
• Polaris prints a score and a list of results per run. It has no record of who owns a failing check or whether last week's failures were fixed.

Advantages of This Integration

What we gained by sending Polaris audits through DefectDojo:

• Only failures become findings. Polaris reports every check it ran, passing or failing, plus an overall score. The parser imports only the failing checks, so a clean manifest produces no findings rather than dozens.
• Precise location. Polaris nests checks at the workload, pod template, and container level. The parser walks all three, records which level a finding came from, and builds a component name like namespace/Deployment/web/server.
• Your severity policy carries over. Polaris danger maps to High, warning to Medium, and ignore to Info, so changing a check's level in your Polaris config changes its DefectDojo severity too.
• Reimport lifecycle. Reimporting each audit into the same Test mitigates checks that now pass and adds new failures.
• Same workflow as other findings. Failing checks can be assigned to chart owners, risk-accepted with an expiration, or pushed to Jira.

How This Integration Works

DefectDojo imports Polaris output with the Polaris Scan scan type, which expects the JSON written by polaris audit --format json.

1. Run a Polaris audit. Against manifests in a repository:

polaris audit --audit-path ./manifests --format json > polaris.json

To audit the cluster your kubeconfig points at, omit --audit-path:

polaris audit --format json > polaris-cluster.json

If you use a custom Polaris configuration file to tune check severities, pass it with --config so the report reflects your policy.

2. Import the file. In the UI, open the Engagement, choose Import Scan Results, select Polaris Scan, and upload the file. Through the API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Polaris Scan" 
  -F "file=@polaris.json" 
  -F "product_name=checkout-service" 
  -F "engagement_name=K8s Config" 
  -F "auto_create_context=true"

DefectDojo Pro users can run the same import with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Polaris Scan" 
  --report-path "./polaris.json" 
  --product-name "checkout-service" 
  --engagement-name "K8s Config" 
  --auto-create-context

3. Reimport on every change. Send each new audit to /api/v2/reimport-scan/ for the same Test.

Data Granularity: What Gets Imported

Passing checks (Success: true) are never imported.

Use Cases

In a CI/CD pipeline: Every pull request to a chart repository runs polaris audit --audit-path and reimports the result. New danger-level failures show up as new High findings, and a release gate can block on them.

For platform standards: A platform team sets its own severity for each check in a shared Polaris config. DefectDojo SLAs then enforce that policy across every team's workloads without a separate tracking sheet.

For live cluster drift: A weekly cluster audit goes to its own Test, catching workloads that were changed by hand or deployed from outside the pipeline.

When hardening templates: Because findings are named down to the container, a lead can see that one base chart causes the same failure in 30 services and fix it once.

Operational Tips

• Keep manifest audits and live cluster audits in separate Tests. Cluster audits carry no file path, and mixing them makes reimport results hard to follow.
• The description is part of the deduplication hash and names the object and container, so renaming a workload creates a new Finding and mitigates the old one on reimport.
• Expect efficiency and reliability findings alongside security ones. Filter by the category in the description, or use minimum_severity=High to start with danger-level checks only.
• A truly clean Polaris audit takes more than a hardened container. Default checks also look for things like a NetworkPolicy and a PodDisruptionBudget covering the workload.
• Tune severities in your Polaris configuration rather than editing findings by hand. The next import will follow the config.
• Risk-accept checks your organization has deliberately waived, such as a host networking requirement for a node agent, with an expiration date.