SonarQube rules

In SonarQube Cloud, analyzers contribute rules that are ran against source code to generate issues.

SonarQube's analyzers run rules on source code, resulting in the generation of issues and security hotspots.

Each rule:

• Is associated with a code attribute it evaluates.

• Is associated with the software quality(ies) to which this attribute contributes. A severity is assigned to each associated software quality. It determines how much that software quality is impacted when the rule is broken.

• Is associated with a type: bug, vulnerability, code smell, or security hotspot. A type severity is assigned to each rule. It determines how much that rule type is impacted when the rule is broken.

Statistics on SonarQube rules

For code smells and 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 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.

SOFTWARE QUALITY SEVERITIES

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 run 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.

TYPE SEVERITIES

Software quality	Type	Impact	Likelihood
Blocker	Blocker	✅	✅
High	Critical	✅	❌
Medium	Major	❌	✅
Low	Minor	❌	❌

Software qualities

High quality code contributes to software that is secure, reliable, and maintainable. SonarQube's software qualities help asses the overall health of your code. These three aspects - security, reliability, and maintainability - are called software qualities in SonarQube and they contribute to the long-term value of your software:

• Security is the protection of your software from unauthorized access, use, or destruction.

• Reliability is a measure of how your software is capable of maintaining its level of performance under stated conditions for a stated period of time.

• Maintainability refers to the ease with which you can repair, improve and understand software code.

Rules are assigned to one or more software qualities 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.

Types

There are four ypes: bugs, vulnerabilities, code smells, and security hotspots. Rules are assigned to a type 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 vulnerability rule.

Is the rule about code that is security-sensitive? If yes, then it’s a security hotspot 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 bug rule.

Is the rule neither a bug nor a vulnerability? If yes, then it’s a code smell rule.

Rule severities

A severity is linked to each software quality assigned to a rule, and to the rule's type.

Severity 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 run 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.

Severity used in types

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 run malicious code.
Critical	An issue with a critical impact on the application that should be fixed as soon as possible.
Major	An issue with a major impact on the application.
Minor	An issue with a minor impact on the application.
Info	There is no expected impact on the application. For informational purposes only.

Severity assignment rules

To assign severity to a rule, we proceed as follows:

1

We find out what’s the worst-case scenario that could happen

In answering this question, we try to factor in Murphy’s Law, without predicting Armageddon.

2

We assess the impact and likelihood of the worst-case scenario

To assess the severity of a rule, we ask category-specific questions.

SOFTWARE QUALITY

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.

TYPES

3

We enter the results into a truth table

Software quality	Type	Impact	Likelihood
Blocker	Blocker	✅	✅
High	Critical	✅	❌
Medium	Major	❌	✅
Low	Minor	❌	❌

Code attributes

Each rule is associated with a code attribute it evaluates. Each code attribute contributes to one or several software qualities.

Consistency

The is code is written in a uniform and conventional way. All the code looks similar and follows a regular pattern, even with multiple contributors at different times. Consistent code is:

• formatted: the code presentation is systematic and regular. Non-semantic choices, such as spacing, indentation, and character placement, remain consistent throughout the codebase, maintaining uniformity across files and authors.

• conventional: the code performs tasks with expected instructions. Faced with equally good options, the code adheres to a single choice across all instances, preferring language conventions. This includes using the appropriate programming interfaces and language features.

• identifiable: the names follow a regular structure based on language conventions. The casing, word separators, suffixes, and prefixes used in the identifiers have purpose, without arbitrary differences.

Intentionality

The code is precise and purposeful. Every instruction makes sense, is adequately formed, and clearly communicates its behavior. Intentional code is:

• clear: the code is self-explanatory, transparently communicating its functionality. It is written in a straightforward way that minimizes ambiguity, avoiding unnecessary clever or intricate solutions.

• logical: the code has well-formed and sound instructions that work together. It is free of explicit errors, contradictions, and commands that could be unpredictable or objectionable.

• complete: the code constructs are comprehensive and used adequately and thoroughly. The code is functional and achieves its implied goals. There are no obviously incomplete or lacking solutions.

• efficient: the code uses resources without needless waste. It prioritizes economical options when available, avoiding unnecessary consumption of memory, processor, disk, or network resources.

Adaptability

The code is structured to be easy to evolve and develop with confidence. It makes extending or repurposing its parts easy and promotes localized changes without undesirable side-effects. Adaptable code is:

• focused: the code has a single, narrow, and specific scope. Each unit should have only one concise purpose, without an overwhelming accumulation of instructions or excessive amounts of complexity.

• distinct: the code procedures and data are unique and distinctive, without undue duplication. The codebase has no significant repetition where it could be decomposed into smaller shared segments.

• modular: the code has automated checks that provide confidence in the functionality. It has enough test coverage which enables changes in implementation without the risk of functional regressions.

Responsibility

The code takes into account its ethical obligations on data, as well as societal norms. Responsible code is:

• lawful: the code respects licensing and copyright regulation. It exercises the creator’s rights and honors other’s rights to license their own code.

• trustworthy: the code abstains from revealing or hard-coding private information. It preserves sensitive private information such as credentials and personally identifying information.

• respectful: the code refrains from using discriminatory and offensive language. It chooses to prioritize inclusive terminology whenever an alternative exists that conveys the same meaning.

Related pages

• Security-related rules

• Security hotspot rules

• If Sonar updates a rule

• Retrieving and viewing rules

• Adding tags to a rule

• Rules for AI CodeFix

• Built-in rule tags