This is an archived version of the documentation for SonarQube-7.3.
See the Latest Documentation for current functionality.

Rules Types and Severities

How are rules categorized?

The SonarQube Quality Model divides rules into four categories: Bugs, Vulnerabilities, Security Hotspots and Code Smells. Rules are assigned to categories based on the answers to these questions:

Is the rule about code that is demonstrably wrong, or more likely wrong than not?
If the answer is "yes", then it's a Bug rule.
If not...

Is the rule about code that could be exploited by a hacker?
If so, then it's a Vulnerability rule.
If not...

Is the rule about code that is security-sensitive?
If so, then it's a Security Hotspot rule.
If not...

Is the rule neither a Bug nor a Vulnerability?
If so, then it's a Code Smell rule.

How are severities assigned?

To assign severity to a rule, we ask a further series of questions. The first one is basically:

What's the worst thing that could happen?
In answering this question, we try to factor in Murphy's Law without predicting Armageddon.

Then we assess whether the impact and likelihood of the Worst Thing (see How are severity and impact decided?, below) are high or low, and plug the answers into a truth table:

impact

likelihood

Blocker

images/s/en_GB/7402/131c587a84e4ee088cb3d1cec7ecd765481c9c79/_/images/icons/emoticons/add.png

images/s/en_GB/7402/131c587a84e4ee088cb3d1cec7ecd765481c9c79/_/images/icons/emoticons/add.png

Critical

images/s/en_GB/7402/131c587a84e4ee088cb3d1cec7ecd765481c9c79/_/images/icons/emoticons/add.png

images/s/en_GB/7402/131c587a84e4ee088cb3d1cec7ecd765481c9c79/_/images/icons/emoticons/forbidden.png

Major

images/s/en_GB/7402/131c587a84e4ee088cb3d1cec7ecd765481c9c79/_/images/icons/emoticons/forbidden.png

images/s/en_GB/7402/131c587a84e4ee088cb3d1cec7ecd765481c9c79/_/images/icons/emoticons/add.png

Minor

images/s/en_GB/7402/131c587a84e4ee088cb3d1cec7ecd765481c9c79/_/images/icons/emoticons/forbidden.png

images/s/en_GB/7402/131c587a84e4ee088cb3d1cec7ecd765481c9c79/_/images/icons/emoticons/forbidden.png

How are severity and likelihood decided?

To assess the severity and impact of a rule, we start from the Worst Thing (see How are severities assigned?, above) and ask category-specific questions.

Bugs

Severity: Could the Worst Thing cause the application to crash or to corrupt stored data?
Yes = high

Likelihood: What's the probability that the Worst Thing will happen?

Vulnerabilities

Severity: Could the exploitation of the Worst Thing result in significant damage to your assets or your users?

Likelihood: What is the probability that a hacker will be able to exploit the Worst Thing?

Security Hotspots

Security Hotspots are not assigned severities as it is unknown whether there is truly an issue until review by a Security Auditor. When an auditor converts a Security Hotspot into a Vulnerability, severity is assigned based on the identified Vulnerability (see above).

Code Smells

Severity: Could the Worst Thing lead a maintainer to introduce a bug?

Likelihood: What's the probability that the Worst Thing will happen?