Change in Issue severities

SonarQube Server / Community Build
1

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension) --v2026.1 (119033)
  • what are you trying to achieve --Sonar scan runs in every PR and quality gate fails for blocker , critical issues
  • what have you tried so far to achieve this --Sonar rules severties are adapted as per our standards to enforce quality gate failure to block merging

We have enforced Sonar scan in PR and we blocks pipeline if quality gate fails for any security vulnerability or blocker , critical , major issues. But while testing what we have noticed that if any issue is reported as blocker , we can change the severity of issue in Sonar " Issues" view which will then impact the quality gate status . For example if quality gate has failed with blocker issues , you can adapt severity of issues to minor which will turn quality gate to green and can merge PR . Do note the rule severity will remain intact only the issue severity can be adapted for that PR. Is this expected behavior of Sonar ? If yes then what is the purpose of allowing the user to change severties of issues instead they should resolve the issue and mark as Fix or Accept ? Please help on this as it is becoming a big concern.

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

2

Hey @Roopali, yes, this is expected behavior, changing the severity of an issue is a feature of SonarQube. The point is that there are particular instances of a given rule that, based on the context, may be more or less severe. You can read about it in our docs.

However, the ability to do this is controlled by a permission: the Administer Issues permission. This is a project-level permission so a project admin can configure it on a per-project basis, and an instance admin can also configure it in the permission templates, to control what will be the default value for newly created project.

So if you don’t want your users to misuse this feature, you could consider revoking their Administer Issues permission.