sonarqube v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-sonarqube-user-token

Custody

customer_vault

Injection

header (Authorization)

A SonarQube Server user token, held in the client's own secret manager. Token issuance is external: a user (or, for service accounts, an administrator via the instance's token administration) generates the token under Account > My Account > Security, and the deployment's custody job stores it under this reference. The stored material must be the complete Authorization header value (scheme included): 'Bearer ' followed by the token — SonarQube's Web API documentation recommends the bearer scheme and documents that tokens may alternatively be sent as the username half of HTTP Basic with an empty password; this pack registers the Bearer form only. Scope honesty: a USER token carries ALL the permissions of the issuing user (SonarQube states a global admin's user token gives full rights to the instance), so the token must be issued for a dedicated least-privilege service account holding only the permissions the enabled capabilities need (Browse on the bound projects for the reads; Administer Issues on the bound projects for issue transitions; the instance's quality-gate administration permission for gate assignment; the global Create Projects permission for project creation; Administer on a project only where project deletion is enabled — the exact permission names and the supported transition set must be confirmed against the target instance's own /web_api console, which was not retrievable in this session) — never a personal admin's token. Project and global ANALYSIS tokens exist but are scoped to analysis and do not fit these capabilities. Expiry and revocation: tokens may be created with an expiration or with no expiration; Enterprise editions let an administrator enforce a maximum lifetime; tokens can be revoked at any time under My Account > Security, and a project analysis token stops working if its author loses Execute Analysis permission. SonarQube adds a SonarQube-Authentication-Token-Expiration header to API responses so a custody job can track upcoming expiry; an expired or revoked value fails closed. Note the gap honestly: revoking the service account's SESSION or changing its password does not invalidate already-issued tokens — revocation is per-token. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• sonarqube-instance (api, pii): https://sonarqube-server.invalid/api

The endpoint host 'sonarqube-server.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own SonarQube Server base URL before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. Parameter honesty: the registered paths are operation paths only — project, issue and gate selection are sent as caller-supplied form parameters (project, issue, gateName per each operation's parameter names), and nothing in this registration binds or records them at installation: they remain caller-controlled on every request unless a separately reviewed control restricts them. POST operations use application/x-www-form-urlencoded bodies per SonarQube's Web API guidance (parameters in the body, not the URI query string, so they are passed securely). Tiering rationale: collection reads (projects, issues) and single-resource reads (measures, quality gate status) sit at the R0 floor; issue transitions and quality gate assignment are reversible workflow/configuration updates at the R2 floor — but note honestly that transitioning a security issue to accepted or false-positive, or changing a project's quality gate, changes what the quality gate reports and can hide a real finding from release controls: the R2 floor is a minimum, and policy should scope these capabilities to named actors and projects. Project delete sits at the R3 floor: deleting a project removes it and its analysis history, and delete is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). Documented exclusions: this pack does not register user and group administration (api/users, api/user_groups), permission management (api/permissions — granting permissions is access-granting and needs its own review), token administration endpoints (api/user_tokens — token issuance and revocation are an external custody process, see the credential note), quality gate and quality profile creation/modification beyond project assignment (instance-wide governance settings), webhook management, analysis submission (the scanner's ce endpoints), and the X-Sonar-Passcode system authentication scheme (a server-wide passcode for monitoring endpoints, not a per-user credential — not registered). Source limitation, stated for the reviewer: SonarQube documents its web services in the running server's own /web_api console, which is client-rendered and could not be retrieved in this session (a further attempt against the public next.sonarqube.com /web_api console returned only the client shell); the operations registered here are the long-standing documented Web API operations per the fetched Web API extension guide and token documentation, and each path and parameter set must be confirmed against the target instance's own /web_api console before enabling — that confirmation is why this pack remains a draft.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://docs.sonarsource.com/sonarqube-server/latest/extension-guide/web-api/ (retrieved 2026-09-21)
• https://docs.sonarsource.com/sonarqube-server/user-guide/managing-tokens.md (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.