Context

Endor Labs gives you three ways to dismiss findings. All three set spec.dismiss=true, but they differ in scope, timing, ownership, and how they fit into your workflow. This article explains those differences, what permissions are required, and when to use each one.

At a Glance

Snooze

Best for temporarily dismissing a single finding instance in a specific project when you do not need a permanent or repo-wide exception.

What happens when a finding is snoozed

• The finding's spec.dismiss property is set to true

• The finding is tagged with FINDING_TAGS_SNOOZED

• This change happens immediately - it does not wait for the next scan

• The finding remains visible in the system (use Dismissed > Snoozed filters to view it) but is excluded from action policies (both admission warn/block and notifications)

• Built-in action policies skip the finding on the next evaluation. Admission and notification scanners check spec.dismiss and exclude dismissed findings automatically.

• You can set an expiration date, and optionally configure vulnerability findings to un-snooze automatically when a fix becomes available.

User permissions required

The following user roles can snooze findings:

• Code Scanner - Has permission to update findings

• Admin - Has permission to update findings

Users with Read Only or Policy Editor roles cannot snooze findings.

Exception Policies

Best for rule-based, repeatable exceptions across multiple findings or projects, especially when criteria should be re-evaluated on every scan.

What happens when an Exception Policy matches a Finding

• spec.dismiss is set to true, and the matching policy UUIDs are recorded in spec.exceptions.policy_uuids

• The finding is tagged with FINDING_TAGS_EXCEPTION.

• The change is applied during the scan cycle, not instantly from the UI.

• Matched findings are excluded from built-in action policies on subsequent scans, the same way snoozed findings are.

• Exception criteria persist across scans and can span multiple repository versions or projects, depending on policy scope.

Endor Ignore (.endorignore.yaml)

Best for dismissal as code - developers can commit ignore entries in the repository, and scans will apply them automatically.

What happens when an ignore entry matches a finding

• spec.dismiss is set to true, and ignore metadata is stored in spec.ignore.

• The finding is tagged with FINDING_TAGS_IGNORED.

• Ignore files are processed during scan execution.

• They apply only to the repository version that contains the file (the parent of the scan).

• Matched findings do not trigger built-in action policies, consistent with the other dismissal methods.

When to use each

1. Snooze: One-off, temporary dismissal of a specific finding while a fix is in progress. Use expiration or "un-snooze when fix available" for time-bound exceptions.

2. Exception Policy: Repeatable, policy-driven exceptions across projects or finding types that should be centrally managed and re-evaluated every scan.

3. Endor Ignore: Developer-owned, reviewable exceptions committed to the repository; best when dismissal should follow your normal code-review process.

For more information, see the Snooze Findings documentation, Exception Policies documentation, and Dismiss findings using an ignore file.