Suppress a finding only with a reason, an owner and an expiry date, and ideally a VEX statement saying why it does not affect your product. Never delete the finding. A suppression without an expiry is a permanent blind spot that nobody remembers approving.
What VEX is for
CycloneDX describes VEX as a way to convey the exploitability of vulnerable components in the context of the product in which they are used. CISA similarly describes it as an attestation that indicates whether products are affected by known vulnerabilities. In practice, a VEX statement lets you say: this CVE is in a package in our image, and here is why it does not matter, or here is what we did about it.
Valid reasons to suppress
| Reason | Evidence to keep |
|---|---|
| Package not present | Scan output showing no match; image digest |
| Present but code not loaded | Reachability result or a test |
| Vulnerable function not called | Call graph or code review note |
| Mitigated elsewhere | Description of the control and its owner |
| Scanner false positive (for example a backported fix) | Link to the distro advisory showing the fix |
| Accepted risk, no fix | Risk sign-off and a review date |
Invalid reasons
"Too many findings." "The sprint is full." "It is only medium." These are prioritization reasons, which belong in a queue and not in a suppression list.
A suppression record
Write down these fields every time:
- The CVE or advisory id and the affected package and version.
- The image digest or service the decision applies to.
- The status: not affected, fixed, under investigation or accepted.
- The justification, in one or two sentences.
- The owner and approver.
- The expiry date, shorter for riskier items.
- A link to the evidence.
Scope it narrowly
Suppress for one image or service, not for the whole organization, unless you have shown the reason applies everywhere. Org-wide ignores quietly cover new images that happen to include the same package in a reachable way.
Review on a schedule
At expiry, rerun the check. If a fix now exists, apply it. If the reason still holds, renew with a new date. Keep the history, because auditors and customers ask how you handled a known CVE. For related thinking, see what to do when no fix exists.
Try it yourself
Click through it at your own pace, or open it full screen.
Note which questions in the check would become the justification line in your suppression record.
Quick check
Is a suppression file in Git enough?
It is a good start because history is kept. Add owner, reason and expiry fields and review them.
Should VEX be shared with customers?
Often yes, because it saves them from chasing findings that do not affect them. Keep statements accurate and current.
Safeguard offers reachability analysis and policies to support these decisions; try the free scan.
Sources
Last reviewed: 19 October 2026.
