We’ve decided to phase out the concept of Security Hotspots. By July 1st, 2026, all hotspots will be rewritten as issues impacting the software quality security. This means all security findings will finally be in one place and not split between the Issues and the Hotspots tab.
Why we are doing this:
Confusion:
Most of you did not catch the difference between a “hotspot” and an “issue” and we had to explain it many times which is a sign that something was wrong.
Hotspots were not made compatible with the Clean Code taxonomy and the MQR mode adding to the confusion.
Visibility: Many users miss the hotspots tab. This makes them think we find fewer security problems than others while the findings were in the hotspots tab.
Value: Because they are in a separate tab, users think these findings are less important.
Market Standard: No one else in the industry uses “hotspots”. The concept never became popular outside of Sonar.
We know this works:
We have already started this process with good results:
We migrated PHP hotspots to security issues
We migrated secret rules (S2068 and S6418) for almost all languages. We have received no negative feedback so far. The feedback we received was good one and we fix the mistake.
What I should do:
If you have any concerns or questions about this migration, please let us know here or via private message.
We will do our best to ensure there is no negative impact on you, such as making sure that existing hotspots are not reopened as new security issues.
The only anticipated side effect is a positive one: some projects may now fail their quality gates. This is because what was previously classified as a “hotspot” to review is now a “security issue” to fix which may cause a quality gate to fail. Overall, this is beneficial as it will make your projects more secure.
Timeline:
The full rewrite will happen during Q2 2026. Our goal is to finish everything by July 1st.
This change will make the product simpler and ensure you better see the full value of our security findings in one view.
Good, this was an unnecessary complexity in the reporting of issues to end users also the remediation process wasn’t in parity with fixing issues from the IDE perspective so it’ll be good to have these all in the same house now.
One thing that isn’t noted here is how will this impact quality gate measurements for enforcement purposes? Today There are conditions for Security Hotspot Reviewed as well as a security rating; will new measures just be attached to the Security Rating letter grade assigned to the scan result?
Thanks for asking the question on the impact on Quality Gate. Since Security Hotspots will now be vanilla Vulnerabilities (Standard Mode) or Security Issues (MQR), they will impact the existing Security Rating. All measures related to Hotspots will be removed once the migration is done.
In Q2, the api/hotspots will be marked as deprecated to be sure a maximum of users see it.
By the end of Q2, all new Hotspots will be actually created as Security Issues.
During Q3, existing Hotspots will be bulk migrated as Security Issues.
At this moment, the api/hotspots endpoints will return nothing.
As per our policy, we can drop a public API if its deprecation was announced at least 180 days before the drop.
I think we will drop the API, 180 days after we reach the “api/hotspots endpoints returns nothing” phase.
We would like to understand the impact on the lifecycle and status transitions when converting Security Hotspots into Security Issues.
Specifically:
How does the status mapping work between hotspots and issues (e.g., To Review, Acknowledged, Safe vs Open, Confirmed, Fixed, False Positive, etc.)? We understand that hotspots and issues have different states, so we would like to clarify how this transition is handled.
What happens to the review history and comments when a hotspot is converted?
We want to better understand how this would affect our current process and lifecycle handling for both Security Hotspots and Security Issues.
The existing review history and comments will be remain attached to the migrated security issue. The migrated security issue will add an extra tag former-hotspot on it so it’s easier for you to find issues that were before hotspots.
There is a plan (not yet announced) to release a SQS LTA in Sept 2026. We expect to be done with the work of Hotspots migration for this version.
Our plan “During Q3, existing Hotspots will be bulk migrated as Security Issues” is still valid.
, all hotspots will be rewritten as issues impacting the software quality security. This means all security findings will finally be in one place and not split between the Issues and the Hotspots tab.