Just looking into this feature in more detail - how do I find security hotspots that I’ve acknowledged across projects, and why do they not factor into the Security rating?
Current workflow:
After a SonarQube scan, there’s a new security hotspot to review. The Hotspots Reviewed rating jumps up, but the Security rating stays at A
I review the hotspot and, since it’s valid and needs to be fixed, I set it to “Acknowledged”.
Result: the Hotspots Reviewed rating goes back to A, the Security rating is still at A, and there’s no more mention of this security issue anywhere. Not in the project summary list, not in the Overall Code overview, not in the list of issues, or anywhere else where it would be obvious that there’s something left to fix.
The only way to find this hotspot again is to:
Remember that there was something to fix. This alone is impossible if someone else sets a hotspot to “Acknowldged” that I have no knowledge of.
Go into the project, then into the Security Hotspots tab, and then filter by “Acknowledged”.
Should this not show up in the Security rating? Or at least remain listed as a Security Hotspot, but with 100% of hotspots reviewed? What am I missing?
This is definitely a major failing in the product IMO - just because you have acknowledged an issue exists does not mean the code is suddently more secure - that will only happen when the issue is actually fixed.
Currently “acknowledged” essentially makes the issue disappear from all security reports as far as I can see so now we could be reporting to management (or indeed our customers who want to see our security reports) that the code is all green when actually we have merely acknowledged 50 serious security hotspots that still need to be worked on.
I strongly believe that “Acknowledged” issues should not change the security rating and cause them to “disappear”
The only status that should affect the security rating is “Safe” IMO:
To review = We haven’t looked at it yet, the issue still exists => The app is still at risk
Acknowledged = We have confirmed it is an issue, the issue still exists => The app is still at risk
Fixed = We believe we have fixed it but the issue may still exist (maybe our fix does not do what we want) => The app is still potentially at risk
Safe => We do not believe this is an issue => The app is not at risk.
If an issue is genuinely fixed, whether we have marked it fixed or not, I would expect that the issue goes away when the code is merged into main/master - simply marking it as fixed signals our belief that we fixed it, but really it only matters what Sonar thinks.
The other issue raised by the OP is that we can’t get a view across projects of security hotspots and their statuses like we can do with regular “Issues” where you just click the top level “Issues” menu item to get a view across all projects.
We should have the same for Security Hotspots
My idea:
I would expect that every acknowledged hotspot counts as vulnerability and that this given project has a rating of C (because auf acknowledged hotspot with review priority medium)
Hi @ganncamp - sorry to tag you directly, but you’ve been very helpful on a lot of topics over the years. How can we get someone from the product team to at least take a look at this issue? Maybe there’s something we’re all missing in the SonarQube configuration or UI that already addresses this?
Currently, this is creating security issues in our apps, which is the opposite of what we’re trying to achieve with SonarQube.
Thank you for raising this. It is an issue we are aware of, but we don’t have anything in our near-in roadmap to address it. You might be able to use the API to create reporting that somewhat helps with this, but it isn’t an ideal solution.
