A patch statistic is only as meaningful as the list of vulnerabilities behind it. Some reports cover every published CVE, some only exploited ones, some a hand picked set of 17. Each choice is reasonable and each changes the number. Ask what the denominator is before you read the result.
Common ways a set is chosen
| Selection | Example | Effect on the time |
|---|---|---|
| All published CVEs | Every flaw found by a scanner | Dominated by low severity items that wait |
| Known exploited only | Entries in the CISA catalog | Usually faster, because urgency is higher |
| One device class | Edge devices and VPNs | Reflects that class only |
| Severity filtered | Critical and high only | Faster than the full set |
| Named incidents | CVEs in a breach report | Shaped by what attackers chose |
A real example of a curated set
Tenable's contribution to the 2025 Verizon DBIR focused on 17 edge device CVEs that the report highlighted, and noted that each was on the CISA known exploited list (Tenable). That is a deliberate choice: the most exploited edge flaws. It makes the result useful for edge priorities. It does not say how long a typical medium severity library update waits.
What the known exploited catalog contains
The CISA catalog lists vulnerabilities with evidence of active exploitation, and each entry carries a date added and a due date for federal civilian agencies (CISA). A statistic built from catalog entries therefore covers flaws with exploitation evidence, not the whole set of CVEs.
Questions that expose the selection
- How many vulnerabilities, and who picked them?
- Was the list chosen before or after the outcomes were known?
- Were flaws with no fix available excluded?
- Were end of life products excluded, since they cannot be patched?
Matching the selection to your decision
If you want a target for urgent exploited flaws, a known exploited based figure is relevant. If you want to size the effort of your entire backlog, you need the full population, including the slow tail. Do not use the first to justify ignoring the second.
Reading the fine print
Look for sentences such as "vulnerabilities with a known fix" or "supported products only". These small phrases exclude exactly the hard cases: flaws with no patch and software past end of life. A figure that leaves them out will always look better than your own full backlog.
Quick check
Why do exploited flaws get patched faster?
Often because the urgency is visible and deadlines exist for some organizations. That is also why a figure for exploited flaws is not a figure for all flaws.
Is a hand picked set of CVEs biased?
It is selective by design. That is fine when disclosed, but the result describes that set only.
Safeguard can help with the inventory side of this. Its SBOM and dependency scanning and reachability analysis show which vulnerable components you run and which your code actually calls. You can try the free scan at gold.safeguard.sh/scan.
Sources
- Tenable, Verizon 2025 DBIR research collaboration on CVE remediation trends
- CISA, Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
