SonarQube Security Hotspots: Review and Triage Security-Sensitive Code

What Triggers a Security Hotspot

SonarQube flags code patterns that are security-sensitive but context-dependent. Whether they're actually vulnerable depends on how they're used:

Reviewing Hotspots in the SonarQube UI

The Hotspot Review Workflow

1. Navigate to your project → Security Hotspots tab
2. Each hotspot shows: the code, the risk category, why it was flagged
3. Review the code in context
4. Mark it as:
   • Safe: Code is fine as-is. The pattern looks risky but it's not in this context.
   • Fixed: You changed the code to eliminate the risk.
   • Acknowledged: The risk is real and accepted (document why).

Reading the Hotspot Details

Each hotspot includes:

• What's the risk: Explains the vulnerability class
• Are you at risk?: Questions to ask when reviewing
• Is this a false positive?: Common legitimate uses that trigger this pattern

Example: MD5 hotspot

What's the risk?
Using MD5 in a security context (passwords, signatures) is cryptographically weak.

Are you at risk?
- Is this used for password hashing? YES: Use bcrypt instead.
- Is this used for digital signatures? YES: Use SHA-256 or better.
- Is this used as a non-security hash (cache keys, ETags)? NO risk.

Is this a false positive?
If the MD5 output is used purely for cache invalidation or content addressing
and never in a security context, mark as Safe.

Hotspot Status in CI

By default, hotspots don't affect the quality gate. To require all hotspots to be reviewed:

Quality Gates → Your Gate → Add condition:

On New Code: Security Hotspots Reviewed = 100%

Now your quality gate fails if any new hotspot is left TO_REVIEW.

In your CI pipeline:

- name: SonarQube Scan
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
  run: |
    mvn sonar:sonar \
      -Dsonar.qualitygate.wait=true

sonar.qualitygate.wait=true makes the build wait for the analysis to complete and fail if the quality gate fails (including the hotspot review condition).

Bulk Triage

For legacy codebases with many hotspots, bulk review them:

1. Go to Security Hotspots → Filter by category
2. Select all hotspots of a type you've audited
3. Mark all as Safe (or Fixed/Acknowledged)

Document your decision in the comment: "Reviewed 2026-06-02: All SHA1 usages in this module are for content addressing, not security. Safe."

Suppressing False Positives in Code

For code you've confirmed is safe, suppress the hotspot with a @SuppressWarnings annotation or NOSONAR comment:

// Java: suppress with annotation
@SuppressWarnings("java:S2245") // Math.random() used for non-security shuffle
public void shuffleItems(List<Item> items) {
    Collections.shuffle(items, new Random());
}

// JavaScript: inline suppression
const cacheKey = crypto.createHash('md5').update(content).digest('hex'); // NOSONAR: MD5 for cache key only

Use NOSONAR sparingly — it suppresses all issues on that line, not just the hotspot.

Common Hotspot Decisions

Math.random() / new Random()

• Safe if: generating test data, shuffling a playlist, assigning random IDs in non-security contexts
• Fix if: generating session tokens, password reset links, CSRF tokens (use SecureRandom in Java, crypto.randomBytes in Node)

MD5 / SHA1

• Safe if: cache keys, ETags, file deduplication, non-security content addressing
• Fix if: password storage (use bcrypt/Argon2), HMAC signatures (use SHA-256 minimum)

SQL String Concatenation

• Safe if: the variable comes from a trusted internal source (enum, constant)
• Fix if: any part comes from user input — use parameterized queries

Access-Control-Allow-Origin: *

• Safe if: public API that intentionally serves all origins
• Fix if: API handles authenticated resources — specify allowed origins explicitly

File Path from User Input

• Safe if: the path is validated against a whitelist before use
• Fix if: user input goes directly into file operations — validate and canonicalize

Hotspot Review as Part of Code Review

Make hotspot review a gate in your pull request process:

1. Developer opens PR with new hotspots
2. CI runs SonarQube with sonar.qualitygate.wait=true
3. Quality gate requires 100% hotspots reviewed
4. Developer reviews and marks hotspots in SonarQube
5. CI re-runs or quality gate re-evaluates
6. PR merges only when all hotspots are resolved

This embeds security review into the development workflow without a separate security review phase.

Summary

Security hotspots are intentionally not vulnerabilities — they're a prompt to think, not a guaranteed bug. The review workflow makes that thinking auditable.