Security Hotspots, Vulnerabilities, Taint Analysis, and Review Workflow: Configuration, Design Patterns, and Trade-Offs

1. Design principle: security policy must survive UI and taxonomy changes

The durable policy is not “click Safe in the Hotspots tab.” The durable policy is: identify the exact security-sensitive finding, determine whether remediation or contextual review is required, record the evidence and owner, then prove the next analysis state. That remains valid even while Sonar migrates hotspot objects into the ordinary issue model.

2. Vulnerability versus hotspot-style review

3. Direct pattern matching versus taint/data-flow analysis

Some security rules can decide from local syntax or local semantic context. Others need interprocedural data-flow reasoning. Taint analysis follows a value from a source to a sink and may need to understand sanitizers, control flow, framework APIs, and multiple methods/files.

flowchart LR
  S[Untrusted input / source] --> P1[Assignment / parameter]
  P1 --> P2[Transformation]
  P2 --> Q{Sanitized?}
  Q -->|No| K[Dangerous sink]
  Q -->|Yes| Z[Flow considered protected]

Do not infer that a Community Build rule with one location is “inferior” or that every Developer-edition finding is exploitable. The two analyzers answer different questions. Verify the current supported language/edition matrix and inspect the actual flow evidence.

4. Community Build versus commercial advanced-security capability

5. Review design patterns

6. Security rating, hotspot review percentage, and migration

Older/current-overlap releases may expose both security ratings and Security Hotspot review measures. Sonar’s 2026 migration plan states that former hotspot findings will ultimately become ordinary security issues/vulnerabilities and affect the existing security rating, while hotspot-specific measures are being removed. Therefore:

• Record the exact server/community release and instance mode.
• Do not compare pre-migration hotspot-review percentages directly with post-migration security ratings as if the metric definition were unchanged.
• Do not silently edit a gate because migration increases security-issue counts.
• Document the product migration as a measurement-definition change.

7. Worked decision table

8. Governance record template

finding_key:
rule_key:
representation: vulnerability | classic hotspot | migrated security issue | taint finding
server_version:
instance_mode:
edition:
language/analyzer:
revision:
decision: fixed | contextual-safe | accepted-temporarily | false-positive
evidence:
reviewer:
expiry_or_revisit_trigger:
post_analysis_task:
post_analysis_status:
residual_risk:

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.