> ## Documentation Index
> Fetch the complete documentation index at: https://docs.endorlabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Dismiss findings
> Exclude findings from your active workflow using exception policies, ignore files, or snooze.
Dismiss findings to exclude them from the active workflow. Dismissed findings no longer appear in active views and do not trigger policies.
You can dismiss findings in one of the following ways:
* [**Exception Policy**](#dismiss-findings-using-an-exception-policy): Applies during scan execution and suppresses all findings that match the defined criteria across the selected repository versions or projects.
* [**Snooze**](#snooze-findings): Applies to a single finding instance for a specific target, repository version, and project. It takes effect immediately and applies only to the selected finding instance.
You can't snooze pull request findings, as each pull request represents a new repository version. However, you can dismiss PR findings using [incremental PR scans](/scan/pr-scans#perform-incremental-pr-scan), [Exception Policy](/platform-administration/policies/exception-policies#create-an-exception-policy-from-a-template), or [ignore files](#dismiss-findings-using-an-ignore-file).
* [**Ignore File**](#dismiss-findings-using-an-ignore-file): Applies during scan execution and suppresses all findings matching the ignore file entries. Ignore files are part of the source code and are only applied to the parent repository version.
## Dismiss findings using an exception policy
Add an exception policy to prevent a finding from triggering action policies in future scans.
1. Select **Projects** from the left sidebar.
2. Search for and select a project, and select **Findings**.
3. Search for findings using advanced or basic filters.
4. Select findings and click the vertical three dots.
5. Select **Add Exception**.
Use the **Grouped By** filter to group multiple findings and apply exceptions to them at once.
See [Create exception policy](/platform-administration/policies/exception-policies) for details on how to create and apply exceptions.
## Snooze findings
Snooze a finding to temporarily dismiss it and choose when it should reappear for findings that do not require immediate action or a permanent exception policy. To dismiss multiple findings, or a single finding across multiple repository versions or projects, create an [exception policy](/platform-administration/policies/exception-policies).
You require **Admin** or **Code Scanner** role permissions to snooze findings and edit snooze parameters. See [authorization roles](/platform-administration/rbac/authorization-roles) to learn about the different roles Endor Labs offers.
To snooze a finding:
1. Open the finding details.
2. Click **Snooze**.
3. Select the most appropriate reason to indicate why you're snoozing the finding.
4. Optionally, select **Expiration** to specify when the finding should reappear. If you set an expiration date, the finding will be automatically un-snoozed by the first scan on the expiration date.
5. Optionally, for vulnerability findings, select **Automatically un-snooze when a fix becomes available** to have the finding reappear after the first scan once a fix becomes available.
6. Optionally, add a comment to provide context for the snooze.
7. Click **Snooze Finding**.
A finding can be temporarily snoozed while a fix is in progress, with details such as the reason, expiration date, and remediation timeline recorded for context.
### View snoozed findings
To view snoozed findings:
1. Select **Findings** from the left sidebar.
2. Select **Dismissed** from saved filters and select **Yes**.
3. Select **Snoozed** to view snoozed findings only.
4. Use the filter form to refine results by reason, or expiry range.
5. Click on a snoozed finding to view its details.
You can view snooze parameters, including status, expiration date and time, and comments, in the finding details panel. The last updated timestamp shows when you created or last modified the snooze, which helps you track changes and verify if someone else has modified or un-snoozed the finding.
See [Get finding snooze history](/developers-api/rest-api/using-the-rest-api/use-cases#get-finding-snooze-history) to retrieve the snooze history of a finding via the API.
### Un-snooze findings
When you un-snooze a finding, it immediately reappears in your findings list and dashboards. The finding becomes active again, and action policies will process it during the next scan.
To un-snooze a finding:
1. Select **Findings** from the left sidebar.
2. Select **Dismissed** from saved filters and select **Yes** to view snoozed findings.
3. Click on a snoozed finding to view its details.
4. Click **Edit snooze** and then click **Un-snooze**.
### Update snoozed findings
To update snooze settings of a finding:
1. Select **Dismissed** from saved filters and select **Yes** to view snoozed findings.
2. Click on a snoozed finding and click **Edit snooze**.
3. Edit snooze settings such as expiration date, reason, or comments, and click **Update Snooze** to save the changes.
## Dismiss findings using an ignore file
Ignore files let you dismiss findings by committing a file in your repository. Endor Labs applies them during scan execution, and they only affect the repository version that contains the file (the parent of the scan). Any finding that matches an entry in the ignore file does not appear in the findings list or trigger action policies.
You must [allow ignore files to dismiss findings](/platform-administration/configure-system-settings#allow-ignore-files-to-dismiss-findings) in **Settings** > **SYSTEM SETTINGS** > **Developer Workflows** for scans to process ignore files.
Ignore files can be in one of two formats:
* [**Yaml format**](#ignore-file-yaml-syntax): A list of ignore entries. Each entry specifies the finding by name, dependency, or other fields, plus metadata such as reason, expiration date, and comments.
* [**Raw vulnerability IDs**](#ignore-file-plain-text-format): A plain list of vulnerability identifiers (for example, CVE or GHSA), one per line, for vulnerability findings only. This format does not require yaml structure.
By default, the supported file path is `.endorignore.yaml`. Your administrator can configure additional files in Developer Workflows. Set up CODEOWNERS for all supported ignore files so that changes require approval before merge.
### Ignore file yaml syntax
The ignore file contains entries that specify the findings to suppress during scans. Use the [endorctl ignore](/developers-api/cli/commands/ignore) command to create the file if needed and format the yaml entries automatically. Use the [endorctl validate ignore](/developers-api/cli/commands/validate/ignore) command to validate the file after changes or branch merges.
The file must include a top-level `version` and an `ignore` key whose value is a list of entries. Each entry supports the following fields.
{`
- Field: \`id\`
Description: Unique identifier for the entry.
- Field: \`finding_name\`
Description: Name of the finding to match. Each entry requires at least one of \`finding_name\` or \`vuln_id\`.
- Field: \`vuln_id\`
Description: Vulnerability ID to match, such as a CVE or GHSA ID. Each entry requires at least one of \`finding_name\` or \`vuln_id\`.
- Field: \`dependency_name\`
Description: Name of the dependency to match. You can use partial values, for example you can specify the dependency name without a version.
- Field: \`parent_name\`
Description: Name of the parent package that declares or pulls in the dependency. You can use partial values, for example you can specify the package name without a version.
- Field: \`username\`
Description: Developer who requested the exception.
- Field: \`reason\`
Description: Reason for ignoring the finding. Allowed values are \`false-positive\`, \`risk-accepted\`, \`in-triage\`, \`resolved\`, or \`other\`. Default is \`risk-accepted\`.
- Field: \`expiration_date\`
Description: Date when the ignore entry expires, in YYYY-MM-DD format.
- Field: \`expire_if_fix_available\`
Description: Indicates whether to remove the ignore entry automatically when a fix becomes available.
- Field: \`comments\`
Description: Additional comments describing the reason for the entry.
`}
The following example shows a valid ignore file in yaml format with a version, an ignore list, and entries that use the fields described above.
```yaml expandable theme={null}
version: 1.0.0
ignore:
- id: endorignore-1
username: alice@corp.com
finding_name: Unmaintained Dependency some-package@1.0
reason: risk-accepted
expiration_date: 2026-06-01
comments: "Tracking upgrade in JIRA-123"
- id: endorignore-2
vuln_id: CVE-2025-12345
parent_name: some-ut-package-name
reason: other
expire_if_fix_available: true
comments: "No fix available and this package is only used for testing"
- id: endorignore-3
username: bob@corp.com
finding_name: "Potential secret leak Generic API Key: ID #dace33"
reason: resolved
comments: "I revoked my token"
```
### Ignore file plain text format
You can ignore vulnerability findings by listing the vulnerability IDs in a plain text file.
```shell theme={null}
# Ignore list for approved exceptions (AppSec-owned)
CVE-2024-12345
GHSA-xxxx-yyyy-zzzz
CVE-2023-99999
```
### View ignored findings
To view ignored findings:
1. Select **Findings** from the left sidebar.
2. Select **Dismissed** from saved filters and select **Yes**.
3. Select **Ignored** to view ignored findings only.
4. Use the filter form to refine results by reason, or expiry range.
5. Click on an ignored finding to view its details.
You can view ignore parameters, including status, expiration date and time, comments, ignore file name and entry id in the finding details panel. The ignore parameters available depend on which fields the developers must provide in the ignore file entries.
## Filter dismissed findings
Use the following options to filter dismissed findings.
* Select **Yes** to view only dismissed findings in the findings table.
* Select **No** to hide dismissed findings from the findings table.
* Deselect both Yes and No to include dismissed findings in the findings table along with the rest of the findings.
* Select **Exception**, **Ignored**, and/or **Snoozed**, to filter by dismissal method.
* For exception findings, choose from one of the existing exception policies in the list or search for a specific exception using **Search for Policy Name**.
* Select **Reason** to filter dismissed findings by reason.
* Select **Expires Within** to filter dismissed findings by expiration time-frame.
