Managing Security Hotspots
What is a Security Hotspot?
Security Hotspot highlights a security-sensitive piece of code that the developer needs to review. Upon review, you'll either find no threat, or you will need to apply a fix to secure the code.
Another way of looking at Security Hotspots is through the concept of Defense in depth (computing), in which several redundant protection layers are placed in an application so that it becomes more resilient in the event of an attack.
Please note that you may see different terminology depending on the configuration of your SonarQube Server instance. Security Vulnerability is displayed in Standard Experience and Security is shown in MQR Mode.
What are the differences between security issues and Security Hotspots?
The main difference between Security Hotspot and Security Vulnerability (in Standard Experience) or Security (in MQR Mode) is the need for review before deciding whether to apply a fix:
- With a Security Hotspot, a security-sensitive piece of code is highlighted, but the overall application security may not be impacted. It's up to the developer to review the code to determine whether or not a fix is needed to secure the code.
- With a Security Vulnerability (in Standard Experience) or Security (in MQR Mode), a problem that impacts the application's security has been discovered and needs to be fixed immediately.
An example of a Security Hotspot is the RSPEC-2092 where the use of a cookie secure flag is recommended to prevent cookies from being sent over non-HTTPS connections. A review is needed in this example because:
- HTTPS is the main protection against MITM attacks and so the secure flag is only additional protection in case of some failures of network security.
- The cookie may be designed to be sent everywhere (non-HTTPS websites included) because it's a tracking cookie or similar.
With Security Hotspots, we try to give users more freedom and educate them on how to choose the most relevant or appropriate protections depending on the context, for example, budgets and threats.
Why are Security Hotspots important?
While the need to fix individual Security Hotspots depends on the context, you should view them as an essential part of improving an application's robustness. The more you fix Security Hotspots, the more secure your code is in the event of an attack. Reviewing Security Hotspots allows you to:
- Understand the risk: Understanding when and why you need to apply a fix in order to reduce an information security risk (threats and impacts).
- Identify protections: While reviewing Security Hotspots, you'll see how to avoid writing code that's at risk, determine which fixes are in place, and determine which fixes still need to be implemented to fix the highlighted code.
- Identify impacts: With Security Hotspots, you'll learn how to apply fixes to secure your code based on the impact on overall application security. Recommended secure coding practices are included on the Security Hotspots page to assist you during your review.
Lifecycle
Security Hotspots have a dedicated lifecycle. You can make status changes, comment, and assign findings to users.
Statuses
Through the lifecycle, a Security Hotspot takes one of the following statuses:
- To review: The default status of new Security Hotspots set by SonarQube Server. Security Hotspot has been reported and needs to be checked.
- Acknowledged: A developer has reviewed the Security Hotspot and a resolution to the highlighted risk is pending. This covers cases where a fix is in progress or where time is needed to determine the next step.
- Fixed: A developer has reviewed the Security Hotspot and applied a fix.
- Safe: A developer has reviewed the Security Hotspot and determined that no change is necessary, for example, because other more relevant protections are already in place.
Workflow
Follow this workflow to review Security Hotspots and apply any fixes needed to secure your code.
Review Priority
When SonarQube Server detects a Security Hotspot, it is added to the list of Security Hotspots according to its review priority from high to low. Hotspots with a high review priority are the most likely to contain code that needs to be secured and require your attention first.
Review priority is determined by the security category of each security rule. Rules in categories that are ranked high on the OWASP Top 10 and CWE Top 25 standards are considered to have a high review priority. Rules in categories that aren't ranked high or aren't mentioned on the OWASP Top 10 or CWE Top 25 standards are rated as Medium or Low. Please see Security-related rules for more details.
Reviewing Security Hotspots
When reviewing a Security Hotspot, you should:
- Review the What's the risk? tab to understand why the Security Hotspot was raised.
- From the Assess the risk tab, read the Ask Yourself Whether section to determine if you need to apply a fix to secure the code highlighted in the Security Hotspot.
- From the How can I fix it? tab, follow the Recommended Secure Coding Practices to fix your code if you've determined it's unsafe.
After following these steps, set the Security Hotspot to the appropriate status (see above): Acknowledged, Fixed, or Safe. If you need another user’s review, you can leave it as To review.
Review Activity
The Activity tab shows the history of the Security Hotspot including the status it's been assigned and any comments the reviewer made about it.
Reviewing Security Hotspots in your IDE
Seeing a Security Hotspot directly in the IDE can help you better understand its context and decide whether it is safe or not. This is the purpose of the Open in IDE button that you'll see as an authenticated user.
This feature is available to users of:
- SonarQube for IntelliJ 4.13 and above
- SonarQube for Visual Studio 4.29 and above
- SonarQube for VS Code 1.20 and above
- SonarQube for Eclipse 5.7 and above
It’s best if your project is already open in the appropriate IDE and bound to the server through SonarQube for IDE's Connected Mode before selecting the Open in IDE button. With SonarQube for IntelliJ, VS Code, and Eclipse, Automatic Connected Mode setup is available; to use the Open in IDE feature with SonarQube for Visual Studio, you will need to have already set up Connected Mode beforehand.
Keep in mind that the revision or branch analyzed by SonarQube Server may not be the same as what you have opened in the IDE. In this case, SonarQube for IDE will do its best to locate the Security Hotspot in your local code.
Was this page helpful?