Cloudsploit Integration with DefectDojo

Cloudsploit Integration with DefectDojo

CloudSploit is an open source cloud security posture management (CSPM) scanner maintained by Aqua Security. It connects to cloud accounts through read-only API credentials and runs a library of plugins that check for risky configurations in AWS, Azure, Google Cloud, Oracle Cloud Infrastructure, and GitHub, such as public storage buckets, disabled logging, missing encryption, and overly permissive security groups. Each plugin reports a status of OK, WARN, FAIL, or UNKNOWN per resource and region, and results can be written to JSON for import into DefectDojo.

Cloudsploit Integration with DefectDojo

We run CloudSploit against every cloud account on a schedule because it is free, fast, and covers the services we actually use. The hard part was never running it. It was knowing which of last week's FAIL results were fixed, which were new, and who owned each one. Importing CloudSploit JSON into DefectDojo turns each failed check into a Finding tied to the right Asset, deduplicated against earlier runs, with an owner, an SLA, and a status history we can report on.

Why Cloudsploit Matters

Most cloud incidents trace back to configuration, not exploits, and configuration drifts every time someone clicks through a console or applies a hurried Terraform change.

• It checks the live state of cloud accounts, which catches drift that infrastructure as code scanning can't see.
• Its plugin library covers the common failure points across major providers, including storage exposure, identity and access settings, network rules, encryption, and logging.
• It is open source and runs from your own environment with read-only credentials.
• Each result names the exact resource and region, so a finding can go straight to the team that owns that account.
• On its own, CloudSploit output is a point-in-time list. Repeated scans produce the same failures again with no record of what changed.

Advantages of This Integration

What changed once CloudSploit results went into DefectDojo:

• Repeat scans stop multiplying work. DefectDojo deduplicates CloudSploit findings on title and description, and the description includes the resource and region, so the same failed check on the same resource is recognized across runs.
• Drift shows up as a delta. Reimporting each scan into the same Test closes findings for resources that were fixed and adds anything that newly fails.
• Accounts map to owners. Importing each cloud account or subscription into its own Asset gives every finding a clear owner and lets us assign and track remediation per team.
• SLAs apply to cloud posture. FAIL results arrive as Critical and WARN results as Medium, so the same SLA rules we use for application vulnerabilities cover cloud misconfigurations.
• Exceptions are recorded. Intentional configurations, like a bucket that is meant to be public, can be risk-accepted with a reason and an expiration date instead of being ignored in a spreadsheet.

How This Integration Works

DefectDojo imports CloudSploit output with the Cloudsploit Scan scan type, which expects the JSON array CloudSploit writes with its --json option.

1. Run CloudSploit and write JSON. From a CloudSploit checkout configured with credentials for the target account:

./index.js --config=./config.js --json=cloudsploit-prod-aws.json --ignore-ok

The --ignore-ok flag leaves passing checks out of the report. DefectDojo imports any result that is not WARN or FAIL as Info, so excluding OK results keeps passing checks from cluttering the Test.

2. Import the file. In the UI, open the Engagement, choose Import Scan Results, select Cloudsploit Scan, and upload the JSON. To automate it, use the import 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=Cloudsploit Scan" \
  -F "file=@cloudsploit-prod-aws.json" \
  -F "product_name=aws-prod-account" \
  -F "engagement_name=Cloud Posture" \
  -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 "Cloudsploit Scan" \
  --report-path "./cloudsploit-prod-aws.json" \
  --product-name "aws-prod-account" \
  --engagement-name "Cloud Posture" \
  --auto-create-context

3. Reimport on a schedule. Send each subsequent run to /api/v2/reimport-scan/ for the same Test so findings for remediated resources are mitigated automatically.

Data Granularity: What Gets Imported

When the same check produces identical title and description entries within one report, the parser merges them into one Finding.

Use Cases

For scheduled posture checks: A nightly job runs CloudSploit against each production account and reimports the results. Security leads review the overnight delta each morning instead of rereading the full list.

When onboarding a new cloud account: The first scan of an acquired company's AWS organization often returns hundreds of failures. Importing them into a dedicated Asset lets the team triage in bulk, risk-accept intentional settings, and set SLAs for the rest.

During compliance preparation: CloudSploit can run with a compliance filter such as --compliance=pci. Importing that run into its own Engagement gives auditors a dated record of which controls failed and when they were fixed.

Across multiple clouds: Teams with AWS, Azure, and Google Cloud workloads import each provider's results into the owning Asset, so posture findings for one application sit next to its code and container findings.

Operational Tips

• Map one cloud account, subscription, or project to one Asset. It keeps ownership clear and makes per-account metrics meaningful.
• Always use --ignore-ok, or set minimum_severity=Low on import, so passing checks don't land as Info findings.
• Reimport into a stable Test per account rather than creating a new Test for each run. That is what gives you automatic mitigation of fixed resources.
• Review the severity mapping before setting SLAs. Every FAIL becomes Critical regardless of the check, so you may want to adjust severity on lower-risk checks during triage.
• Tag imports with the provider and environment (for example tags=aws,prod) to filter dashboards by cloud.
• Risk-accept intentional configurations with an expiration date so they are reviewed again rather than forgotten.