Findings come inStatic analysis
SonarQube
Takes SonarQube's security hotspots and vulnerability rules out of the quality gate and into the remediation loop, where they get an owner, a deadline and a verified close.
What the connector does
- Vulnerabilities and reviewed security hotspots from the projects you name
- Rule keys mapped to CWE, so a Sonar finding and a scanner finding about the same weakness line up
- Attached to the repository asset, not to a project name that only Sonar understands
- Works against SonarQube Server and SonarCloud
Credential required
A SonarQube user token with Browse permission on the projects you name.
What this connector is for
A quality gate stops a build. It does not chase the person who has to fix what stopped it, and it does not remember that the same weakness class is also present in two other services. SonarQube findings that leave the gate usually leave the conversation as well; this connector keeps them in it.
What is ingested
Issues of type vulnerability, and hotspots a reviewer has marked as a real risk. Sonar's rule key is translated to a CWE, which is what lets the platform group a Sonar result with a Semgrep result and a pentest observation that all describe the same class of mistake — the grouping compliance mapping and weakness reporting are both built on.
What happens next
The finding lands against the repository, inherits that repository's application and owning team, and gets an SLA from the policy that governs its severity and exposure. Nothing is closed because Sonar stopped reporting it in isolation: closure needs the finding to be absent from a later sync, and for findings the scan engine can retest, a targeted verification run.
What you have to grant
A user token that can browse the projects. The connector issues only read calls, and a contract test asserts that no request it makes uses a method other than GET.