Chef Integration with DefectDojo

Chef InSpec Integration with DefectDojo

Chef InSpec is a compliance-as-code and infrastructure testing framework, originally developed by Chef Software and now maintained by Progress, which acquired Chef in 2020. Its source code is developed in the open on GitHub. Teams write controls in a Ruby-based language, group them into profiles (CIS benchmarks are a common example), and run them against servers, containers, and cloud accounts. Each control carries an impact value from 0.0 to 1.0, and each run reports whether controls passed, failed, or were skipped. DefectDojo imports InSpec results from a line-delimited JSON log with the Chef Inspect Log scan type.

Chef InSpec Integration with DefectDojo

We run InSpec profiles against our server fleet to check hardening baselines, and we send the results to DefectDojo so compliance gaps are handled like any other security finding. A failed control becomes a Finding on the Asset for that system, with a severity derived from the control's impact, an owner, and an SLA. Instead of reading InSpec output per host, the infrastructure team gets one queue of hardening work next to the vulnerability findings for the same systems. If your InSpec runs report into Chef Automate, DefectDojo Pro's Chef Automate connector can pull the failed controls directly, with no log conversion step.

Why Chef InSpec Matters

Configuration drift is a steady source of exposure. A server that passed its baseline at build time can fail it six months later after manual changes.

• InSpec controls are code, so baselines are versioned, reviewed, and run the same way every time.
• Public profiles for CIS benchmarks and similar guidance give teams a starting point without writing every check themselves.
• Each control's impact value expresses how serious a failure is, which gives triage a starting severity.
• Control tags can reference compliance frameworks, which helps answer an auditor's question about which requirement a failure affects.

Advantages of This Integration

What DefectDojo adds to InSpec results:

• Compliance failures as tracked work. Each control result becomes a Finding that can be assigned, commented on, risk-accepted, or pushed to Jira.
• Severity from impact. InSpec's 0.0 to 1.0 impact maps onto DefectDojo's Info to Critical scale, so SLA policy applies without manual scoring.
• Host and profile context in one place. The description records the platform, profile, control group, control tags, and the individual test results, along with the site metadata fields in the log.
• Infrastructure and application risk together. Hardening Findings sit on the same Asset as vulnerability scanner results for that system, so reporting covers both.
• Exceptions with expiry. Controls you deliberately don't meet can be risk-accepted with an end date, instead of being silently ignored in every run.
• Failures only, on a schedule (DefectDojo Pro). The Chef Automate connector imports only failed InSpec controls from each node's latest compliance run, grouped by Chef environment, so the queue is outstanding work rather than a full control inventory.

How This Integration Works

DefectDojo imports InSpec data with the Chef Inspect Log scan type. The parser expects a text file (.log or .txt) with one JSON object per line, where each object describes one control result. The fields it reads are title, impact, description, id, control_tags, platform, profile, group, and results, plus batch_runtime, application_group, zone, office, dc, and environment.

1. Produce the log. InSpec's built-in JSON reporter writes a single nested document per run:

inspec exec ./cis-dil-benchmark -t ssh://admin@logsrv01 --reporter json:inspec-report.json

That document is not the format this parser reads. The sample logs in the DefectDojo repository are flattened, one control per line, with site metadata (application group, zone, office, data center, environment) that InSpec does not produce on its own. Plan for a small conversion step in your pipeline that writes one line per control with those keys. Each line needs at least title and a numeric impact. Other fields can be left out; they show as None in the description.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Chef Inspect Log, and upload the file. To automate it, 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=Chef Inspect Log" \
  -F "file=@inspec-results.log" \
  -F "product_name=logserver-fleet" \
  -F "engagement_name=CIS Baseline" \
  -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 "Chef Inspect Log" \
  --report-path "./inspec-results.log" \
  --product-name "logserver-fleet" \
  --engagement-name "CIS Baseline" \
  --auto-create-context

Option: Chef Automate connector (DefectDojo Pro). Teams that send InSpec results to Chef Automate can configure this connector in the DefectDojo Pro UI instead of building log files. Enter your Chef Automate server URL in Location, a Chef Automate API token in Secret (the token is never logged), and optionally a Minimum Severity. The connector groups the nodes Chef Automate reports on by environment and creates a Record for each environment.

Data Granularity: What Gets Imported

Every non-empty line becomes a Finding. There is no filtering by status inside the parser.

Connector findings (DefectDojo Pro). Each Chef Automate environment becomes a Record carrying the failed InSpec controls from its nodes' latest compliance runs. Passing and skipped controls are not imported, which avoids the status problem described in the tips below.

Use Cases

Fleet hardening: An infrastructure team runs a CIS profile across a server group nightly, filters the output to failed controls, and imports it into an Asset per environment. Each failure has an owner and an SLA, and the backlog shows which baseline items are still open.

Golden image checks: Base images are tested with InSpec before publishing. Failed controls are imported into an Engagement for the image build, and the image is held until the Critical ones are fixed or risk-accepted.

Audit preparation: Because control tags and profile details are kept in each Finding's description, a compliance lead can show which hardening requirements failed on which systems and when each was resolved.

Combining with vulnerability scans: The same Asset holds InSpec hardening failures and network or agent-based vulnerability findings for those hosts, so a system owner sees everything they need to fix in one list.

Operational Tips

• If you use Chef Automate, prefer the connector over file imports for nodes it already reports on. It handles status filtering for you, and running both against the same systems would track the same failures twice.
• Filter to failed controls before importing. The parser imports every line as an active Finding and maps severity from impact alone, so a passed control with impact 1.0 arrives as an active Critical Finding.
• Expect weak deduplication between runs. The description includes the batch runtime and each test's run timing, so the same control usually produces a different hash on the next run. Review duplicates after the first few imports and decide on a reimport cadence that works for you.
• Keep one log per host or host group, and set the Asset or Engagement accordingly, because the parser does not create endpoints for the target host.
• Set impact values deliberately in custom profiles. Impact is the only input to severity, and a profile that leaves everything at 0.0 imports as Info.
• Use minimum_severity on import to keep low-impact informational controls out of the queue.
• Tag imports with the profile name and version (for example tags=cis-dil,0.3.0) so you can tell which baseline produced a Finding.