SonarQube

SonarQube is SonarSource’s code quality and security platform, available as a self-hosted server (Community Build, Developer, Enterprise and Data Center editions), as the hosted SonarQube Cloud, formerly SonarCloud, and as the SonarQube for IDE editor plugins, formerly SonarLint. In a pipeline the scanner runs in CI, pushes an analysis to the server, and the server computes the quality gate. Everything the practitioner reads lives on the server, and that architecture is what decides its grades here.

How it is conformant

Bespoke rules are supported and documented (4.1) by three routes: a Java plugin against the plugin API for Java, PHP, Python, COBOL and RPG; rule templates instantiated in the web interface; and the Generic Issue Import Format for reports produced by any external tool, all on adding coding rules and available in the Community Build. The Java plugin route has a real proving harness (4.2): CheckVerifier runs one check against one file annotated with // Noncompliant markers, per Custom Rules 101. Rule keys are stable and author-chosen: @Rule(key = "...") becomes a repository:key identifier such as java:S2259, the same string used in @SuppressWarnings("java:S2077") (advanced exclusions). Rule documentation is keyed on that key at rules.sonarsource.com and on the server’s Rules page, which is the form 6.1 accepts even though it is not on disk. SonarQube ships rules that track its own suppression comments, S1291 for NOSONAR and S1309 for @SuppressWarnings and noqa (tracking inline comments), so the inline route is detectable by a rule the detector itself ships, which meets 7.1, though they are off by default.

How it is not conformant

Clause 5.1 is failed structurally. The SonarScanner CLI requires sonar.host.url and a token, sends the report to the server, and prints no findings: the result reaches the practitioner on a web page, not in the output of the command they ran, which fails 5.3 too, and because the scanner prints nothing the stable rule key is never printed with a finding, so 4.3 is only partly met. SonarQube for IDE runs standalone with built-in rules only; custom plugin rules require Connected Mode and a compatibility flag in the plugin manifest (connected mode), so a bespoke defence fires only through a hosted or self-run server the practitioner may not have, which is precisely the hosted-service condition 5.4 forbids. The one server-free terminal mode, sonar analyze secrets in the new SonarQube CLI, covers secrets detection only (secrets detection). The single-rule, single-file run exists only inside a Java unit test, hence the amber readiness and a partial 5.2. No offline resolver from the installed scanner is documented, so 6.2 is failed; each analyser plugin bundles per-rule HTML, but whether it is reachable from the installed copy without the server is not verified (6.3), and no release gate on rule documentation is documented (6.4). NOSONAR and @SuppressWarnings carry no reason, and marking an issue Accepted or False Positive in the interface takes an optional comment, so 7.2 is not met. There is no rule over the rules (4.4).

Clause by clause

Notes for a practitioner

Treat SonarQube as the server-side gate and keep the method’s loop somewhere the practitioner can run: write the class rule in a local detector such as PHPStan, ESLint or Semgrep, prove and sweep it there, and feed its report into SonarQube through the Generic Issue Import Format so the quality gate blocks on it. If the rule must be a Sonar plugin rule, prove it red in a CheckVerifier test, and enable S1291 and S1309 as blocking so inline suppression is at least visible.