Rules

Overview

In SonarQube Cloud, analyzers contribute rules executed on source code to generate issues. There are four types of rules:

• Code smell (maintainability domain)
• Bug (reliability domain)
• Vulnerability (security domain)
• Security hotspot (security domain)

For code smells and bugs, zero false-positives are expected. At least this is the target so that developers don't have to wonder if a fix is required.

For vulnerabilities, the target is to have more than 80% of issues be true-positives.

Security hotspot rules draw attention to code that is security-sensitive. The hotspots identified by the rules must be reviewed and flagged as safe or a fix applied.

The Sonar Rules catalog is the entry point where you can discover all the existing rules.

Rules

You can access the Rules top menu only from within your organization. By default, when entering the top menu item "Rules," you will see all the available rules brought by the analyzers available on SonarQube Cloud. You can narrow the selection based on search criteria in the left pane:

• Language: the language to which a rule applies.
• Type: bug, vulnerability, code smell, or security hotspot rules.
• Tag: it is possible to add tags to rules in order to classify them and to help discover them more easily.
• Repository: the engine/analyzer that contributes rules to SonarQube Cloud.
• Default severity: the original severity of the rule - as defined by the analyzer that contributes this rule.
• Status: rules can have 3 different statuses:
  • Beta: The rule has been recently implemented and we haven't gotten enough feedback from users yet, so there may be false positives or false negatives.
  • Deprecated: The rule should no longer be used because a similar, but more powerful and accurate rule exists.
  • Ready: The rule is ready to be used in production.
• Security category: security rules are classified according to well-established security standards such as:
  • CWE
  • OWASP Top 10 
• Available since: the date when a rule was first added on SonarQube Cloud. This is useful to list all the new rules since the last upgrade of a plugin for instance.
• Quality Profile: inclusion in or exclusion from a specific profile.
• Inheritance: available when an inherited quality profile is selected. It can filter inherited rules, other rules, or inherited rules that have been overridden by other settings. 
• Activation severity: available when an inherited quality profile is selected. It can filter by severity using the value chosen when the rule was activated in the quality profile. 

For more detailed information on the use of rules in Quality Profiles, see the Quality profiles page.

Rule details

To see the details of a rule, either click on it or use the right arrow key. Along with basic rule data, you'll also be able to see which, if any, profiles it's active in and how many open issues have been raised with it.

The following actions are available only if you have the right permissions ("Administer Quality Profiles and Gates"):

• Add/Remove tags:
  • It is possible to add existing tags to a rule, or to create new ones (just enter a new name while typing in the text field).
  • Note that some rules have built-in tags that you cannot remove - they are provided by the plugins which contribute the rules.
• Extend description:
  • You can extend rule descriptions to let users know how your organization uses a particular rule, or give more insight into a rule.
  • Note that the extension will be available to non-admin users as a normal part of the rule details.

Rule types and severities

How are rules categorized? The SonarQube Cloud 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 an attacker? 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-case scenario 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-case scenario (see How are severity and likelihood decided? below) are high or low, and plug the answers into a truth table:

How are severity and likelihood decided?

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

Bugs

Impact: Could the 'worst case scenario' cause the application to crash or corrupt stored data?

Likelihood: What's the probability that the worst thing will happen?

Vulnerabilities

Impact: Could the exploitation of the 'worst thing' result in significant damage to your assets or your users?

Likelihood: What is the probability that an attacker 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 underlying vulnerability until they are reviewed.

What might change after an update

Sonar developers continually re-evaluate our rules to provide the best results. This process is evident in each release and means some rule-specific properties may change after an upgrade, even in a custom Quality Profile. This is normal and expected, and is no cause for alarm. The following are rule-specific properties that may change in an upgrade.

• Type: Type (Bug, Vulnerability, Code Smell) updates happen on occasion. When a rule type is updated, its value will update automatically in every profile that uses it. Although the rule will be updated, issues previously raised by the rule will not be updated. For example, if a rule transitioned from Bug to Code Smell, the existing issues will retain their original Bug type, and new issues will get the new type, Code Smell.
• Severity: Changes to a rule's default severity will automatically be applied in Quality Profiles where the default severity was used. Although the rule will be updated, existing issues raised by the rule will not be updated. Note that it is possible to override a rule's default severity in a profile, and your custom override should remain intact in your Quality Profile after the upgrade.
• Tags: Two types of tags may be attached to a rule: the default tags that come out of the box, and the custom tags added by administrators. When the default tags attached to a rule are updated in SonarQube Cloud, those changes will happen automatically. Custom tags associated with a rule will not change.
• Key: Can change but this is uncommon. Typically this happens in the rare case that, for whatever reason, a key that was non-normal and needs to be normalized. When the key of a rule is changed, related issues are updated as well, so that they remain related to the re-keyed rule.
• Status: Status does not affect the operation of a rule and has no impact on its issues. There are three possible rule statuses: Beta, Ready, and Deprecated. Sometimes, rules are first issued in Beta status and then moved to Ready. Most rules are in Ready status; ready to be used in production. When Sonar developers realize that a rule no longer makes sense, they first deprecate the rule, then eventually drop it.

For a comprehensive list of available rules and their up-to-date properties, see our Sonar Rules catalog.