Moving Security Hotspots to Security Issues

Sonar Updates
, ,
1

Hi everyone,

We’ve decided to phase out the concept of Security Hotspots. By July 1st, 2026 :crossed_fingers:, 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.

Alex

5 Likes
2

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?

3

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.

4

Good decision. One question: how will the API endpoints (api/hotspots) be phased out?

5

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.

6

Hi Alexandre, thanks, we can work with that!