SonarQube integration
Upload SonarQube security issues to Konvu to have each one triaged and reproduced against your code.
Integration details
Primary category
Static Application Security Testing
Sync direction
SonarQube → Konvu API
No native connector. You or your pipeline upload SonarQube security issues as a report. Reproduced issues come with evidence and a fix prompt.
Status
Available
Which SonarQube security issues are real?
SonarQube flags vulnerabilities and security hotspots next to your code quality results, and every hotspot needs a person to review it. Konvu has no native connector for SonarQube. You upload the security issues as a JSON export, and Konvu splits it into one report per issue, triages each one, and reproduces it against your code in a sandbox.
SonarQube findings Konvu analyzes
SAST
SonarQube vulnerabilities
Issues of type vulnerability, exported as JSON from the SonarQube web API and uploaded as a report.
SAST
SonarQube security hotspots
Hotspots exported the same way. Each one becomes its own report.
Access and setup
Export the issues with the SonarQube web API, filtered to vulnerabilities and security hotspots, and upload the file from the Konvu dashboard, the CLI, or the API. Konvu never connects to SonarQube.
To send findings
- A Konvu API key, scoped to your organization, for CLI or API uploads
- A JSON export of the security issues, and the repository it applies to
To write back
No access to SonarQube is needed.
- When automated triage is enabled for your organization, Konvu splits an uploaded export into one report per finding and links each back to the file it came from.
- Leave code smells and other quality issues out of the export. Konvu treats each report as a claimed vulnerability.
How Konvu investigates SonarQube findings
What Konvu receives
Each issue copied verbatim out of the export, with its rule, file, and line.
What Konvu checks
- Whether the issue describes a plausible vulnerability in scope for the repository.
- Whether another report already covers the same flaw, so one fix is not tracked twice.
- Whether the flaw can be triggered, by reproducing it in an isolated sandbox against your code.
What decides the verdict
Each report is first triaged as valid, invalid, or needing information. Valid reports are reproduced, and end as Reproduced, with the proof, or as False positive, Hardening, or Inconclusive, with the evidence behind the call.
Illustrative example
An SSRF hotspot from SonarQube
A made-up service, written to show how an investigation reads. Not a customer result.
- 1
Scanner finding
SonarQube flags a server-side request forgery hotspot in a Java service: a webhook sender builds an HTTP request from a URL stored in the database.
- 2
Application context
Only organization admins can set the webhook URL, through an authenticated settings page. The sender runs on a network that can reach internal services.
- 3
Investigation
Konvu runs the service in a sandbox and tries to point the webhook at an internal address as a regular user. The settings endpoint rejects the change. As an admin, the change succeeds and the request reaches the internal address.
- 4
Verdict
Hardening. A regular user or outside attacker cannot set the URL, but an admin account could reach internal services through it. An allowlist of webhook destinations would close the gap.
- 5
Evidence
The requests Konvu sent as each role, the responses, and the code path from the stored URL to the HTTP client.
- 6
Where it ends up
The report is marked Hardening in Konvu with the evidence, and Konvu gives a fix prompt for your coding agent to add the allowlist. SonarQube is not changed, so the hotspot is reviewed there.
Writeback and controls
Where results go
- Reproduced reports come with a fix prompt your coding agent can apply directly.
- Every verdict and its evidence can be pulled into your own tools through the Konvu API or CLI.
Who triggers it
You decide when to upload. Triage and reproduction start on their own when automation is enabled for your organization.
What stays with your team
- Reviewing hotspots and resolving issues in SonarQube.
- Code changes. For uploaded reports Konvu gives a fix prompt for your coding agent, not a pull request.
Evaluation questions
The technical detail
More integrations
View all
Arnica
Add exploitability verdicts with evidence to Arnica SCA and SAST findings, and send approved SCA dismissals back to Arnica.
- SCA
- SAST
- ASPM
Black Duck
Get an exploitability verdict with evidence for Black Duck Polaris SCA findings and Coverity SAST findings.
- SCA
- SAST
Checkmarx
Send Checkmarx One SCA and SAST results to Konvu for an exploitability verdict with evidence, through the Konvu API or a report upload.
- SAST
- SCA
CodeQL
Check whether each CodeQL security alert is exploitable, and dismiss the false positives in GitHub code scanning.
- SAST
GitHub
Prioritize GitHub CodeQL and Dependabot alerts by adding exploit context to each finding.
- SAST
- SCA
- Ticketing & Messaging
GitLab
Add exploitability analysis to GitLab's built-in SAST and SCA pipeline findings.
- SCA
- SAST
- Ticketing & Messaging