Dodgy Integration with DefectDojo

Dodgy Integration with DefectDojo

Dodgy is a small open source tool, written in Python and maintained under the prospector-dev organization on GitHub, that searches a codebase for values that look like they should not be there. It uses regular expressions to spot hardcoded passwords and secret keys, cloud provider keys, private key material, and connection strings, along with accidental diff check-ins. Dodgy is also bundled as one of the tools run by Prospector, the Python code analysis wrapper. It writes a JSON report to standard output, which DefectDojo imports.

Dodgy Integration with DefectDojo

We use Dodgy as a cheap, fast secrets check on Python repositories, often through Prospector, because it needs no configuration and runs in seconds. The weak point was always follow-through: a warning in a CI log does not get anyone to rotate a key. Importing Dodgy JSON into DefectDojo turns each match into a High finding on the right Asset, with the file and line, an owner, an SLA, and a mitigation note that says to remove and rotate the secret. When the credential is gone from the code, the next reimport closes the finding.

Why Dodgy Matters

A credential committed to source control is exposed to everyone with read access to the repository and to its full history, not just the current branch.

• Dodgy catches common secret shapes, such as AWS secret keys and generic secret assignments, before they spread through forks and clones.
• It is lightweight enough to run on every commit or as a pre-commit check.
• It requires no service, account, or network access, which suits restricted build environments.
• It reports no severity of its own, so without a platform deciding how to treat a match, every result looks equally ambiguous.

Advantages of This Integration

What running Dodgy through DefectDojo adds:

• Consistent severity. Every Dodgy warning imports as High, on the basis that a match is a credential in source control, so secret findings fall under a short SLA by default.
• Actionable mitigation. Each finding includes guidance to remove the secret from source, rotate it, and load it at runtime from configuration or a secrets manager.
• Deduplication on rule and location. DefectDojo hashes Dodgy findings on Vuln ID from Tool, file path, and line, so rescanning the same commit does not create duplicates, while two different rules matching the same line stay separate.
• Closure on reimport. When a secret is removed, reimporting the next report into the same Test mitigates the finding.
• Ownership and ticketing. Findings can be assigned to the repository owner, pushed to Jira, and tracked in metrics alongside other secrets scanners.
• Triage you only do once. False positives, such as test fixtures, can be marked once, and later scans that match the same rule, file, and line match the existing finding.

How This Integration Works

DefectDojo imports Dodgy output with the Dodgy Scan scan type, which expects JSON.

1. Run Dodgy and capture the report. From the root of the repository:

pip install dodgy
dodgy > dodgy.json

Dodgy writes its JSON report to standard output, so redirect it to a file for import.

2. Import the file. In the UI, open the Engagement, choose Import Scan Results, select Dodgy Scan, and upload the JSON. With 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=Dodgy Scan" 
  -F "file=@dodgy.json" 
  -F "product_name=analytics-worker" 
  -F "engagement_name=Secrets Scanning" 
  -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 "Dodgy Scan" 
  --report-path "./dodgy.json" 
  --product-name "analytics-worker" 
  --engagement-name "Secrets Scanning" 
  --auto-create-context

3. Reimport on every commit or merge. Send later reports to /api/v2/reimport-scan/ for the same Test so removed secrets are mitigated.

Data Granularity: What Gets Imported

Each entry in the report's warnings list becomes one Finding. If two rules match the same line, for example aws_secret_key and secret, both are imported.

Use Cases

As a commit gate: A Python team runs Dodgy in CI on every push and reimports the results. A new High finding blocks the release check, and the developer sees the rotation guidance in the finding rather than in a log.

Through Prospector: Teams already running Prospector for code quality add a Dodgy JSON run to the same job so that secrets results go to DefectDojo with an SLA instead of disappearing among lint warnings.

During a repository audit: Before open sourcing an internal project, a team imports a Dodgy scan into a dedicated Engagement, works each finding to closure, and keeps the record of what was found and rotated.

Alongside deeper secret scanners: Dodgy findings sit next to results from history-aware secrets tools on the same Asset. Dodgy covers the current tree quickly, and the other tools cover history.

Operational Tips

• Rotate first, then remove. Deleting the line closes the finding on reimport, but the secret still exists in repository history until it is revoked.
• Expect paired findings. The secret rule often fires on the same line as a more specific rule, so close or mark both together.
• Run Dodgy from the same directory every time. File paths feed the deduplication hash, and a changed working directory makes every finding look new.
• Mark test fixtures and sample values as false positives once. Matching on rule, file, and line keeps the decision on later scans as long as the line does not move.
• Adjust severity during triage for matches that are clearly not credentials. Everything arrives as High by design.
• Tag imports with the repository name (for example tags=analytics-worker,secrets) to report secret exposure by team.