Upgraded from 9.9 to 10.4.1, I am now struggling to find my vulnerabilities as previously listed

Must-share information (formatted with Markdown):

  • which versions are you using SonarQube 10.4.1
  • how is SonarQube deployed: Docker, running in AWS Fargate
  • what are you trying to achieve: I am trying to see how I view security vulnerabilities as I did in the 9.9 version.
  • what have you tried so far to achieve this: I have searched through all the available tabs within the 10.4.1 version of SonarQube and found security vulnerabilities. However these numbers do not match what was previously there and all of them are listed as Medium findings, when I know we had a handful of Critical and High findings previously.

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

Hey there.

The Upgrade Notes should help you understand the changes we’re making in the 10.x version of SonarQube.

Clean Code updates

The classification of issues and rules has evolved:

  • Issue types are deprecated. Issues are now classified based on Clean Code attributes and software qualities.
  • The severity of an issue is now tied to the issue’s impact on the software qualities.

Existing types and severities are preserved and are still used to evaluate the Quality Gate conditions. Type and severity can no longer be edited on issues and rules via the UI.

For details, see Issues and Clean Code. (SONAR-20023)

Don’t hestiate to give us your feedback.

Thank you for the response,

Does this mean that you are no longer looking into security vulnerabilities and attributing criticality based on that? I see a lot about ensuring clean code so I just want to make sure that from a security perspective I am looking at the correct things.


A secure application is the outcome of Clean Code. We’re now choosing to focus on secure coding practices (what does secure code look like, how do developers write secure code, how to fix code that could lead to security issues), rather than declaring that a codebase has x number of vulnerabilities.

While issues no longer have an issue type (like bug, vulnerability, and code smell), issues now contribute to various software qualities (like Maintainability, Reliability, and Security).

Why does this matter? The old model meant that a rule could raise an issue that is a Bug, a vulnerability, or a Code Smell. This was limiting – an out-of-bounds access could be both a bug and a vulnerability. Our new model means that a single issue can contribute to multiple software qualities.

The old model also meant it was hard to introduce new concepts like Sustainability (“Green” code) without creating new issue types. Now we can explore new domains without creating a dozen issue types.

Functionally, on the Issues tab of your project/instance, you can filter by Software Quality (like on our own instance, filtering to Security. If something is missing, let us know.

Additionally, I’m new to explaining this change (we all are), so if anything is unclear please let’s keep discussing!