Prospector Integration with DefectDojo

Prospector Integration with DefectDojo

Prospector is an open source Python analysis tool, hosted under the prospector-dev GitHub organization and released under GPLv2. Rather than doing its own analysis, it runs a set of other Python tools such as Pylint, pycodestyle, pyflakes, McCabe complexity, and dodgy, with optional extras including bandit and mypy, then reports all of their messages in one common format. Its output formats include JSON, selected with --output-format json.

Prospector Integration with DefectDojo

We use Prospector because one command gives us a consistent view of a Python codebase across several linters, and DefectDojo is where we separate what matters for security from what is style. Importing a Prospector report into DefectDojo puts each message on the right Asset with its file path, line, originating tool, and check code. Messages from the security-oriented tools come in as High, everything else as Low, so a hardcoded credential found by dodgy does not get buried under a few hundred line-length warnings.

Why Prospector Matters

Python teams often run several analyzers, each with its own configuration and output format. Prospector puts them behind one interface with shared profiles and strictness levels.

• One run covers style, errors, complexity, and a first layer of security checks.
• Profiles let a team turn checks up or down without configuring each tool separately.
• Every message keeps the name of the tool and the code that raised it, so results stay traceable.
• Its output mixes cosmetic and security issues in a single list. Without triage, the security items are easy to miss.

Advantages of This Integration

What we get from routing Prospector through DefectDojo:

• Security weighting by source. Messages from dodgy and bandit import as High. Messages from pylint, pyflakes, pycodestyle and the other linters import as Low.
• Precise locations. Each Finding carries the file path and line from the report, and the description adds the function name when Prospector provides one.
• Deduplication on check, file, and line. DefectDojo hashes the check code, file path, and line, so rescanning the same code does not duplicate Findings.
• A real lifecycle. Reimporting into the same Test mitigates messages that disappeared after a fix and adds new ones.
• Filter by tool. The originating tool and code are recorded in the title and description, so you can isolate dodgy or bandit results after import.
• Normal DefectDojo workflow. Findings can be assigned, marked false positive, risk-accepted, or pushed to Jira like any other result.

How This Integration Works

DefectDojo imports Prospector results with the Prospector Scan scan type, which reads the messages array from Prospector's JSON output.

1. Produce a JSON report. From the project root:

prospector --output-format json > prospector.json

To include bandit's checks, install Prospector with the bandit extra and enable it in your profile or on the command line, so its messages are part of the report.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Prospector 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=Prospector Scan" 
  -F "file=@prospector.json" 
  -F "product_name=billing-service" 
  -F "engagement_name=CI" 
  -F "auto_create_context=true"

DefectDojo Pro users can do the same with Universal Importer:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Prospector Scan" 
  --report-path "./prospector.json" 
  --product-name "billing-service" 
  --engagement-name "CI" 
  --auto-create-context

3. Reimport on each change. Send later reports to /api/v2/reimport-scan/ against the same Test so fixed messages close and new ones are added in one history.

Data Granularity: What Gets Imported

Prospector does not supply CWE, CVE, or remediation text, so those fields stay empty.

Use Cases

In a CI pipeline: Each merge to main runs Prospector and reimports the report into a Test for that repository. Developers see new High findings from dodgy or bandit the same day, while Low style messages remain available for whoever owns code quality.

Cleaning up a legacy codebase: A team adopting Prospector on an older service imports the first report, sets a minimum_severity of High for the security queue, and works through the rest on a separate schedule without losing track of it.

Comparing repositories: Platform security teams running Prospector across many Python services import each into its own Asset, which shows which services still carry hardcoded secrets or other security messages.

Supporting audits: Security messages imported from Prospector keep their discovery date and status history, so reviewers can see how long a credential finding stayed open.

Operational Tips

• Decide whether you want style messages in DefectDojo at all. Importing with minimum_severity=High keeps only dodgy and bandit results and drops the linter output.
• Because severity is based on the tool name, a serious pylint error still imports as Low. Raise it manually or review Low findings periodically if your team relies on pylint for correctness checks.
• Line numbers are part of the dedupe hash. Large refactors that move code can close old Findings and open new ones for the same issue.
• Pin your Prospector profile in the repository so successive reports use the same tools and strictness. Changing profiles changes what gets reported and can look like a wave of new or fixed Findings.
• dodgy flags strings that look like secrets. Mark test fixtures as false positives in DefectDojo so the decision is recorded and later reimports respect it.
• Tag imports with the repository or branch name so findings can be filtered when several codebases share an Asset.