How are rules categorized?

The SonarQube Quality Model divides rules into three categories: Bugs, Security Vulnerabilities, 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 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
Critical
Major
Minor

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?

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?