Most security programs track time-to-patch (TTP) as their primary measure of remediation performance. A CVSS Critical vulnerability has a 30-day SLA. High is 60 days. Medium is 90 days. The security team reports patching rates against those SLAs, and if the numbers are good, the program is considered to be performing well.
The problem is that time-to-patch is not the relevant metric for assessing exposure. The relevant metric is the gap between when a vulnerability becomes exploitable and when it is remediated. Call this the exploitation-to-patch delta, or the window during which an attacker can successfully exploit the vulnerability before it is closed. Time-to-patch starts at disclosure. The exploitation window starts when weaponized exploit code appears. These are different events, and in many cases they are separated by days, not weeks.
The CVE Timeline: Disclosure Is Not the Starting Gun
A vulnerability moves through several stages from discovery to active exploitation. The discovery-to-disclosure gap is the period when the vulnerability exists in software but has not been publicly reported. This gap varies enormously: from zero (zero-days with no prior report) to years (vulnerabilities discovered by researchers who follow coordinated disclosure timelines). During this period, the vulnerability may be known to the discoverer and to the vendor but is not publicly exploitable because the details are not public.
Disclosure triggers the CVE assignment and NVD publication. This is when scanning tools pick up the vulnerability and when time-to-patch SLAs typically start running. It is also when the race begins. Security researchers, red teams, and threat actors all start analyzing the disclosed vulnerability to understand whether it is exploitable, how complex exploitation is, and whether existing exploitation frameworks can be adapted.
For many high-severity vulnerabilities, working proof-of-concept exploit code appears within 24-72 hours of disclosure. For vulnerabilities in widely deployed software with large research audiences (Apache Log4j is the canonical example), the timeline from disclosure to active exploitation across internet-facing systems was measured in hours, not days. The 30-day remediation SLA was operating against a 12-hour exploitation window.
What Determines How Fast Exploitation Follows Disclosure
The speed at which weaponized exploits appear after disclosure is not uniform. Several factors predict faster exploitation. First, the vulnerability's complexity: a simple buffer overflow with a well-understood exploitation technique in a common memory layout will be weaponized faster than a complex logic vulnerability that requires application-specific knowledge to exploit. Second, the size of the research community watching the disclosure: vulnerabilities in components with large install bases attract more researchers and threat actors simultaneously. Third, the availability of prior art: if the vulnerability is similar to a previously exploited class, existing tools can often be adapted quickly.
Fourth, and increasingly important, automated exploitation tooling: frameworks that test applications for known vulnerability patterns can incorporate new CVE signatures rapidly. An automated scanner that has been updated with a new Log4Shell detection pattern can be deployed against millions of internet-facing endpoints within days of the exploit becoming public. The attacker resources required to exploit a CVE at scale have dropped substantially as automated tooling has improved.
The implication for time-to-patch SLAs is that their appropriateness depends entirely on the specific vulnerability's exploitation speed profile. A 30-day Critical SLA might be appropriate for a complex vulnerability with limited research interest. For a vulnerability in a widely deployed library with a straightforward exploitation technique, a 30-day SLA is an acknowledgment that your application will be exploitable for 30 days after a functional exploit ships.
Measuring the Exploitation Window for Your Application
A more informative metric than time-to-patch alone is what I will call the exposure window: the duration between when a vulnerability affecting your application becomes exploitable (exploit code available, not just disclosed) and when your application is no longer vulnerable (patched or mitigated). This metric captures the actual risk period rather than the process metric.
Measuring exposure windows requires tracking two things that most security programs track separately or not at all. First, exploitation availability: when does weaponized exploit code appear for a given CVE? This is tracked by threat intelligence services, Metasploit module publication dates, and exploit-db entries. Second, actual patch deployment: when is the patch deployed to production, not just when is the ticket closed or the build updated in staging?
Most vulnerability management systems track the time from disclosure or ticket creation to closure. They rarely track the time from exploitation availability to production deployment. The gap between those two measurements is the actual risk period.
The Detection Gap: What You Do Not Know Is Exploiting You
The exposure window metric also highlights a more uncomfortable scenario: vulnerabilities that were exploited before they were disclosed. Zero-day exploits in the hands of sophisticated adversaries represent exposure windows that start before the CVE timeline begins. By definition, these cannot be detected through CVE monitoring or time-to-patch tracking.
The detection approach for pre-disclosure exploitation is behavioral. If a vulnerability in your logging library allows an attacker to achieve remote code execution, the execution will produce behavioral signals: new processes spawned from the application process, unexpected network connections, file system writes in unusual locations. These signals appear whether the exploit is a zero-day or a known CVE. Detection based on behavioral anomaly rather than signature matching is the layer that catches exploitation that signature-based scanning misses.
This is not primarily a vulnerability management problem. It is an endpoint detection and runtime security problem. But it connects to the CVE-to-breach timing framework because it explains why even a perfect time-to-patch track record does not eliminate exploitation risk: you can only patch what you know about, and the exploitation window for unknown vulnerabilities starts before you have any visibility.
Using Timing Data to Improve Prioritization
The practical application of CVE-to-exploitation timing data is in prioritization. Not all CVEs move at the same speed from disclosure to active exploitation. Tracking exploitation availability as a dimension in your vulnerability prioritization model changes which vulnerabilities get accelerated treatment.
A vulnerability with a CVSS score of 7.5 (High) that has a working Metasploit module published within 48 hours of disclosure should be prioritized above a CVSS 9.0 (Critical) vulnerability in a component with no known exploitation activity and a complex attack vector. The CVSS score reflects theoretical severity. The exploitation timeline reflects actual attacker behavior.
Several threat intelligence data sources track exploitation activity and can be integrated with vulnerability management tooling. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with confirmed active exploitation. Metasploit and exploit-db publication timelines provide exploitation availability dates. Integrating these signals into your remediation prioritization produces a list that is ordered by actual exploitation risk rather than theoretical severity scores.
Time-to-Patch Is Still a Useful Metric
This is not an argument that time-to-patch is useless. It is a process metric that reflects the efficiency of your remediation workflow. Improving time-to-patch reduces the exposure window for the average vulnerability and reduces the risk surface for any given CVE. The argument is that time-to-patch alone, measured against fixed SLAs from disclosure date, gives an incomplete picture of security performance.
A comprehensive picture includes: time from disclosure to detection (does your tooling surface the vulnerability quickly), time from exploitation availability to prioritization adjustment (does your program react to exploit availability signals, not just disclosure), time from patch available to production deployment (does the deployment pipeline allow rapid emergency patching when needed). Each of these components contributes to the exposure window. Tracking only the last one misses the earlier steps where the window is widest.