Your security team flagged 50 'Security Hotspots' in a SonarQube scan of your payment service. How do security hotspots differ from vulnerabilities, and what is the review workflow?
Quick Answer
Vulnerabilities are confirmed security weaknesses that need fixing. Security hotspots are security-sensitive code that MIGHT be vulnerable depending on context - they require human review to determine if the usage is safe. The workflow is: review the hotspot context, decide Safe/Fixed/Needs-to-Fix, and document the rationale.
Detailed Answer
Hotspots vs Vulnerabilities
Vulnerabilities are issues SonarQube is confident are exploitable (e.g., SQL concatenation with user input = definite SQL injection). Security hotspots are code patterns that CAN be insecure depending on context, but SonarQube cannot determine safety automatically. Examples: using a cryptographic algorithm (is the key strength adequate?), configuring CORS (are the allowed origins correct?), using regular expressions (is it vulnerable to ReDoS?). A hotspot is a question: 'Did the developer think about security here?'
Review Workflow
Security hotspots have three review statuses: (1) To Review (new, unreviewed), (2) Acknowledged (someone looked at it), and three resolution states: Safe (reviewed, the usage is secure in this context), Fixed (was insecure, now remediated), or Needs to Fix (confirmed insecure, needs remediation). The reviewer must have the 'Administer Security Hotspots' permission. Reviews should include a rationale comment explaining WHY the code is safe.
Triage Strategy
For 50 hotspots in a payment service, prioritize by: (1) Category - cryptography and injection-related hotspots first, (2) OWASP Top 10 mapping - prioritize A1 (Injection) and A2 (Broken Auth), (3) Data sensitivity - code handling PCI data takes precedence. Assign hotspot review to developers familiar with the code (they have context) with security team oversight. Set a review SLA: all hotspots in payment services reviewed within one sprint.
Quality Gate Integration
The default Quality Gate condition 'All Security Hotspots Reviewed' blocks deployment until every hotspot has been reviewed. For new code, this ensures no security-sensitive code ships without human review. This is distinct from the zero-vulnerabilities condition - both must pass.
Code Example
# List unreviewed security hotspots via API
curl -u admin:$TOKEN \
"https://sonar.company.com/api/hotspots/search?project=payment-service&status=TO_REVIEW" \
| jq '.hotspots[] | {key: .key, message: .message, file: .component, category: .securityCategory, vulnerability: .vulnerabilityProbability}'
# Example hotspot categories:
# - sql-injection: "Make sure this SQL query is safe"
# - crypto: "Make sure this cipher algorithm is safe here"
# - cors: "Make sure CORS policy is restrictive enough"
# - xpath-injection: "Verify XPath expression is safe"
# - auth: "Make sure authentication is properly implemented"
# Review a hotspot - mark as Safe with comment
curl -u admin:$TOKEN -X POST \
"https://sonar.company.com/api/hotspots/change_status" \
-d "hotspot=AXk1_hotspot_key&status=REVIEWED&resolution=SAFE&comment=Using+parameterized+query+with+PreparedStatement.+Input+is+validated+by+PaymentValidator+class+before+reaching+this+code."
# Review a hotspot - mark as needs fixing
curl -u admin:$TOKEN -X POST \
"https://sonar.company.com/api/hotspots/change_status" \
-d "hotspot=AXk2_hotspot_key&status=REVIEWED&resolution=FIXED&comment=Migrated+from+DES+to+AES-256-GCM.+See+PR+#542."
# Common Security Hotspot rules (Java):
# java:S2077 - SQL queries should not be built dynamically
# java:S4790 - Cryptographic hash function usage
# java:S5542 - Encryption algorithm weakness
# java:S5344 - Password hashing
# java:S5122 - CORS configuration
# java:S4502 - CSRF protection disabled
# java:S2245 - Pseudorandom number generators (PRNG)
# Hotspot review metrics for management
curl -u admin:$TOKEN \
"https://sonar.company.com/api/measures/component?component=payment-service&metricKeys=security_hotspots,security_hotspots_reviewed,security_review_rating" \
| jq '.component.measures[]'
# Example: Code that triggers a crypto hotspot
// This triggers hotspot java:S5542
Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding"); // ECB mode is weak
// Reviewer decision: FIXED - changed to:
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
GCMParameterSpec spec = new GCMParameterSpec(128, iv);
cipher.init(Cipher.ENCRYPT_MODE, key, spec);
# Quality Gate condition for hotspot review
curl -u admin:$TOKEN -X POST \
"https://sonar.company.com/api/qualitygates/create_condition" \
-d "gateName=Team-Standard&metric=new_security_hotspots_reviewed&op=LT&error=100"Interview Tip
The key insight: vulnerabilities are confirmed issues (fix them), hotspots are questions (review them). Interviewers want to hear that you understand the DIFFERENCE and that hotspots require security context that static analysis cannot determine automatically. Mention the review rationale documentation as an audit trail.