Rules

Overview

In SonarQube Cloud, analyzers contribute rules that are executed on source code to generate issues. There are three software qualities impacted (security, reliability, maintainability) and four rule types (bug, vulnerability, code smell, security hotspot)

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

For security/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. After being reviewed by a developer, more than 80% of issues are expected to be quickly resolved.

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

Rules page

1. From within your organization, click Rules in the navigation bar to see all the available rules.
2. Use filters to narrow down the results.
3. A list of rules appears on the right side of the page.

Filters

You can filter the list of rules using the following criteria in the left sidebar:

• Language: the language to which a rule applies.
• Clean Code Attribute: consistency, intentionality, adaptability, responsibility.
• Software Quality: security, reliability, maintainability.
• Severity (software quality): blocker, high, medium, low, info.
• Type: bug, vulnerability, code smell, security hotspot.
• Type severity: blocker, critical, major, minor, info. Quality gate conditions related to severity currently use type severities.
• Tag: you can 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.
• Status: rules can have 3 different statuses:
  • Ready: the rule is ready to be used in production.
  • Beta: the rule has been recently implemented and Sonar hasn'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.
• Security Category: security rules are classified according to well-established security standards such as CWE and OWASP Top 10. See Security-related rules for details.
• 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 filters inherited rules, other rules, or inherited rules that have been overridden by other settings. 
• Activation severity is 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.

See Quality profiles for more details.

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 see which profiles the rule is active in.

Add/Remove tags:

• You can add existing tags to a rule or 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 that 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.

Rule types, software qualities and severities

How severities are assigned

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

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 the How severity and likelihood are decided section below) are high or low, and plug the answers into a truth table:

How severity and likelihood are decided

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

What might change after a software update

Sonar developers continually re-evaluate Sonar rules to provide the best results. This process is evident in each release and means some rule-specific properties may change after a software update, 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 after a software update.

• Software quality (security, reliability, maintainability) updates to rules can occur. Changes to a rule's software qualities will not be applied to issues previously raised by the rule until the project is reanalyzed.
• 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 remain the same. 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 remain the same. 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 software update.
• Tags include two types: 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 does not affect the operation of a rule and has no impact on its issues. There are three possible rule statuses: ready, beta, 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.

See the Sonar Rules catalog for a comprehensive list of rules and their properties.

Rules covered with AI CodeFix

SonarQube Cloud's AI CodeFix is an Early Access feature that uses Open AI’s GPT-4o (recommended) or Anthropic's Claude 3.5 or 3.7 Sonnet to suggest fixes for a select set of rules in Java, JavaScript, TypeScript, Python, C#, and C++. See the Sonar AI CodeFix terms for details about the terms of access. 

To learn more about which rules are eligible for AI CodeFix, please see the list of Rules covered with AI CodeFix.

Related pages

• Security-related rules
• Security hotspots
• Rules for AI CodeFix
• Understanding measures and metrics
• Managing your code issues
• Understanding quality profiles
• Quality gates