> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/10.5/user-guide/rules/overview.md).
# Overview
SonarQube Server 10.5 evaluates your source code against its set of rules to generate issues.
{% hint style="info" %}
**For AI agents:** You're in the SonarQube Server 10.5 documentation. For a list of all 10.5 pages, see the [SonarQube Server 10.5 page index](https://3691828591-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Feu7dHWcqP9Cr3eUAzwWg%2Fuploads%2FSs9GoB7jpGlJIw3L9REJ%2Fsonarqube-server-10.5-llms.txt?alt=media). For the whole site, see the [page index](https://docs.sonarsource.com/llms.txt) or the [full text](https://docs.sonarsource.com/llms-full.txt). For another version, replace 10.5 in the URL with that version. The [latest version](https://docs.sonarsource.com/sonarqube-server/) has no version number in its URL.
{% endhint %}
## Overview
SonarQube Server executes rules 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 goal is to have more than 80% of issues be *true positives*.
Security hotspot rules draw attention to code that is security-sensitive. It is expected that more than 80% of the issues will be quickly resolved as "reviewed" after being reviewed by a developer.
## Rules
By default, when selecting the top menu item **Rules**, you will see all the available rules installed on your SonarQube Server instance. You have the ability to review and narrow the selection based on search criteria in the left sidebar:
* **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 Server.
* **Default Severity**: the original severity of the rule - as defined by SonarQube Server.
* **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.
* **Available since**: the date when a rule was first added on SonarQube Server. This is useful to list all the new rules since the last upgrade of a plugin for instance.
* **Template**: display rule templates that allow you to create custom rules (see Custom rules below on this page).
* **Quality profile**: *inclusion in* or *exclusion from* a specific profile
If a Quality profile is selected, it is also possible to check for its active severity and whether it is inherited or not. See the [Quality profiles](/sonarqube-server/10.5/instance-administration/quality-profiles.md) documentation for more.
## Rule details
To see the details of a rule, either click the rule with your mouse or use the right arrow key. Along with basic rule data, you’ll also be able to see which, if any, profiles the rule is active in and how many open issues have been raised with it.
The following actions are available only if you have the correct permission level *Administer quality profiles and gates*:
* **Add/Remove tags**:
* It is possible to add existing tags on a rule, or to create new rules; simply enter a new name while typing in the text field.
* Note that some rules have built-in tags that you cannot remove. For example, the rules are provided by the plugins which contribute to the rules.
* **Extend description**:
* You can extend rule descriptions to let users know how your organization is using a particular rule or to 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 templates and custom rules
Rule templates are provided by plugins as a basis for users to define their own custom rules in SonarQube Server. To find templates, select the **Show Templates Only** option from the **Template** dropdown menu:
Rule templates can easily be isolated from the selection when selecting Show Templates Only.
To create a custom rule from a template select **Create** next to the **Custom rules** heading and enter the following information:
* **Name**
* **Key** (auto-suggested)
* **Type**
* **Severity**
* **Status**
* **Description** (Markdown format is supported)
* The parameters specified by the template
When selecting the link in the **Custom rules** section, you can navigate from a template to the details of custom rules defined by that template.
Custom rules can be created from the SonarQube Server UI using the rule template.
### Custom rules
Custom rules are considered like any other rule, except that you can edit or delete them:
{% hint style="info" %}
When deleting a custom rule, it is not physically removed from the SonarQube Server instance. Instead, its status is set to "REMOVED". This allows current or old issues related to this rule to be displayed properly in SonarQube Server until they are fully removed.
{% endhint %}
## Extending coding rules
Custom coding rules can be added. See [Adding coding rules](/sonarqube-server/10.5/extension-guide/adding-coding-rules.md) for detailed information and tutorials.
## Rule types and severities
### How rules are categorized
The SonarQube Server 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 severities are 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 the *How severity and likelihood are decided* section below) are high or low, and plug the answers into a truth table:
| | | |
| ----------- | ---------- | -------------- |
|
| **Impact** | **Likelihood** |
| Blocker | ✅ | ✅ |
| Critical | ✅ | ❌ |
| Major | ❌ | ✅ |
| Minor | ❌ | ❌ |
## How severity and likelihood are decided
To assess the severity of a rule, we start from the worst thing (see the *How severities are assigned* section above) and ask category-specific questions.
### Bugs
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?**
### 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 a software 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 Server, 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 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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.sonarsource.com/sonarqube-server/10.5/user-guide/rules/overview.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.