Security Hotspots should be reviewed and marked as “safe”. The user changing the status/resolution may leave a blank comment without justifying why the hotspot can be marked as “safe”.
We want to get this field to be mandatory or at least let the admins configure it to be mandatory in SonarCloud/SonarQube.
Why does this matter to you?
Because we noticed that most of the reviewers are marking hotspots as safe without writing why it is safe.
How would that look in SonarCloud? Alternatives?
It should be an option in admin section where the organization admins can enable the mandatory field for security hotspots.
How would we know it works well?
Enabling this option will allow to force comments in security hotspots reviews. We think that the result of the review should be always registered in the hotspot itself.
Why should it be a priority now?
Because a lot of hotspots are being closed without a comment explaining why the hotspot is marked as safe. Customers are missing a lot of security-sensitive information that should be on the reviewed hotspots.
So far, we took the approach of trusting developers, and indeed it’s not required to share a justification for why a Hotspot or an Issue is marked as “Safe” or “Won’t Fix”.
We expect developers to see the value of the raised Hotspots or Issues and that they won’t play against the rules, they won’t cheat to get a PASSED quality gate.
I understand why you would expect to force developers to put a comment. I’m just afraid about the quality of the comments you’ll get.
Anyway, let’s monitor this need and see if other users have the same.
Just for you to know, I also think comment should be mandatory in order to mark a security hotspot as safe.
Nobody should be marking those as safe if they don’t know what they are doing. In order to ensure the person is actively reviewing the sec-hotspot is to force them to write a few lines justifying it.
I think also this is more important nowadays we are adopting an ‘Accepted’ state on issues also.
Why are they accepted?
Which consecuences may we face if we don’t fix it?
Until when will this be permissible?
I believe we should need to think about those things.
I would also like to push for this feature (maybe making it configurable). Depending on the industry, adding a reason when accepting an issue may be mandatory from an auditing and compliance point of view. This is a real use case and would love to be considered in SonarQube.