Safeguard
Research•

Zero day metrics that matter, and the ones that mislead

Counting zero days found is a poor scorecard. Track time to know, time to contain and exposure window, and read any vendor numbers with care.

Safeguard Security Team
5 min read

The useful zero day metrics measure your response, not the number of zero days in the news: time to learn you are exposed, time to contain, and how many assets remain exposed. Counts of zero days found, patched or blocked are easy to publish and easy to misread.

What counts as a zero day?

NIST's glossary, quoting CNSS and NISTIR sources, defines a zero day attack as one that exploits a previously unknown hardware, firmware or software vulnerability. Note the phrase "previously unknown". Once a fix exists and is public, the vulnerability is no longer a zero day for the defenders who know about it, though it stays dangerous.

Metrics that matter

Time to know. From public disclosure or first report to the moment you can list affected assets. This depends on inventory, not scanners. If you keep a software inventory that records dependencies, the answer is a query. If not, it is an email thread.

Exposure window. The time an affected asset stays exposed from disclosure until it is fixed, mitigated or isolated. Report the median and the worst case. The worst case is where the risk sits.

Time to contain. Many events have no patch for days. Containment means a workaround, a block, a feature flag or an isolation step. Measure how long it takes to apply an agreed workaround, and whether you have a rehearsed list of options.

Coverage of the inventory. The share of your systems and software components you can actually query. A fast response to 60 percent of your estate is a slow response to the rest.

Reachability share. Of the affected components, how many are called in your code or exposed to the internet. This turns a long list into a short one. Do not count a finding as risk until you know.

Exercise results. Time taken in a drill where you pretend a major library has a flaw tonight. Run it twice a year. Drills give you data from your own team rather than from a vendor report.

Metrics that mislead

Number of zero days discovered or blocked. It depends on the definition used, on what the vendor counts, and on what happens to be disclosed. It says nothing about your exposure.

Total vulnerabilities fixed. Volume rewards cheap fixes. A team can clear hundreds of low risk items and leave the one that matters.

Mean time to patch across everything. An average hides the tail. It also mixes systems with different change windows.

Scores used alone. CVSS Base scores measure severity, and the user guide says they should not be used alone to assess risk. EPSS estimates exploitation probability over 30 days, and FIRST says it is not a complete risk score. Neither is a response metric.

Detection rates from a vendor's test. Unless you can see what was tested and how, treat these as marketing. Ask for the method and test on your own samples.

Dwell time without context. A shorter dwell time looks good but may reflect noisier detection rather than faster response.

How to report them

Pick four numbers and show them as a trend per quarter: time to know, median and worst exposure window, inventory coverage, and reachability share. Add a one line note on any event in the period. Leadership needs to see direction and the worst case, not a count.

What to compare against

Compare against yourself, not against another company. Your estate, change windows and tools differ. Where you want an external reference, CISA's catalog of known exploited vulnerabilities gives public dates for when exploitation was confirmed, which you can compare to your own response time for those entries.

Where Safeguard fits

Safeguard offers zero day discovery in agentic and scanner modes, reachability analysis that shows whether affected code is called, and policies and gates that can block a vulnerable release. These support time to know and the reachability share. You still need your own drills and your own definitions.

What to do

  1. Build a queryable software inventory, then measure coverage.
  2. Record time to know for every notable disclosure.
  3. Track median and worst exposure window.
  4. Prepare containment options per component type.
  5. Add reachability to cut lists down.
  6. Drill twice a year and record the numbers.
  7. Retire counts that nobody acts on.

Quick check

Which single zero day metric matters most?

Time to know which of your assets are affected. It depends on inventory quality and sets the pace for everything after.

Why is a count of zero days patched misleading?

It depends on what is counted and what happened to be disclosed, and it says nothing about your exposure window.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.