Survivorship bias in a time-to-patch statistic means the figure is calculated only from vulnerabilities that were eventually fixed, so the ones that were never fixed drop out. The result looks faster than reality. Always ask how many items were still open when the data was cut off.
The idea in one example
Imagine ten vulnerabilities. Eight get fixed in 10 days each. Two are still open after a year. If you average only the fixed ones, you report 10 days. If you count the open ones as at least 365 days so far, the picture is very different. The first figure is accurate for what it covers and misleading as a summary of the ten.
Evidence that open items are a big part of the story
The 2025 Verizon DBIR figure for edge devices came with a completion rate: 54% fully remediated, with a median of 32 days (Infosecurity Magazine). Read the two together. A median of 32 days applies to the group that finished. The remaining share is the part a median of completed work cannot show.
A related idea is the half-life. Veracode's public sector snapshot describes a half-life for fixing flaws of 315 days against an overall figure of 252 days (Veracode). A half-life asks how long until half the flaws are closed, which keeps the unfinished ones in view.
Where this bites in your own metrics
- A dashboard that shows "average days to close" for tickets closed this month ignores everything still open.
- Closing a ticket as "accepted risk" or "won't fix" removes it from the clock.
- Resetting a ticket when a finding is rescanned makes old items look new.
How to correct for it
- Report the open count and its age distribution next to every time-to-fix number.
- Track "percent fixed within the target window" for everything discovered in a period, not only for what closed.
- Show the oldest open item and the 90th percentile age.
- Count exceptions separately, with an owner and an expiry date, rather than deleting them.
The aim is a number that gets worse when you leave things unfixed.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how open and closed findings sit side by side, and notice how much the closed list alone would hide.
A note for vendor and customer questions
When a supplier tells you their average fix time, ask the same questions you would ask of any report: does the figure include vulnerabilities that are still open, and how are exceptions counted? A supplier that can show open items and their age is giving you more information than one that gives a single flattering average.
Quick check
Is median time to fix a bad metric?
No. It is useful, but pair it with the share still open and the age of the oldest items, so the unfinished work stays visible.
How do I count an accepted exception?
Keep it open in the data with a reason, an owner and a review date. Do not let it disappear from the denominator.
Safeguard supports this with continuous monitoring of your SBOM and dependencies, zero-day discovery, and policies and gates that you set yourself. The free scan at gold.safeguard.sh/scan is a quick way to see your own starting point.
Sources
- Infosecurity Magazine, Verizon DBIR reveals jump in vulnerability exploitation
- Veracode, 2025 State of Software Security Public Sector Snapshot
Last reviewed: 19 October 2026.
