---
title: "CVE Suppressions"
description: "Accept known-benign vulnerabilities fleet-wide so your scan results stay focused on findings that actually need action."
---

Not every CVE that Trivy reports requires a response. Some are false positives on your base image, some have been accepted by your security review, and some are waiting on an upstream patch. CVE suppressions let you annotate these findings once so they stop competing for attention in every scan, comparison, and alert.

<Note>
  CVE suppressions are available on every tier. Suppressions written on a control node replicate to its replicas at fleet scope.
</Note>

## What suppressions do

A suppression is a rule that says "this CVE is acknowledged." When a scan's findings are read back for display or comparison, Sencho checks each finding against the active suppression list:

- Suppressed findings remain in the database and in the scan totals. Nothing is deleted.
- In the scan drawer and the comparison sheet, suppressed rows are dimmed and marked with a shield-off icon.
- The reason you recorded is visible in the row so reviewers understand why it was accepted.

Counts on badges and summary ribbons continue to reflect the raw findings. Suppressions are a visual filter, not an accounting trick. If you suppress a CVE and then remove the suppression, the finding resurfaces on the next read, without rescanning.

## Creating a suppression

Go to **Settings → Security** and scroll to **CVE Suppressions**, then click **Add Suppression**.

<Frame>
  <img src="/images/cve-suppressions/settings-panel.png" alt="Settings Security section showing the CVE Suppressions panel with a list of accepted CVEs" />
</Frame>

| Field | Description |
|-------|-------------|
| **CVE ID** | The identifier of the finding. Accepts both `CVE-YYYY-NNNN` and GitHub advisory IDs like `GHSA-xxxx-xxxx-xxxx`. |
| **Package** | Optional. Leave empty to suppress every occurrence of this CVE regardless of package, or set it to a specific package name (e.g. `openssl`) to narrow the scope. |
| **Image pattern** | Optional glob against image references (e.g. `registry.example.com/app*`). Leave empty to apply fleet-wide. |
| **Reason** | Required. A short note explaining why this CVE is accepted. Surfaced on every suppressed row. |
| **Expires in** | Optional. Number of days after which the suppression stops applying. Useful for "patched in the next release" acknowledgements. Leave empty for an indefinite suppression. |

<Frame>
  <img src="/images/cve-suppressions/create-dialog.png" alt="Dialog for adding a new CVE suppression with fields for CVE ID, package, image pattern, reason, and expiry" />
</Frame>

### How specificity is resolved

When multiple suppressions match the same finding, the most specific one wins:

1. A suppression that pins both a package name and an image pattern is the most specific.
2. A suppression with only a package name beats a wildcard pattern.
3. A suppression with only an image pattern beats a fully-wildcard rule.

The reason field of the winning suppression is the one displayed on the row.

## Viewing suppressed findings

Open any scan drawer and scroll to the vulnerability table. Suppressed rows look like this:

<Frame>
  <img src="/images/cve-suppressions/suppressed-row.png" alt="Vulnerability scan drawer with a suppressed row dimmed and labeled with a shield-off icon" />
</Frame>

Suppressed rows also carry through to the **Compare scans** view. Both the added and removed columns show the suppression state, so a finding that you've already accepted will not look like a new regression when comparing an older baseline.

## Fleet-wide replication

Suppressions are managed on the **control** Sencho instance and replicate automatically to every remote Sencho you've registered. There is nothing extra to configure:

- Creating or editing a suppression on the control pushes the full list to every remote.
- Remote instances show the suppression list in a read-only state. The **Add Suppression** and **Delete** buttons are hidden, and a banner explains that rules are managed upstream.
- Incoming scan results on the control and every remote apply the same suppression set.

If a push to a remote fails (for example because the remote is temporarily offline), Sencho records the failure and retries on the next fleet sync tick. See [Fleet Sync](/features/fleet-sync) for the details of how replication works and how to inspect push status.

## Removing a suppression

Click the trash icon on any row in the suppressions panel. A confirmation dialog calls out that removing the rule will cause matching findings to reappear in scan results.

To change a suppression's scope (for example, to narrow an image pattern or extend an expiry), delete the existing rule and create a new one with the updated fields.

## Troubleshooting

### I suppressed a CVE but the count on the badge is unchanged

Badge counts reflect the raw findings so they remain meaningful for alerting and policy evaluation. The filter is applied in the scan drawer, the comparison sheet, and every read surface, but the stored totals do not change. Open the scan drawer to confirm the row is dimmed with a shield-off icon.

### A suppression I added on the control is not visible on a remote

Replication runs on every write. If the push failed (network blip, remote restart), check the fleet sync status on the control under **Fleet → Sync status**. The remote picks up the latest state on the next successful push.

### I see suppressions on a remote but cannot edit them

Remote Sencho instances are read-only for security rules. Sign in to the control instance to add, edit, or delete suppressions. Changes sync automatically.

### A suppression does not match a finding I expect it to

Two common causes:

- **Image pattern mismatch.** The pattern uses glob syntax where `*` matches any sequence. `nginx*` matches `nginx:1.25` but not `docker.io/library/nginx:1.25`; use `*nginx*` for a broader match.
- **Expired rule.** If **Expires in** was set, the suppression stops applying after the deadline. The row shows an "expired" badge; edit it or create a fresh rule.
