An exposure window is the period between a vulnerability becoming usable against you and the fix running in production. The end point is easy to measure. The start point needs a decision, and you should write that decision down so the metric means the same thing next quarter.
Three possible start points
Teams use different clocks, and each answers a different question:
- Public disclosure or advisory date. How long after the world knew did we fix it?
- Date your tooling first detected it in your estate. How fast do we act once we know?
- Date the vulnerable version first entered your code. How long were we actually exposed?
The first is the best proxy for attacker opportunity. The second measures your team. The third is the truest exposure, but it requires history that many programs do not keep.
You can track more than one. Just label them. "Time to fix since disclosure" and "time to fix since detection" are two metrics, and the gap between them is a metric too. A large gap means you learn about problems late.
The end point is not "ticket closed"
Closing a ticket is a workflow event. Exposure ends when the fixed version is running where the vulnerable one was. That means merged, built, deployed, and old instances retired.
For libraries, a merged pull request is not the end if the service has not been redeployed. For containers, a rebuilt image is not the end if old pods still run. Measure to deployment where you can. If you cannot, say that your metric ends at merge and accept the understatement.
Exposure is not equal for every finding
A vulnerable library that is never called, or a service with no inbound path, is a different situation from an internet facing service with a known exploit. Count window length for all findings if you like, but headline the windows for items with exploit evidence or a reachable code path.
Tiering helps here. A common approach is a short target for items with active exploitation, a longer one for reachable but unexploited items, and a long one for the rest. See how SLA targets can be built in SLA clock start points explained.
Do not forget the pre disclosure period
Some vulnerabilities are exploited before a patch exists. For those, the window starts before any advisory. You cannot measure that start from your own data, but you can note it on the incident record and shorten the later part with faster detection and mitigations such as configuration changes.
Disclosure timelines elsewhere show how long vendors are given. Google's Project Zero policy, for instance, gives vendors 90 days to patch, with a shorter deadline when it sees in the wild exploitation. That tells you a fix may not exist on day one, and that your window can include a period where mitigation is your only tool.
A simple record to keep
For each finding, store four dates: first public, first detected, fix available, fix deployed. From those you can derive vendor delay, detection delay, and your own delivery time. Three small numbers explain more than one big one.
Quick check
Should an exposure window include weekends?
Yes. Attackers do not take weekends off, so measure in elapsed time even if your SLA is written in business days.
What if the fix is not available yet?
Record the date of the mitigation you applied and the date the real fix arrived. Report both, since the risk changed at the first one.
Sources
Last reviewed: 19 October 2026.
