SonarSource added Security Hotspot detection to both SonarQube and SonarCloud, initially covering PHP, C#, T-SQL, VB.NET, Java, and Swift. The feature is designed to help development teams identify security-sensitive code paths early in the development process, without requiring a complete overhaul of existing CI/CD workflows.
Why Application Security Remains Difficult
Security breaches continue to rise despite broad industry awareness of the risks. The core challenge is straightforward to articulate but hard to solve: improving application security must not disrupt delivery velocity or overwhelm development teams with noise. Reducing vulnerabilities requires a repeatable, sustainable process rather than a one-time audit.
The development community has largely converged on a shift-left philosophy — catching defects, including security issues, as early as possible in the development lifecycle. SonarSource’s approach to this is pragmatic: use automated static analysis to flag both confirmed vulnerabilities and potential vulnerabilities (Security Hotspots), then route each category to the right person for action.
What Are Security Hotspots?
SonarQube and SonarCloud distinguish between two categories of security findings:
- Vulnerabilities — Confirmed security defects such as injection flaws, detected using techniques like taint analysis. These require immediate developer action.
- Security Hotspots — Security-sensitive sections of code through which a vulnerability could flow, but which require human review to determine whether they represent a real risk in context.
A Security Hotspot is not a confirmed bug; it is a signal that a particular code path deserves scrutiny. Think of it as automated triage: the tool highlights where a security reviewer should focus attention, rather than generating a blanket alert across the entire codebase.
Without this kind of guided detection, a security reviewer could spend weeks manually browsing code with no clear starting point. Hotspot detection solves that orientation problem.
How Security Hotspots Fit Into a Secure SDLC
The two-category model maps cleanly onto a Secure Software Development Lifecycle (SSDLC):
- Developers fix confirmed vulnerabilities in their normal development environment, treating them like any other blocking code quality issue surfaced by the CI pipeline.
- A security-focused reviewer assesses Security Hotspots, either a dedicated security engineer or a developer with a security specialisation. Confirmed findings cycle back to the development team for remediation.
This division of labour has practical advantages:
- It integrates with existing pull-request and CI workflows without requiring a separate toolchain.
- Noise is kept low because hotspots are scoped to genuinely sensitive code patterns, not every line of code.
- The cost is manageable — teams are not expected to remediate every theoretical risk at once.
- Developers gain security awareness over time by seeing which patterns are flagged and why, turning the tool into an educational resource.
SAST, DAST, and SCA: Where SonarQube Fits
Application security tooling is commonly divided into three categories:
- SAST (Static Application Security Testing) — Analyses source code or compiled binaries without executing the application. SonarQube and SonarCloud are SAST tools.
- DAST (Dynamic Application Security Testing) — Tests a running application from the outside (black-box testing). Operates downstream of the development team, typically against a staging environment.
- SCA (Software Composition Analysis) — Identifies known vulnerabilities in third-party libraries and open-source dependencies.
SonarSource’s stated focus at the time of this feature release was SAST, with SCA identified as a future direction. DAST remains a valuable complementary technique but sits later in the delivery pipeline and is harder to integrate into a developer’s inner loop. SAST, by contrast, can run on every commit and every pull request, making it a natural fit for shift-left security programmes.
None of these approaches eliminates the need for specialist security expertise. Hotspot review in particular benefits from someone with deep knowledge of common vulnerability patterns — the tool directs their attention efficiently; it does not replace their judgment.
Practical Checklist: Building an Effective AppSec Programme with SonarQube
SonarSource recommends combining the following practices:
- Act immediately on confirmed vulnerabilities. Block merges or flag builds when taint-analysis rules detect a definitive security defect.
- Fix issues where they are introduced. Developers should resolve confirmed vulnerabilities in their own branches rather than passing them downstream.
- Use Security Hotspot review to direct security expertise. Assign a reviewer — either a specialist or a security-aware team member — to assess hotspot findings on a regular cadence.
- Close the feedback loop. When a hotspot review confirms a real vulnerability, route it back to the development team as a tracked issue.
- Use the tool as a learning resource. SonarQube’s rule descriptions explain why a pattern is risky, helping developers build security awareness incrementally.
Language Coverage
At the time of the original announcement (January 2019), Security Hotspot detection was available for the following languages in both SonarQube and SonarCloud:
- PHP
- C#
- T-SQL
- VB.NET
- Java
- Swift
SonarSource indicated that new rules and additional language support would be added continuously. For the current, authoritative list of supported rules and languages, refer to the official SonarSource rules documentation at rules.sonarsource.com.
Summary
Security Hotspot detection represents a pragmatic middle ground in application security: more signal than a traditional vulnerability scanner, less noise than an exhaustive static analysis that flags every possible risk. By combining automated detection of confirmed vulnerabilities with guided hotspot review, teams can build a sustainable SSDLC that scales with their delivery process rather than fighting against it.
The approach is not a silver bullet — DAST, SCA, penetration testing, and specialist security reviews all still have a role — but it gives development teams a concrete, low-friction entry point into continuous application security.