Rules
In SonarQube Cloud, analyzers contribute rules that are executed on source code to generate issues.
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 website is the entry point where you can discover all the existing rules.
Rules page
From within your organization, select Rules in the navigation bar to see all the available rules.
Use filters to narrow your results.
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 the Security-related rules page for more detail.
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 the Understanding quality profiles for more details about how your rule selection affects your analysis.
Rule details
To see the details of a rule, either select the rule title or use the arrow keys to cycle through the list. Inside the detailed view, along side the 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 are rules categorized by software qualities impacted? There are four categories: security, reliability, maintainability, and security hotspots. Rules are assigned to one or more software quality categories based on the answers to these questions:
Is the rule about code that could be exploited by an attacker? If yes, then it’s a security rule.
Is the rule about code that is demonstrably wrong, or more likely wrong than not? If the answer is "yes", then it’s a reliability rule.
Is the rule neither a bug nor a vulnerability? If yes, then it’s a maintainability rule.
How severities are assigned
List of severity metrics used in software qualities.
Severity
Definition
Blocker
An issue that has a significant probability of severe unintended consequences on the application that should be fixed immediately. This includes bugs leading to production crashes and security flaws allowing attackers to extract sensitive data or execute malicious code.
High
An issue with a high impact on the application that should be fixed as soon as possible.
Medium
An issue with a medium impact on the application.
Low
An issue with a low impact on the application.
Info
There is no expected impact on the application. For informational purposes only.
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 are high or low (see How severity and likelihood are decided), and plug the answers into a truth table:
Software quality
Type
Impact
Likelihood
Blocker
Blocker
✅
✅
High
Critical
✅
❌
Medium
Major
❌
✅
Low
Minor
❌
❌
How severity and likelihood are decided
To assess the severity of a rule, we start from the worst-case scenario (see How severity and likelihood are decided) and ask category-specific questions.
Reliability
Impact: Could the worst thing cause the application to crash or corrupt stored data?
Likelihood: What’s the probability that the worst thing will happen?
Security
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.
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 a feature that uses Anthropic's Claude Sonnet 4 (recommended) or OpenAI's GPT-4o 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
Introduction to managing your code issues
Last updated
Was this helpful?