SonarQube Integration with DefectDojo

SonarQube Integration with DefectDojo

SonarQube is a static code analysis platform from Sonar (SonarSource). It is offered as SonarQube Server (self-managed, formerly just SonarQube), SonarQube Cloud (formerly SonarCloud), and a free Community Build. It analyzes source code in many languages for bugs, code smells, security vulnerabilities, and security hotspots, and exposes results through its web UI and REST API. DefectDojo imports SonarQube results from HTML or JSON reports generated by the open source sonar-report tool, from JSON returned by the SonarQube REST API, or, in DefectDojo Pro, through a connector.

SonarQube Integration with DefectDojo

SonarQube is already in most of our build pipelines, so it is our default source of code findings. What SonarQube doesn't give us is a security view that spans tools. Bringing SonarQube vulnerabilities and hotspots into DefectDojo puts them on the same Asset as our dependency, container, and pentest findings, with SLAs, owners, and Jira tickets handled the same way for all of them. Developers keep working in SonarQube; the security team tracks risk in DefectDojo.

Why SonarQube Matters

Code-level weaknesses are cheapest to fix while the code is still in review, and SonarQube runs where developers already look.

• It covers many languages from one platform, which suits organizations with mixed stacks.
• Security hotspots flag code that needs a human decision, such as a weak cryptographic choice or a permissive configuration, rather than a confirmed bug.
• Rule descriptions explain the weakness and usually cite CWE and OWASP references.
• SonarQube tracks issues per project and branch. Security leads still need a cross-tool view of exposure, aging, and SLA status for each application.

Advantages of This Integration

What we gained by routing SonarQube through DefectDojo:

• Two levels of detail. The SonarQube Scan type groups issues of the same rule in the same file into one Finding and lists every line as an occurrence. SonarQube Scan detailed keeps one Finding per issue.
• Matching deduplication. The grouped type is deduplicated by hashcode on CWE, severity, and file path. The detailed type uses the SonarQube issue key as a unique ID from the tool, so the same issue is recognized exactly across scans.
• Reimport lifecycle. Reimporting into the same Test mitigates issues that were fixed and reactivates any that return.
• Hotspots alongside vulnerabilities. REST API JSON from the hotspots endpoint becomes Findings tagged hotspot, so reviewers can triage them next to confirmed vulnerabilities.
• Pro connector. DefectDojo Pro's SonarQube connector pulls from SonarQube Server or SonarQube Cloud on a schedule, with no report files to manage.

How This Integration Works

DefectDojo has two file scan types: SonarQube Scan (grouped) and SonarQube Scan detailed. The parser detects the input by file extension and content.

Option 1: sonar-report HTML or JSON. The sonar-report npm package from Sopra Steria reads a project from SonarQube and writes an HTML report (version 1.1.0 or later is required, 3.1.2 or later recommended). Its --save-report-json option writes the same data as JSON. Run sonar-report -h for authentication options.

sonar-report \
  --sonarurl="https://sonarqube.example.com" \
  --sonarcomponent="payments-api" \
  --project="Payments API" \
  --application="payments-api" \
  --release="2.3.0" \
  --branch="main" \
  --output="sonar-report.html"

Option 2: SonarQube REST API JSON. Save the response of /api/issues/search?projects=<projectkey> or /api/hotspots/search?projectKey=<projectkey> as a .json file. For large projects, page through the results and put the JSON files in a .zip, which the parser also accepts. Use the SonarQube Scan type for REST API files, because that parser path does not set a unique ID from the tool.

Import the file. In the UI, choose Import Scan Results in the Engagement and pick the scan type. 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=SonarQube Scan detailed" \
  -F "file=@sonar-report.html" \
  -F "product_name=payments-api" \
  -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 "SonarQube Scan detailed" \
  --report-path "./sonar-report.html" \
  --product-name "payments-api" \
  --engagement-name "CI" \
  --auto-create-context

Option 3: SonarQube connector (DefectDojo Pro). For SonarQube Cloud, enter https://sonarcloud.io/ in the Location field. For SonarQube Server, enter your instance's base URL. In both cases, put an API token in the Secret field; for SonarQube Server it must be a User token with access to projects, vulnerabilities, and hotspots.

A note on the older API pull. The SonarQube API Import scan type, configured through Tool Configuration, is deprecated as of DefectDojo 3.2.0 and scheduled for removal in 3.5.0 (November 2026). Move to the connector or to file import, which is not affected.

Data Granularity: What Gets Imported

The table describes sonar-report HTML and JSON; REST API differences are noted.

REST API JSON maps severity differently: BLOCKER becomes High, CRITICAL becomes Critical, MAJOR Medium, MINOR Low. Hotspots take their severity from the vulnerability probability.

Use Cases

In a CI/CD pipeline: After the SonarQube analysis step, the pipeline runs sonar-report and reimports the HTML into a Test per repository and branch. Security sees new vulnerabilities as they appear, and developers keep working in SonarQube.

For hotspot review: An AppSec engineer pulls hotspots from the REST API each sprint, imports them, and works through the hotspot-tagged Findings, accepting or escalating each one with notes.

With DefectDojo Pro at scale: Organizations with hundreds of SonarQube projects use the connector so every project's findings arrive without pipeline changes.

For release reporting: SonarQube findings appear in DefectDojo reports next to SCA and DAST results, so a release review covers the whole application.

Operational Tips

• Pick grouped or detailed per Test and don't switch. The two types deduplicate differently, so mixing them in one Test produces confusing matches.
• Prefer SonarQube Scan detailed for sonar-report files when you want issue-level tracking. The issue key gives exact matching across scans.
• Know your severity mapping. sonar-report files and REST API JSON map Blocker and Critical differently, so stick to one source per Asset if SLAs depend on it.
• REST API files include bugs and code smells as well as vulnerabilities. Filter by tag, or set minimum_severity, if you only want security work in DefectDojo.
• Grouped findings with no CWE fall back to a legacy hash calculation, so review deduplication results after the first few imports.
• Migrate any SonarQube API Import configurations before the 3.5.0 release removes them.