
SonarQube
Application Security- Overview
- Setup
- Data & mappings
- Operations & API
- Changelog
The SonarQube Connector integrates with a SonarQube server to synchronize static code analysis data. It syncs three models: Code Projects (the analyzed projects together with their quality metrics and ratings), Static Code Findings (the issues SonarQube raises against project code), and Static Code Finding Definitions (the rules that describe and categorize those issues). Together these provide visibility into code quality, security, reliability, and maintainability across analyzed projects.
Data retrieved from SonarQube
| Connector Object | Required | Maps to Data Model |
|---|---|---|
| Code Project | Yes | Code Project |
| Static Code Finding | Yes | Static Code Finding |
| Static Code Finding Definition | Yes | Static Code Finding Definition |
Model relationships
For detailed steps on how to view the data retrieved from SonarQube in the Brinqa Platform, see How to view your data.
Connection settings
When setting up a data integration, select SonarQube from the Connector dropdown and provide the following:
| Setting | Required | Default | Description |
|---|---|---|---|
| Server URL | No | — | SonarQube server URL |
| User token | No | — | SonarQube user API token, user should have ''System Administrator'' permission. |
| Page size | No | — | Maximum number of records to get per API request |
| Parallel requests | No | — | Maximum number of parallel API requests |
| SSL / TLS | No | — | Skip certificate verification |
Authentication
SonarQube authenticates with a user token using HTTP Basic authentication. The token is supplied as the username with an empty password — the connector Base64-encodes the string <userToken>: and sends it in the Authorization header on every request. No interactive login or token-exchange step is required.
Request Headers
| Header | Value |
|---|---|
Authorization | Basic <base64(userToken + ":")> |
Accept | application/json |
Connection Test
The connector validates the credentials by issuing a minimal paged request:
| Method | URL |
|---|---|
GET | {url}/api/issues/search?p=1&ps=1 |
A 2xx response confirms the token is valid and the server is reachable. Because the token is presented directly in the Authorization header, the same header is reused unchanged on every subsequent API request; there is no session token to store or refresh.
Sample Response
{
"total": 0,
"p": 1,
"ps": 1,
"paging": { "pageIndex": 1, "pageSize": 1, "total": 0 },
"issues": [],
"components": []
}
| Field | Description |
|---|---|
total | Total number of matching records. |
p | Current page index. |
ps | Page size. |
issues | Array of issue records (empty for the test request). |
Sync Behavior
The connector supports incremental (delta) syncs. It maintains a sync token between runs and applies it as an incremental timestamp filter, so each run re-processes only the records that changed after the previous sync. The initial run retrieves the complete data set; later runs are incremental. The specific timestamp field applied to each object is documented under that object's Sync Duration Parameter.
How to obtain SonarQube credentials
Generate a SonarQube user token
For the SonarQube connector to use the SonarQube API, you must provide a user token. The user token inherits the permissions of the user who creates the token and can be used to perform any SonarQube Web API action.
To create a user token, follow these steps:
-
Log in to your organization's SonarQube server.
-
Click the account profile icon on the upper-right corner of the page and then click My Account.
-
Click the Security tab.
-
Enter a name for the token and click Generate.
Your new user token displays. You cannot view the token again after this. Copy and save it to a secure location.
Note: If you do not have permissions to create a user token, contact your SonarQube administrator. For additional information on managing user tokens and permissions, see SonarQube documentation.
Attribute mappings
Expand the sections below to view the mappings between the source and the Brinqa data model attributes:
Code Project
| Source Field Name | SDM Attribute |
|---|---|
analysis.projectVersion | PROJECT_VERSION |
component.description | DESCRIPTION |
component.measure("alert_status") | QUALITY_GATE |
component.measure("cognitive_complexity") | COGNITIVE_COMPLEXITY |
component.measure("complexity") | CYCLOMATIC_COMPLEXITY |
component.measure("coverage") | COVERAGE |
component.measure("duplicated_lines_density") | DUPLICATION |
component.measure("ncloc") | LINES_OF_CODE |
component.measure("reliability_rating") | RELIABILITY_RATING |
component.measure("security_rating") | SECURITY_RATING |
component.measure("sqale_rating") | MAINTAINABILITY_RATING |
project.key | UID |
project.key | KEY |
project.lastAnalysisDate | LAST_ASSESSED |
project.name | NAME |
project.organization | ORG |
project.qualifier | QUALIFIER |
project.revision | REVISION |
project.visibility | VISIBILITY |
Sync time (Instant.now()) | LAST_CAPTURED |
Static Code Finding
| Source Field Name | SDM Attribute |
|---|---|
| /api/sources/show result | CODE_SNIPPET |
derived from normalized issue.status | STATUS_CATEGORY |
issue.author | AUTHOR |
issue.component (+ :issue.line) | PATH |
issue.creationDate | FIRST_FOUND |
issue.debt | DEBT |
issue.effort | EFFORT |
issue.hash | HASH |
issue.key | UID |
issue.key | KEY |
issue.message | RESULTS |
issue.project | TARGETS |
issue.rule | TYPE |
issue.status | PROVIDER_STATUS |
issue.status (normalized) | STATUS |
issue.status (normalized) | SOURCE_STATUS |
issue.tags | TAGS |
issue.updateDate | LAST_FOUND |
Static Code Finding Definition
| Source Field Name | SDM Attribute |
|---|---|
derived from normalized rule.severity | SEVERITY_SCORE |
rule.createdAt | PUBLISHED_DATE |
rule.htmlDesc + rule.descriptionSections | DESCRIPTION |
rule.isTemplate | TEMPLATE |
rule.key | UID |
rule.lang | LANGUAGES |
rule.name | NAME |
rule.params | PARAMS |
rule.repo | REPOSITORY |
rule.severity | SOURCE_SEVERITY |
rule.severity (normalized) | SEVERITY |
rule.tags | TAGS |
rule.type | CATEGORIES |
rule.updatedAt | SOURCE_LAST_MODIFIED |
Operations & API
Expand each connector object to see its operation options, delta-sync behavior, and the API it uses. See connector operation options for how to apply operation options (keys and values are case-sensitive).
Code Project
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
GET /api/projects/search
Static Code Finding
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
GET /api/issues/search
Static Code Finding Definition
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
GET /api/rules/search
Changelog
The SonarQube connector has undergone the following changes:
| Version | Description | Migration Steps |
|---|---|---|
| 3.0.6 | Improvements - Connector-sourced attribute values now take precedence over non-connector data channels (manual edits, bulk imports, UI input) when the platform consolidates records, so SonarQube data is no longer overridden by lower-priority sources. Bug Fixes - Corrected the data type of the Static Code Finding model's "First found" and "Last found" attributes. They are now stored as proper timestamps instead of numeric epoch values, so date-based filtering, sorting, and display behave correctly. | • StaticCodeFinding: the "First found" and "Last found" attributes changed from numeric (epoch) values to timestamps. Re-sync the SonarQube connector to repopulate findings with the corrected types. |
| 3.0.5 | Improvements - Code Projects whose measures or analyses cannot be read because the configured token lacks sufficient privileges are now skipped gracefully, so a single permission gap no longer aborts the whole synchronization. - Hardened handling of SonarQube's 10,000-result API limit so that reaching the limit on one project cleanly stops paging that project and continues with the rest instead of surfacing an error. - The Server URL and User token settings are now marked as required so misconfigurations are caught when the connector is set up. | N/A |
| 3.0.4 | New Features - Added lifecycle (retirement) handling for Code Projects and Static Code Findings, so stale projects and findings tied to removed projects are aged out automatically. - Static Code Findings now capture the original provider status and a normalized source status alongside the existing status, giving clearer visibility into how SonarQube reports each issue. Improvements - Code Projects now record a "Last captured" timestamp on every sync to support lifecycle aging. Bug Fixes - The Code Project "Last assessed" date is now stored as a proper timestamp instead of a numeric epoch value, so date-based filtering, sorting, and display behave correctly. - The Static Code Finding Definition "Source severity" now reflects SonarQube's original severity label (for example "BLOCKER" or "CRITICAL") instead of an internal numeric score. | • CodeProject: the "Last assessed" attribute changed from a numeric (epoch) value to a timestamp. Re-sync the SonarQube connector to repopulate projects with the corrected type. • StaticCodeFindingDefinition: the "Source severity" attribute changed from a numeric score to the original severity label. Re-sync the SonarQube connector to repopulate finding definitions with the corrected values. |
| 3.0.3 | Improvements - Error responses from SonarQube are now reported more reliably: when the API returns an unstructured error body, the raw message is surfaced instead of an empty error, making sync failures easier to diagnose. Bug Fixes - The 10,000-result API limit is now detected only on the specific HTTP 400 response that reports it, preventing unrelated responses from being misinterpreted. | N/A |
| 3.0.2 | Improvements - The connector now handles SonarQube's hard limit of 10,000 results per project: instead of failing, it stops paging the affected project once the limit is reached and continues with the remaining projects, so large instances synchronize successfully. Dependency Upgrades - Upgraded internal framework and model libraries to the latest stable versions for improved reliability, security patches, and alignment with the rest of the connector platform. | N/A |
| 3.0.1 | Improvements - Internal stability improvements to how the connector registers its supported object types. No change to synchronized data. | N/A |
| 3.0.0 | Overview The SonarQube connector integrates with SonarQube to synchronize code projects, static code findings, and the rule definitions behind those findings. Category: Application Security Models | N/A |