Security Hotspots, Vulnerabilities, Taint Analysis, and Review Workflow: Core Concepts and Mental Model

1. The practical problem: “security finding” is not one workflow

Chapter 14 taught that SonarQube consumes evidence rather than magically discovering every external fact. Chapter 15 adds a second distinction: not every security-related result means the same thing or asks the team to perform the same action.

A vulnerability (called a Security Vulnerability in Standard Experience and a Security impact in MQR-oriented terminology) is a finding that indicates code requiring remediation. A classic Security Hotspot historically meant security-sensitive code that required human context before deciding whether it was safe or needed a fix. Advanced taint analysis adds another dimension: it reasons about data flowing from a source through transformations to a dangerous sink, and current Sonar product packaging makes this capability language- and edition-dependent.

2. Current 2026 reality: Security Hotspots are being migrated

For that reason, this course uses hotspot-style finding as the durable concept: a rule that historically asked for contextual review rather than immediate remediation. When your current instance still exposes a classic hotspot, preserve its review status/history. When the rule has already migrated, use the current issue workflow and record the rule key, issue type/impact, migration tag or history, and the contextual review rationale.

3. Mental model: finding type determines the next evidence

flowchart TD
  A[Local source revision] --> B[Security rules / analyzers]
  B --> C{Finding kind}
  C -->|Security issue / vulnerability| D[Remediate source]
  C -->|Hotspot-style| E[Contextual review]
  C -->|Taint-capable rule| F[Inspect source-to-sink flow]
  D --> G[Reanalyze]
  E --> G
  F --> D
  G --> H[Compute Engine result]
  H --> I[Issue state + security rating + gate]
  I --> J[Residual-risk / audit record]

The important causal rule is simple: the UI status does not replace code state. A finding can disappear because the code changed, because a rule/profile changed, because a scope/exclusion changed, or because workflow metadata changed. Those causes are not equivalent and must be distinguished by revision, effective configuration, and history evidence.

4. State map to capture before changing anything

5. Vulnerability/security issue: remediation is the default outcome

When the analyzer has enough evidence to raise a vulnerability/security issue, treat it as a code defect to investigate and normally fix. Do not downgrade it merely because exploitation is inconvenient in the current environment. Severity is prioritization metadata—not proof of exploitability and not permission to ignore a validated issue.

A proper remediation record pairs the finding with the exact source revision, the source change, a reanalysis task, and the post-analysis state. If the finding remains, the fix was incomplete or the issue has another cause. If it disappears, preserve the new revision and Compute Engine result so the disappearance is attributable to the code change rather than to a policy edit.

6. Hotspot-style finding: review context before disposition

The classic hotspot workflow exists because some security-sensitive constructs are not automatically vulnerable in every context. A secure cryptographic choice, cookie configuration, or permission boundary may depend on surrounding controls. Review therefore asks: what threat does this rule describe, what protection exists, and what evidence supports the conclusion?

7. Taint analysis: source → propagation → sink

Taint analysis follows untrusted or sensitive data through the program and looks for a dangerous sink without an adequate sanitizer. A useful finding shows more than a single line: it can show the source, intermediate propagation steps, and sink. This is especially valuable for injection classes because a sink is dangerous only when attacker-controlled data can actually reach it.

# Local teaching-only example. Do not expose as a service.
def run_report(user_value):
    # A taint-capable analyzer may reason about the flow:
    # user_value (source) -> command construction -> shell sink.
    import subprocess
    subprocess.run("report " + user_value, shell=True, check=False)

Current Sonar packaging lists injection-vulnerability taint analysis as a Developer-edition-and-above capability for selected languages including Java, C#, JavaScript/TypeScript, Python, PHP, Kotlin, Go, and VB.NET. Community Build remains the mandatory lab path, so this course does not promise that the example above will produce a flow finding locally. The local fallback teaches the source/sink reasoning manually and uses Community Build for the vulnerability/hotspot-style evidence it actually supports.

8. Security rating and Quality Gate evidence are consequences, not proof

A security rating summarizes analyzer findings under the current rule/profile/mode semantics. It does not test authentication design, runtime deployment, abuse cases, business logic, dependency compromise, infrastructure hardening, penetration resistance, or every exploitable path. Likewise, a passing Quality Gate means that the configured gate conditions passed for the analyzed population—not that the application is secure.

After every security change, preserve: scanner exit status, report-task.txt, Compute Engine task status, resulting issue/hotspot state, security measures, gate state, and the source revision. These facts may all differ.

9. Read-only inspection before any workflow action

git rev-parse HEAD
sonar-scanner --version

# After a scan, preserve the asynchronous task identity:
cat .scannerwork/report-task.txt

# Read-only system/version check:
curl -fsS "$SONAR_HOST_URL/api/system/status"

# Discover security-related rules in the current instance before selecting a fixture.
# Prefer the Rules UI when API fields differ across releases.
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/rules/search?languages=py&ps=100"

Do not begin by changing a rule, profile, gate, status, or exclusion. First capture what the current instance actually calls the finding and whether it exposes a classic hotspot object or a migrated issue.

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.