> For the complete documentation index, see [llms.txt](https://docs.snyk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snyk.io/scan-fix-and-prevent/fix/prioritize-issues-for-fixing/ignore-issues/consistent-ignores-for-snyk-code.md).

# Consistent Ignores for Snyk Code

How Consistent Ignores work for Snyk Code

{% hint style="info" %}
**Snyk is rolling out a new navigation.** The steps on this page describe the classic interface. If your view looks different, visit [Navigate the Snyk Web UI](https://docs.snyk.io/navigate-the-snyk-web-ui#where-things-moved) to map these options to the new interface.
{% endhint %}

## Consistent Ignores for Snyk Code

Snyk Code Consistent Ignores helps your teams focus on important tasks by filtering out distractions. After you ignore a finding, Snyk applies the ignore to that finding across the repository: in every branch and integration, in the Snyk CLI and Snyk IDE plugins, and in pull request checks.

By filtering out false positives, inapplicable threats, and accepted risks, your security teams can prioritize fixing real problems, and developers can code without interruptions.

### Enable Snyk Code Consistent Ignores

Enable Snyk Code Consistent Ignores for your Group or Organization in the Snyk Web UI by navigating to **Group/Organization** > **Settings** > **General** > **Ignores across the repository for Snyk Code**.

### Disable Snyk Code Consistent Ignores

Any ignores created or converted with the feature enabled will not be automatically converted back to Project-based ignores. You can recreate them manually after disabling the feature.

## How Consistent Ignores match findings

Snyk attaches a Consistent Ignore to the repository-level identifier of a finding (`snyk/asset/finding/v1`), not to a file path and line number.

Each time Snyk Code tests the repository, Snyk matches the results to the findings it already tracks for that repository. This applies to tests from every branch, the Snyk CLI, Snyk IDE plugins, and pull request checks. When code moves or changes, Snyk matches the finding to its existing identifier where it can, so the ignore continues to apply.

Snyk Code records file paths relative to the directory that a test starts from, and uses the path as one of the signals when it matches a finding. Tests of one repository that start from different directories report the same file under different paths.

Deleting a branch Project or a target does not delete Consistent Ignores and does not reopen ignored findings. The ignores remain in place for the repository.

## If an ignored finding appears as open again

Snyk cannot always match a finding to the identifier that its ignore is attached to. Two setups cause this most often:

* Tests of one repository that start from different directories, for example the repository root in a pipeline and a module directory on a developer machine.
* Repositories that contain duplicate copies of their source files, such as a baseline or build output directory.

In these cases, Snyk can attach the ignore to the finding at a different path. The original finding appears as **Open** again, and the finding at the other path is suppressed. Snyk does not move the ignore back automatically. The original ignore is not deleted.

1. [Ignore the finding again](#create-an-ignore) from its issue card.
2. [Retest the Project](/scan-fix-and-prevent/scan-with-snyk/snyk-code/manage-code-vulnerabilities.md#retesting-code-repository) to update the issue status.
3. Review ignored findings in duplicate directories, and exclude those directories from tests where possible.
4. If ignored findings reappear repeatedly, contact Snyk Support with the Organization, the Project, and the URLs of the affected issues.

## User roles

To create, edit and remove ignores, you need to have a user role assigned with Ignore management permissions. Only Group Admins can set these permissions (see [User role management](https://docs.snyk.io/platform-administration/user-management/user-role-management)).

1. Log in to the Snyk Web UI and navigate to your Group and Organization.
2. Navigate to **Members** > **Manage Roles** and select one or more permissions.

<table><thead><tr><th width="203">Ignores management</th><th>Description</th></tr></thead><tbody><tr><td>View Ignores</td><td>View Ignore information.</td></tr><tr><td>Create Ignores</td><td>Create new Ignores.</td></tr><tr><td>Edit Ignores</td><td>Configure Ignores.</td></tr><tr><td>Remove Ignores</td><td>Permanently remove Ignores.</td></tr></tbody></table>

### Manage ignores at the Group level through Snyk Code Security policies

{% hint style="info" %}
This feature is available to Enterprise customers only. It must be enabled by Snyk before it is accessible.
{% endhint %}

You can manage ignores proactively using Group-level Snyk Code Security policies. As a general rule, you can apply ignore policies when you identify a recurring need to apply similar individual ignores.

To manage the ignores through security policies, Snyk Code Consistent Ignores need to be enabled at the Group level. You do not require [conversion](/scan-fix-and-prevent/fix/prioritize-issues-for-fixing/ignore-issues/consistent-ignores-for-snyk-code/convert-project-scoped-ignores-to-asset-scoped-ignores.md) for any previously applied Group level policy ignores. If you want to activate Snyk Code Security policies at the Group level, contact your Snyk account team or Snyk Support.

{% hint style="info" %}
[**Snyk Security Policies**](https://docs.snyk.io/manage-risk/policies/security-policies) are a separate feature, available at the Group level to all Enterprise customers. That feature is applicable to Open Source and Container, and will not work for Snyk Code. For Group level policy Ignores to apply to Snyk Code, you must use the Snyk Code Security policies feature.
{% endhint %}

Policies configured to ignore based on Project attributes do not result in ignores being applied in Snyk CLI and IDE settings where a Snyk Project is not available.

To configure a Snyk Code Security policy, select the organization/s or project attributes that the policy should apply to, give it a name, and add rules containing at least one of the following criteria:

| Criteria | Description                                                                                                                                                                                                                                                      |
| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| CWE      | You can provide any CWE value. Snyk Code will ignore any subsequent tests that find associated findings or issues. You can find valid CWEs on [MITRE’s website](https://cwe.mitre.org/data/published/cwe_latest.pdf) or anywhere you can view Snyk Code results. |
| Rule IDs | You can provide any Snyk Code rule ID. You can find Snyk Code rule IDs as part of the SARIF output that you exported using [Snyk CLI](https://docs.snyk.io/developer-tools/snyk-cli).                                                                            |
| Severity | Matches all issues that contain a specified severity level. When multiple values are selected, the condition applies to all issues containing any of the selected severity levels (for example, High, Medium, Low).                                              |

### Manage ignores in Snyk Projects

You can take action from Project issues, but Snyk will apply any ignores to the underlying asset-scoped findings that can span across Snyk Projects, integrations, and branches.

When you create, modify, or delete an ignore, you must [retest the Project](/scan-fix-and-prevent/scan-with-snyk/snyk-code/manage-code-vulnerabilities.md#retesting-code-repository) to update the issue status.

An indicator at the top of the Project page will notify you if a retest is needed to capture policy or ignore updates.

Project retests typically occur on a nightly or weekly basis, but you can also retest manually.

#### Create an ignore

1. Log in to the Snyk Web UI and navigate to your Group and Organization.
2. Open a Project and find an issue card.
3. Select **Ignore** on an issue card to create an ignore.
4. Fill in the ignore information and confirm its creation. The issue will be updated and moved from **Open** to **Ignored**.\
   \
   If anyone loads the page before a retest, an indicator will appear and encourage retesting to capture policy or ignore changes.

#### Modify ignore

**Delete ignore**

1. Log in to the Snyk Web UI and navigate to your Group and Organization.
2. Open a Project and find an issue card.
3. Select **Unignore** to set all future tests to show the associated finding or issue as open.

**Edit ignore details**

1. Log in to the Snyk Web UI and navigate to your Group and Organization.
2. Open a Project and find an issue card.
3. Select **Edit Ignore** and change the ignore type or expiration. After a reviewer approves or rejects an ignore request, **Ignore reason** is disabled and you cannot change it.
4. Click **Confirm**.


---

# 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.snyk.io/scan-fix-and-prevent/fix/prioritize-issues-for-fixing/ignore-issues/consistent-ignores-for-snyk-code.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.