Change a Security Hotspot rule to be a Vulnerability rule

There is a rule that from the Security Hotspot that I will always want it to be fixed, but because it needs to be set to reviewed, it need to manual go to set is to be fixed.

Is there a way that I configured the rule as a Vulnerability or the rule can configured to be always need to be fixed?


Can you share the identifier of that particular Security Hotspot?


For example, Security Hotspot - csharpsquid:S2068 “Hard-coded credentials are security-sensitive”, this rule to us it is a violation of our coding practice and it is a must to be fixed, hence it does not need to be reviewed.

This rule is a little bit special and was debated a lot internally in the past. It was in the past a Vulnerability and we moved it to Hotspot. There is no doubt about the fact that having hard-coded credentials is not a good practice and that they should be removed because the code can leak or without leaking, some malicious person even if they are authorized person could make bad use of them.
The way the rule was designed, we can’t be 100% sure it highlights a real hardcoded password, this is why today we believe it’s better to keep it as a Hotspot so that a human can review, confirm and fix.

There is no way in SonarQube to change the type of a rule when you activate it in a Quality Profile.
The default Quality Profile forces all new Hotspots to be reviewed and you can enforce that all Hotspots must be reviewed to get a PASSED Quality Gate.

Hi Alexandre,

Thank you for your explanation.
However, it will be great if it could be configurable to individual business needs.
This will help to freed up time for the reviewers in reviewing only security hotspot rules that are defined by the company.

To reiterate what Alexandre said, they can’t really tell what’s genuinely being used as a password (see the Halting Problem) so they just look for strings like “PASSWORD” – so if you have code to generate a login page with a PASSWORD box, that will trip the rule. In our code, all hotspots generated by this rule are like this, so we marked them all safe. (On the plus side, I guess that means our devs know what they’re doing. :slight_smile: ) This is also true for the SQL injection hotspot: our code calls an internal object to get column names to form the string, and SQ can’t be sure there’s not a user pathway in there somewhere. So all our instances are actually OK, so we marked them safe.

I actually liked the hotspot category when it was introduced around 7.x or thereabouts, to separate “things we’re pretty sure are vulnerabilities” from “things we’re pretty sure are NOT vulnerabilities, but you’d better check anyway.” What I DON’T like is the way everything was totally broken in 8.x, e.g., a gratuitously different set of function calls in the web_api (so all our scripts had to be rewritten with 2x the code), eliminating most capabilities from hotspots (can’t filter any more, even by LANGUAGE???), changing to a completely different set of severities, etc.

So I upvoted this but the better solution would be to keep the hotspot designation but keep the old API.