# Sandboxing of issues

Some SonarQube updates may introduce new issues in your code on sections that have not been changed since the previous analysis. Such updates include Sonar analyzer improvements (improved rules), or changes to built-in quality profiles (addition of rules). This introduction of new issues may lead to abrupt and unexplained quality gate and pipeline failures, causing frustration and delays in releases.

To eliminate these pain points, you can enable the sandboxing of issues that come from SonarQube updates and fulfill preconfigured conditions. This way:

* The sandboxed issues won’t impact your quality gate.
* Users will be able to triage the sandboxed issues at their own pace.

{% hint style="warning" %}
Be aware that sandboxed issues can result in accumulation of debt if left unaddressed. Users should not postpone the triage and addressing of sandboxed issues for too long.
{% endhint %}

## Sandbox conditions

The way the conditions are applied depends on your instance mode (for more information about the instance mode, see [instance-mode](https://docs.sonarsource.com/sonarqube-server/instance-administration/analysis-functions/instance-mode "mention")).

{% hint style="warning" %}
Sandboxing security and/or reliability issues can significantly elevate the risk of security breach, unpredictable behaviour and degraded performance of your software if the issues are not addressed.
{% endhint %}

### MQR mode

Conditions for issue sandboxing are configured based on:

* The software quality that the issue impacts.
* The severity level of this impact.

An issue is sandboxed if:

* Each impacted software quality fulfills a configured condition.
* All configured conditions are fulfilled for at least one severity level for a given software quality.

**Example 1**

If you configure the following conditions:

* The issue impacts maintainability with medium or low severity.
* The issue impacts security with low severity.

then:

* An issue impacting the maintainability with medium or low severity *and* the security with low severity, *and* with no impact on reliability will be sandboxed.
* In all other cases, the issue will not be sandboxed.

**Example 2**

If you configure the following condition:

* The issue impacts maintainability with medium or low severity.

then:

* An issue impacting the maintainability with medium or low severity, *and* with no impact on security and reliability will be sandboxed.
* In all other cases, the issue will not be sandboxed.

### Standard Experience

Conditions for issue sandboxing are configured based on:

* The issue type.
* The issue’s severity level.

An issue is sandboxed if its type and severity level fulfill a configured condition.

**Example**

If you configure the following conditions:

* Issue type is bugs with info, minor, or major severity.
* Issue type is code smells with info or minor severity.

then:

* A bug with info, minor, or major severity will be sandboxed.
* A code smell with info or minor severity will be sandboxed.

## Sandbox configuration levels

The instance admin can enable the Sandbox feature.

If Sandbox is enabled in their instance, the project admins can change the Sandbox status (on or off) for their project.

When enabling the Sandbox feature, the instance admin:

* Sets the Sandbox’ default status (on or off) for all new and existing projects.
* Configures the sandbox conditions and decides whether project admins are allowed to change them or not for their project.

## Related pages

* [triaging-issues-in-sandbox](https://docs.sonarsource.com/sonarqube-server/user-guide/issues/triaging-issues-in-sandbox "mention")
* [#setting-up-the-sandbox-feature-at-the-instance-level](https://docs.sonarsource.com/sonarqube-server/instance-administration/analysis-functions/quality-standards#setting-up-the-sandbox-feature-at-the-instance-level "mention")