An empty vulnerability backlog is good news only if you know how it got empty. It can mean everything was fixed. It can also mean findings were closed as accepted, suppressed or never detected. The list tells you about process, not about safety.
Myth: an empty list means we are secure
Fact: it means that no known finding is open in your tracker. Unknown flaws, undiscovered assets and misconfiguration are not in the tracker at all.
Myth: more closed tickets means more progress
Fact: closing a ticket as not exploitable or accepted risk is a decision, and decisions can be wrong. Track how many were closed by a fix and how many by an exception, and review exceptions on a schedule.
Myth: severity tells us what to fix first
Fact: severity describes potential impact in general. FIRST describes EPSS as a probability of exploitation in the next 30 days and says it is not a severity or risk measure, and that it does not know your environment. CISA's Known Exploited Vulnerabilities catalog lists issues that have been exploited in the wild, and CISA recommends using it as an input to prioritisation. Use both together with your own context.
Myth: not affected means ignore
Fact: a statement that a product is not affected is useful, but it needs to be recorded with a reason so someone can check it later. Vulnerability Exploitability eXchange documents exist for this purpose, and CISA has published minimum elements for them.
Better numbers than the raw count
- Known exploited vulnerabilities present in production: should be zero or have a dated plan.
- Median days from disclosure to deployed fix, by severity.
- Percentage of assets with an up to date inventory.
- Open exceptions past their review date.
- Share of findings closed by fix rather than by exception.
How to report an empty list honestly
State the scope, the date, the data sources and how many exceptions are open. Something like: "No open critical findings across the listed services as of 19 October; three accepted exceptions, each with an owner and review date."
A habit worth building
Each month, sample ten closed findings and check that the closure was right. It is quick, and it catches both bad suppressions and good fixes that were never deployed.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Is an empty backlog a good target?
It is a fine outcome and a poor target. Targets like time to fix and no known exploited issues in production resist gaming better.
How often should exceptions be reviewed?
Set a date at the time of acceptance, commonly tied to severity, and review on that date.
Sources
Last reviewed: 19 October 2026.
