> For the complete documentation index, see [llms.txt](https://knowledgebase.autorabit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledgebase.autorabit.com/product-guides/integral-zone/iz-suite/quality-control/rules/quality-rules.md).

# Quality Rules

Quality Rules serve as the guidelines utilized for conducting static code analysis.

1. Navigate to **`Rules`** -> **`Quality Rules`** <br>

   <figure><img src="https://1912836914-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9vAxMuDrkUkB4OXlH9CL%2Fuploads%2FzNcvdKZ2MMEOXrAIvsNK%2Fquality-rules.png?alt=media&amp;token=3b8e405e-49bf-4368-ba61-fe378e5cf4aa" alt=""><figcaption></figcaption></figure>
2. Details include -
   1. **`Name`** - Name of the rule
   2. **`Language`** - Language for which the rule is applicable. E.g.: Mule, API
   3. **`Severity`** - Severity of the rule. Value can be one of -
      1. CRITICAL
      2. BLOCKER
      3. MAJOR
      4. MINOR
      5. INFO
   4. **`Category`** - Category of the rule. Value can be one of -
      1. BUG
      2. CODE SMELL
      3. VULNERABILITY
      4. SECURITY HOTSPOT
3. Click on **`Activate Rule`** action to activate the rule in any of the Quality Profile\
   &#x20;

   <figure><img src="https://1912836914-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9vAxMuDrkUkB4OXlH9CL%2Fuploads%2FeECawKbPxJGrNbAZDOTk%2Factivate-rule-in-profile.png?alt=media&amp;token=9096ec95-d2e4-43bb-9995-c2f7bfe17b15" alt=""><figcaption></figcaption></figure>

#### Rule Descriptions <a href="#rule-descriptions" id="rule-descriptions"></a>

Every built-in rule has a description in Markdown, shown when you open the rule and in the IDE plugins:

1. What the rule checks and why it matters, including what it deliberately does not report.
2. Examples: a **Non Compliant** and a **Compliant** code example. AWS rules show the equivalent template JSON, or the setting to change in the AWS Console where the issue is fixed there.
3. **References**: links to the official documentation behind the rule. Security rules link the OWASP Top 10 2021 and CWE entries they map to.

Rules that offer auto-fix also describe what the fix changes.

#### Rule Tags <a href="#rule-tags" id="rule-tags"></a>

Every built-in rule carries one to five short, lower-case tags, which are shown in the **`Tags`** column. Type a tag in **`Search Rule`** to list the rules that carry it, and use tags in the **`Rule`** filter.

&#x20;For example:

* AWS rules: **`aws`**, the service (such as **`aws-lambda`**, **`sqs`** or **`elb`**), the area and the topic, for example **`aws`**, **`aws-lambda`**, **`security`**, **`encryption`**
* Java rules: the area and topics, plus the OWASP Top 10 category for security rules, for example **`security`**, **`spring-boot`**, **`owasp-a05`**
* Python PEP 8 rules: **`pep8`** and the matching **`pycodestyle`** code, for example **`pep8`**, **`whitespace`**, **`e225`**

#### How Built-in Rules Are Classified <a href="#how-built-in-rules-are-classified" id="how-built-in-rules-are-classified"></a>

Built-in rules are assigned a severity and category consistently:

* **Vulnerability** - a definite, exploitable flaw. An end-of-life engine or runtime (for example a deprecated Lambda runtime) is a **Critical** Vulnerability.
* **Security Hotspot** - security-sensitive code or configuration that needs review. Security Hotspots are rated **Major** or **Minor** only.
* **Bug** - code or configuration that will not behave as intended.
* **Code Smell** - maintainability and style issues. Rules that only report scan coverage or inventory are **Info** Code Smells.

### Built-in and Custom Rules

* **Built-in rules** are delivered and updated with IZ Suite. New and revised built-in rules are applied automatically by the seed data process after an upgrade.
* **Custom rules** are created with **`Add Rule`** or by cloning a built-in rule.

{% hint style="warning" %}
In a multi-tenant installation built-in rules are read-only. To change the name, severity, category or definition of a built-in rule, clone it and use the clone in your quality profiles
{% endhint %}

### See Also

* [Quality Profiles](/product-guides/integral-zone/iz-suite/quality-control/profiles/quality-profiles.md)
* [Metric Profiles](/product-guides/integral-zone/iz-suite/quality-control/profiles/metric-profiles.md)
* [Metric Rules](/product-guides/integral-zone/iz-suite/quality-control/rules/metric-rules.md)


---

# 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://knowledgebase.autorabit.com/product-guides/integral-zone/iz-suite/quality-control/rules/quality-rules.md?ask=<question>&goal=<user_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.