mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-08 18:05:10 +00:00
Anso
732fc95415
Operators can accept known-benign findings once and have Sencho filter them out of scan drawers, comparison views, and other read surfaces. Suppressions replicate from the control instance to every remote node. * New cve_suppressions table with a COALESCE-based unique index so NULL scope slots collide the way users expect * Admin + paid-tier CRUD routes; writes are rejected on replicas * Read-time filter enriches vulnerability details and compare payloads without mutating stored counts * Settings > Security panel for managing rules, per-CVE suppress action in the scan drawer, dimmed rows with a shield-off indicator * Vitest unit tests for the filter (glob, expiry, specificity) and route tests (auth, tier, replica, UNIQUE conflict)
98 lines
6.0 KiB
Plaintext
98 lines
6.0 KiB
Plaintext
---
|
|
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 require a **Skipper** or **Admiral** license.
|
|
</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.
|