Suppressed and risk accepted vulnerabilities are still present in the software, so a dashboard should show them in a separate, visible category rather than deleting them from the totals. Each needs an approver, a reason and an expiry date, and the category count should be reported next to the open count.
Why hiding them distorts the picture
If suppressed items vanish from the open count, the number falls without any risk being removed. Two teams with the same real exposure then look different based on how liberally they use suppression. Over time, a growing pile of old suppressions is a hidden backlog.
A simple state model
| State | Meaning | Counted as open? | Needs expiry? |
|---|---|---|---|
| Open | Needs action | Yes | No |
| Fixed | Code or version changed | No | No |
| Not affected | Evidence shows the vulnerable code is not used | Shown separately | Review on change |
| Accepted | Known, risk consciously taken | Shown separately | Yes |
| Deferred | Will fix later, date set | Yes, with flag | Yes |
| False positive | Scanner matched wrongly | No, but audited | Review sample |
Keep the states few and the definitions written. Teams will map real situations onto whatever labels exist, so unclear labels produce unclear data.
Rules that keep it honest
- Every suppression has a named approver, a reason in a sentence, and an expiry date. Without expiry, suppression becomes permanent by default.
- Approval authority rises with severity, so a low severity item can be approved by a team lead and a critical one by a security owner.
- Expired items return to open automatically and trigger a review.
- Suppressions are visible on the dashboard as a count and an age distribution.
- A periodic sample audit checks whether the stated reasons still hold.
Metrics worth tracking
- Number of active suppressions, by severity.
- Share of suppressions past their review date.
- Share of suppressions that have no approver recorded.
- Average age of accepted items.
If the share past review date is large, the exception process is not working, whatever the open count says.
False positives are different
A false positive is a statement that the scanner is wrong. It does not mean risk was accepted. Keep it apart from acceptance, and sample these decisions occasionally, since a wrongly dismissed finding is more costly than an unnecessarily kept one.
For auditors and customers
When someone asks for open vulnerability figures, give open plus accepted and say what is in each. A figure with a visible exception count is far more credible than a smaller number with no explanation.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Policies and gates can require an expiry on every exception, and compliance evidence automation keeps the approvals on record. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does an accepted risk count as fixed?
No. The vulnerability remains. Count it in its own category and keep it visible.
How long should an exception last?
Set it by severity and review it before expiry. Shorter windows suit higher severity items.
Last reviewed: 19 October 2026.
