Security Hotspots, Vulnerabilities, Taint Analysis, and Review Workflow: Diagnostics, Failure Modes, and Production Practices

1. Evidence-first diagnostic sequence

1. Preserve scanner logs, report-task.txt, API/UI finding evidence, and the exact Git SHA.
2. Confirm Community Build/Server edition, version, instance mode, scanner, Java/runtime, and analyzer/plugin versions.
3. Confirm indexed files, source revision, effective parameters, quality profile, and active security rule.
4. Confirm report upload and Compute Engine task success.
5. Inspect the exact current finding representation: vulnerability/security issue, classic hotspot, migrated issue, or no finding.
6. Inspect rule context, primary/secondary flow locations, status, assignment, comments, rating/gate, and permissions.
7. Only then inspect network/auth/database/search/JVM/container state if analysis infrastructure is implicated.
8. Apply the least destructive correction and rerun the smallest equivalent fixture.

2. Failure: “There is no hotspot, therefore the pattern is safe”

In 2026 this conclusion can be wrong for at least four independent reasons:

• The rule was migrated from a hotspot into an ordinary security issue.
• The relevant rule is inactive in the project profile.
• The language/analyzer no longer uses that classification.
• The file was not indexed or the fixture does not match the rule.

Preserve the rule search, profile, scanner indexing log, and Issues view. Search current issues and rule metadata before assuming the old Hotspots surface should contain anything.

3. Failure: “No security findings means secure”

A clean static-analysis result proves only that the configured analyzers raised no findings in the analyzed scope under the current rules and version. It does not prove absence of business-logic flaws, runtime configuration weaknesses, dependency compromise, authentication mistakes, authorization bypasses, unmodeled injection flows, infrastructure exposure, or vulnerabilities outside supported languages/features.

4. Failure: using a public vulnerable target to “test SonarQube”

SonarQube analyzes source; this chapter does not need network exploitation. A deliberately vulnerable public service introduces authorization, safety, rate, and legal problems while teaching the wrong layer. Keep the insecure behavior as inert local source and let the analyzer inspect it.

5. Failure: embedding a real secret so the scanner can find it

Never use a real credential as test data. Use unmistakably fake values such as not-a-real-secret, and keep even fake tokens out of Git history when the exercise is about credential handling. The scanner token itself belongs in an environment variable or CI secret store, not in sonar-project.properties or shell history.

6. Failure: teaching commercial taint analysis as universal

If Community Build does not report a source-to-sink injection flow, that is not proof that the flow is safe or that the scanner is broken. Verify the product matrix. Current Sonar product material places injection-vulnerability taint analysis in Developer edition and above for selected languages. Use a manual source→sink diagram as the free fallback.

7. Failure: changing policy to make security evidence disappear

Reactive rule deactivation, broad exclusions, gate threshold lowering, mass acceptance, or mass false-positive marking can all make dashboards greener without changing code risk. These are governance changes and must be treated as such, with owners, rationale, scope, approval, and rollback—not as troubleshooting shortcuts.

8. Intentionally broken example: preserve the apparent contradiction

Symptom: An older tutorial predicts a Security Hotspot for a cookie-related pattern. On Community Build 26.9 the Hotspots view/API shows none, but the project has a new security issue with the same/related rule family.

git rev-parse HEAD | tee evidence/broken/revision.txt
cp .scannerwork/report-task.txt evidence/broken/report-task.txt

# Preserve the current issue population:
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/issues/search?componentKeys=$SONAR_PROJECT_KEY&ps=100" \
  > evidence/broken/issues.json

# Legacy endpoint may be deprecated/empty; preserve rather than treating emptiness as proof:
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/hotspots/search?projectKey=$SONAR_PROJECT_KEY&ps=100" \
  > evidence/broken/hotspots.json || true

Diagnosis: Confirm server version, inspect the rule key and tags/history, and compare with the 2026 hotspot-migration notice. If the finding migrated, the correction is not to re-enable an old UI; it is to update the runbook to the current issue workflow while preserving contextual-review rationale.

9. Causal failure map

10. Production anti-patterns to reject

• Do not delete projects to erase security history.
• Do not directly edit SonarQube database/search state.
• Do not disable TLS verification to “fix” scanner authentication.
• Do not use administrator tokens in routine analysis.
• Do not mass-suppress or mark findings false positive to make a gate green.
• Do not clear logs/caches before preserving first-failure evidence.
• Do not downgrade to an unsupported server/analyzer version as a shortcut.
• Do not replace a failing project key with a new one to reset history.

Knowledge check

Official references and version notes

• SonarQube downloads and edition matrix — Community Build 26.9.0.129388; Server 2026 Release 4.1; current LTA; Community Build basic vulnerabilities/hotspot review; Developer+ injection/taint analysis for selected languages.
• Managing Security Hotspots — conceptual difference between security issues/vulnerabilities and review-oriented security-sensitive findings.
• Security-related rules — security-rule categories and standards mapping.
• Moving Security Hotspots to Security Issues — 2026 migration plan, gate/metric implications, API deprecation, and status/history migration context.
• Current hotspot API source/changelog — api/hotspots/search is deprecated since 2026.4 in favor of security issues/vulnerabilities.
• Managing issues — current issue lifecycle, assignment, acceptance/false-positive semantics.
• Web API — bearer authentication and current API guidance.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used in the mandatory local workflow.