SpotBugs Integration with DefectDojo

SpotBugs Integration with DefectDojo

SpotBugs is an open source static analysis tool for Java, maintained by the SpotBugs community as the successor to FindBugs. It analyzes compiled bytecode rather than source and reports bug patterns such as null pointer dereferences, resource leaks, concurrency mistakes, and bad practices. With the Find Security Bugs plugin it also reports security issues such as injection, weak cryptography, and unsafe deserialization. SpotBugs writes XML reports from its command line, Maven, and Gradle integrations, and DefectDojo imports that XML.

SpotBugs Integration with DefectDojo

We already run SpotBugs with Find Security Bugs on our Java services, so its results were sitting in build artifacts that nobody opened after the build passed. Importing the SpotBugs XML into DefectDojo turns each bug instance into a Finding on the right Asset, with the source file, line, and class, plus the pattern's explanation and references. Repeat builds deduplicate against what is already open, fixes close on reimport, and security-relevant patterns get owners and SLAs like findings from any other scanner.

Why SpotBugs Matters

Java teams can get bytecode-level analysis for free, inside the build they already have.

• Because it analyzes compiled classes, SpotBugs sees what the compiler produced, including code paths that are hard to read in source.
• The Find Security Bugs plugin adds a large set of security patterns for Java web frameworks and libraries.
• Each bug type has a written explanation, and security patterns usually include an example of vulnerable code and a fix.
• SpotBugs reports a CWE ID for many patterns, which helps map results to weakness categories.
• On its own, a SpotBugs report is a build artifact. There's no record of which issues were reviewed, accepted, or fixed.

Advantages of This Integration

What we gained by importing SpotBugs into DefectDojo:

• Clean imports. SpotBugs gives each bug instance an instanceHash. The parser uses it to merge repeats within one report and counts them as occurrences.
• Location-based deduplication. DefectDojo hashes SpotBugs findings on CWE, severity, file path, and line, so the same bug at the same place is recognized across builds.
• Fix guidance on the Finding. When the report includes pattern details, the parser fills Mitigation from the pattern explanation (marking example code as an example) and References from the links in it.
• Reimport lifecycle. Reimporting each build into the same Test mitigates fixed bugs and reactivates regressions.
• Triage and ticketing. Findings can be marked false positive, risk-accepted, assigned to the owning team, or pushed to Jira.

How This Integration Works

DefectDojo imports SpotBugs output with the SpotBugs Scan scan type, which reads the XML BugCollection report.

1. Produce an XML report with messages. From the SpotBugs command line:

spotbugs -textui -xml:withMessages -output spotbugs.xml target/classes

The withMessages variant matters. Without it, the report lacks the ShortMessage text and the BugPattern details that DefectDojo uses for the title, mitigation, and references, and Findings fall back to the raw bug type as their title. To include security patterns, add the Find Security Bugs plugin to your SpotBugs run (for example through your Maven or Gradle SpotBugs plugin configuration).

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select SpotBugs Scan, and upload the XML. 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=SpotBugs Scan" \
  -F "file=@spotbugs.xml" \
  -F "product_name=inventory-service" \
  -F "engagement_name=CI" \
  -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 "SpotBugs Scan" \
  --report-path "./spotbugs.xml" \
  --product-name "inventory-service" \
  --engagement-name "CI" \
  --auto-create-context

3. Reimport on every build. Send later reports to /api/v2/reimport-scan/ for the same Test.

Data Granularity: What Gets Imported

Use Cases

In a Java CI pipeline: The Maven or Gradle build runs SpotBugs with Find Security Bugs, writes XML, and reimports it into a Test for the service. New security bugs show up in DefectDojo the same day, and a gate can block releases with open High findings.

For security-focused triage: Teams that enable every SpotBugs detector get many non-security results. Importing all of them and filtering in DefectDojo by CWE, or tagging security imports separately, lets AppSec focus on the security-relevant ones while developers handle the rest in their own workflow.

Across many services: A platform team with dozens of Java services imports each one into its own Asset, which gives security leads a per-team view of open Java SAST findings. Because CWE is stored on each Finding, the same view can be cut by weakness class to see, for example, which services still have open weak cryptography findings.

Next to other analysis: SpotBugs findings appear on the same Asset as dependency and DAST results, so reviews of a Java service see all of its open issues together.

Operational Tips

• Always generate XML with -xml:withMessages. Plain XML gives you titles made of bug type codes and no mitigation text.
• Remember that SpotBugs priority is a confidence rank, not a risk rating. Priority 1 becomes High regardless of whether the pattern is a security issue or a style issue, so adjust severity during triage or filter by category.
• Limit what reaches DefectDojo. Run SpotBugs with a filter or a security-only detector configuration if you only want security findings tracked there, or use minimum_severity on import.
• Line numbers are part of the dedupe hash, so moving code can make a bug look new. Review those pairs during triage.
• Use one Test per service and reimport into it, so fixed bugs are mitigated and history stays in one place.
• Tag imports with the build or commit (for example tags=build-1042) to link findings to the code that produced them.