TL;DR overview
- In SonarQube's quality model, bugs, vulnerabilities, and code smells are all first-class citizens—each representing a distinct type of risk with its own detection rules and severity levels.
- Bugs are coding mistakes that will or may cause incorrect behavior; vulnerabilities are security weaknesses that could be exploited; code smells are maintainability issues that increase long-term technical debt.
- This three-tier model allows SonarQube to give development teams targeted feedback: security teams focus on vulnerabilities, QA teams focus on bugs, and architects track code smells.
- Understanding the distinction between these issue types helps teams prioritize remediation effectively and communicate the real-world risk of code quality problems to both technical and non-technical stakeholders.
In SonarQube Server 5.5 we adopted an evolved quality model, the SonarQube Server Quality Model, that takes the best from SQALE and adds what was missing. In doing so, we've highlighted project risks while retaining technical debt.
Why? Well, SQALE is good as far as it goes, but it's primarily about maintainability, with no concept of risk. For instance, if a new, blocker security issue cropped up in your application tomorrow, under a strict adherence to the SQALE methodology you'd have to ignore it until you fixed all the Testability, Reliability, Changeability, &etc issues. When in reality, new issues (i.e. leak period issues) of any type are more important than time-tested ones, and new bugs and security vulnerabilities are the most important of all.
Further, SQALE is primarily about maintainability, but the SQALE quality model also encompasses bugs and vulnerabilities. So those important issues get lost in the crowd. The result is that a project can have blocker-level bugs, but still get an A SQALE rating. For us, that was kinda like seeing a green light at the intersection while cross-traffic is still flowing. Yes, it's recoverable if you're paying attention, but still dangerous.
So for the SonarQube Server Quality Model, we took a step back to re-evaluate what's important. For us it was these things:
- The quality model should be dead simple to use
- Bugs and security vulnerabilities shouldn't be lost in the crowd of maintainability issues
- The presence of serious bugs or vulnerabilities in a project should raise a red flag
- Maintainability issues are still important and shouldn't be ignored
- The calculation of remediation cost (the use of the SQALE analysis model) is still important and should still be done
To meet those criteria, we started by pulling Reliability and Security issues (bugs and vulnerabilities) out into their own categories. They'll never be lost in the crowd again. Then we consolidated what was left into Maintainability issues, a.k.a. code smells. Now there are three simple categories, and prioritization is easy.
We gave bugs and vulnerabilities their own risk-based ratings, so the presence of a serious Security or Reliability issue in a project will raise that red flag we wanted. Then we renamed the SQALE rating to the Maintainability rating. It's calculated based on the SQALE analysis model (technical debt) the same way it always was, except that it no longer includes the remediation time for bugs and vulnerabilities:
To go help enforce the new quality model, we updated the default Quality Gate:
- 0 New Bugs
- 0 New Vulnerabilities
- New Code Maintainability rating = A
- Coverage on New Code >= 80%
The end result is an understandable, actionable quality model you can master out of the box; quality model 2.0, if you will. Because managing code quality should be fun and simple.