Patch statistics usually come from one of four places: scanner telemetry, breach and incident investigations, surveys, or public catalogs. Each sees a different slice of the world, so each is biased in a different direction. Knowing the source tells you what the number can and cannot represent.
The four common sources
| Source | What it sees | Typical blind spot |
|---|---|---|
| Scanner telemetry | Assets scanned by one vendor's customers | Customers who do not run that product, unscanned assets |
| Breach investigations | Incidents that were reported and analyzed | Organizations that were never breached, or never told anyone |
| Surveys | What respondents say they do | Self reporting, who chose to answer |
| Public catalogs | Exploited or disclosed flaws and dates | Fix times on the customer side are absent |
Examples from the 2025 edge device data
The Verizon DBIR is built from breach and incident data. Tenable said its contribution analyzed over 160 million data points across 17 edge device CVEs, using its own telemetry (Tenable). That is a large dataset, and it is still a view through one vendor's customer base. Customers who pay for vulnerability scanning are probably not a random sample of all organizations, in either direction. They may be more mature than average, or they may be scanning because they have a problem.
What bias looks like in practice
- Telemetry sees assets that are scanned. Forgotten servers, shadow IT and unmanaged devices rarely show up, yet attackers find them.
- Breach data over represents the vulnerabilities attackers actually used, which is useful for priority and misleading as a picture of all flaws.
- Surveys tend to report policy, such as a target of 30 days, which may differ from practice.
A simple method to apply
- Name the source in one line next to the number.
- Ask who is missing from the data.
- Ask whether the direction of the bias would make the number look better or worse than reality.
- Prefer a range of sources over a single one when you make a decision.
Using this in your own program
Your own data has the same issue. If your scanner only covers the production network, your time-to-fix figure says nothing about the build servers or developer laptops. State coverage next to every metric. An asset inventory is the first step, and it is also what the asset discovery capability in Safeguard is built for. The free scan at gold.safeguard.sh/scan can show a first view of your dependencies.
Reading a source line
A useful habit is to rewrite each statistic as a sentence that includes its source: "Among organizations scanned by this vendor, the average time to remediate this flaw was X days." If the sentence sounds smaller than the headline, the headline was larger than the evidence.
Quick check
Is telemetry data more accurate than surveys?
It measures behavior rather than opinion, which helps, but it still reflects the vendor's customers and scanned assets only.
Why do breach reports focus on exploited flaws?
Because they analyze incidents. That makes them valuable for priority, but they do not describe the fix time for all vulnerabilities.
Sources
- Tenable, Verizon 2025 DBIR research collaboration on CVE remediation trends
- Infosecurity Magazine, Verizon DBIR reveals jump in vulnerability exploitation
Last reviewed: 19 October 2026.
