You are probably running an inherited vulnerability schedule: fix top-severity findings within 30 days, high severity within 60, and medium within 90. That calendar assumed attackers took months to build working exploits. In 2018, the median interval from disclosure to first observed exploitation was 771 days. According to tracking by Resilient Cyber, that median has dropped to single-digit hours, with 28.3% of exploited flaws weaponised within 24 hours of disclosure. Discovery and exploitation both accelerated, but patch deployment cadences did not. Understanding why fixed patch SLAs stopped working means distinguishing discovery from exploitation, analysing the economics behind weaponisation, and re-planning remediation around asset exposure. Start with the distinction the calendar quietly depends on.
What is the difference between a vulnerability being discovered and a vulnerability being exploited?
Discovery occurs when a researcher or automated tool identifies a code defect and creates a descriptive security record. Exploitation happens when an adversary runs functional code against that defect to alter system behaviour or access protected data. Discovery creates an inventory record, while exploitation creates an active operational timeline.
A severity-sorted dashboard cannot distinguish an unexercised record from an active threat. A Common Vulnerabilities and Exposures (CVE) entry confirms a flaw exists across shared software components, but does not indicate whether an adversary can abuse it.
Relying on base scores produces predictable misallocations. A flaw can hold a high Common Vulnerability Scoring System (CVSS) score and sit harmlessly in your backlog for years without an exploit. Conversely, a flaw with a moderate base score can see widespread abuse across the internet if the affected component is exposed.
Attack distributions are skewed. Google Threat Intelligence documented that while monthly disclosures climbed past 10,000, only 141 distinct flaws were both disclosed and actively exploited in the wild across the first eight months of 2026. The volume issue is explored in why vulnerability disclosure is outrunning everyone’s ability to patch, while automated submission noise is covered in AI slop in vulnerability reporting.
These metrics describe third-party software. Your proprietary code sits outside public registries: it has no public advisory, no Exploit Prediction Scoring System (EPSS) rating, and no public patch for adversaries to examine. That divergence between what gets counted and what actually gets attacked is the organising idea behind the AI vulnerability flood that breaks the patch queue.
Three distinct clocks govern every public flaw:
- Time from flaw introduction to initial discovery
- Time from discovery to public disclosure
- Time from public disclosure to first observed exploitation
The first two clocks run vendor-side and are invisible to your team. Only the third clock, the disclosure-to-first-exploitation window, bounds how long defensive controls can wait before an adversary arrives.
Why has the disclosure-to-exploit window collapsed from hundreds of days to hours?
The disclosure-to-exploit window collapsed because automated binary analysis and generative models made exploit development cheap. Software patches provide a blueprint of the underlying flaw, automated tools generate working exploit scripts in minutes, and attackers run high-volume internet scans against exposed services rather than manually selecting corporate targets.
Adversaries once required months to operationalise newly disclosed flaws. A Cloud Security Alliance analysis documented this figure dropping from a 771-day median in 2018 to single-digit hours today. While methodologies differ between trimmed means and median timelines across datasets, all major telemetry tracks the same downward direction.
Four technical and economic factors drove this collapse:
First, patch diffing is now cheap. A public software patch is an exact specification of the defect. Automated tools compare pre-patch and post-patch binaries to isolate the vulnerable code path. Research by Anthropic showed that autonomous systems can generate functional exploit chains from security patches within hours of release.
Second, exploit development shifted from scarce specialist labour to throughput. Crafting an exploit previously required specialist reverse engineering over multiple weeks. Adversaries now combine automated models with reusable exploit primitives, driving the marginal cost of weaponisation to near zero.
Third, publication velocity supplies raw material. Annual disclosures now exceed 50,000 CVEs. In this environment, the n-day vulnerability, an exploit developed after the vendor releases a patch, has replaced the zero-day as the primary weapon. Each published patch feeds automated diffing systems, circulating weaponised code before operations teams complete change evaluations. For supply-chain risks when maintainers disappear, see what happens downstream when open source maintainers stop patching.
Fourth, attacker economics favour untargeted perimeter scanning. When weaponisation is cheap, selection pressure disappears: automated scanning sweeps the public internet for any vulnerable service rather than profiling individual targets. Sysdig observed attackers compromising live applications in under 20 hours based on advisory details. The gap between patch release and weaponised scanning is now commonly shorter than standard enterprise testing cadences.
How should patch SLAs be re-planned when the exploitation window is measured in hours?
When the exploitation window is shorter than your change cycle, your team should replace static calendar bands with dynamic remediation windows driven by verified exploitation and asset exposure.
The order teams increasingly apply is KEV first, EPSS second, exposure third:
- Observed exploitation: The CISA Known Exploited Vulnerabilities (KEV) catalogue confirms real-world attacks. These findings require mitigation within 24 to 72 hours, regardless of CVSS base score.
- Probability of attack: For flaws not listed in KEV, the Exploit Prediction Scoring System (EPSS) estimates likelihood. Elevated EPSS scores indicate public exploit tooling exists and automated attacks are probable within 30 days.
- Asset exposure: Teams evaluate threat scores against runtime context. An unauthenticated public gateway demands fast mitigation, while an internal service behind identity boundaries can wait for standard release cycles. The triage logic is set out in which findings deserve the new windows, and handling accumulated debt is covered in diagnosing, funding and reporting a backlog that cannot be cleared.
One regulator has already moved this way. Under CISA Binding Operational Directive 26-04, federal agencies retired flat 14-day deadlines in favour of flexible windows based on internet exposure and automated exploitation.
When deployment takes longer than the exploitation window, your team must rely on containment. Virtual patching, such as web application firewall rules, disabled feature flags, and network isolation, blocks the exploit path without modifying application source code. It counts as mitigation rather than remediation, buying time for safe testing. In regulated settings like healthcare or industrial control, where validation rules restrict short-notice code changes, compensating controls are the available defence.
Finally, measure time from patch availability to mitigation, rather than tracking ticket closure in an issue queue. Ticket closure is an administrative milestone, whereas mitigation marks when the exposure actually ends.
The 30/60/90-day calendar was calibrated against an exploitation curve that has since gone. Teams met it because the work was done; the schedule simply measures an interval the attacker no longer uses. Managing risk in this environment means separating theoretical severity from active exploitation, containing perimeter entry points, and scheduling permanent fixes based on real-world reachability. For an end-to-end perspective on restructuring your pipeline, read the whole disclosure-to-remediation story.
Frequently Asked Questions
What is the difference between a zero-day and an n-day exploit?
A zero-day is exploited before the vendor publishes a fix; an n-day is exploited after the patch exists. That distinction used to favour defenders, because a zero-day was rare and expensive to build while an n-day required serious reverse-engineering of the fix. Patch diffing inverted it. The n-day is now the cheaper, more common object, and the dangerous one for anyone running a lagging queue.
What is a KEV-based patch SLA?
A KEV-based SLA sets the remediation clock from evidence of exploitation rather than from a severity score. If a CVE appears in CISA’s Known Exploited Vulnerabilities catalogue, the window is hours to days regardless of its CVSS base score. Everything else is triaged separately, usually by EPSS and exposure. The catalogue updates within roughly a day of confirmed exploitation, so it is a signal you can act on rather than wait out.
Does a high CVSS score mean I should patch that finding first?
No. CVSS describes the potential impact if a flaw were used, not whether anyone is using it or how soon they will. A 9.8 in an unreachable library function can wait longer than a 6.5 that is internet-facing and already listed in KEV. Keep CVSS as an impact qualifier when you rank findings; let exploitation likelihood and reachability set both the order and the clock.
Is the drop from 771 days to single-digit hours a genuine trend or an artefact of better measurement?
Both, partly, and the figures are trend endpoints rather than a continuous series. The historical 771-day median came from incident-response and breach-report lineages (CrowdStrike, Mandiant, Verizon DBIR) that measured large, mass-exploited populations. Current figures describe first exploitation and are often trimmed means or medians of quite different samples. Treat the direction as robust and the exact number as population-specific.
How do I know whether a vulnerability in my estate is being exploited right now?
Check KEV first, because it is evidence rather than prediction: if the CVE is listed, exploitation is confirmed somewhere and should be treated as present until you can show otherwise. Then use EPSS for the rest as a probability, not a verdict. Neither tells you about your own exposure, so pair both with reachability and internet-facing status from your asset inventory.
What is virtual patching, and does it count as remediation?
Virtual patching blocks the exploit path without changing the vulnerable code: a WAF rule, a disabled code path, a feature flag, or network isolation in front of the service. It counts as mitigation, not remediation, and it buys hours rather than closing the finding. That is enough when the window is shorter than your change cycle, provided each control has a named owner and an expiry date.
What do I do when there is no patch available yet?
Treat the absence of a patch as an exposure problem rather than a waiting problem. Reduce reachability: take the service off the public internet, restrict the vulnerable function behind authentication, or block the exploit pattern at the edge. Then watch for the vendor fix and for a KEV listing, which can arrive before it. Maintainers who have stopped patching are a supply-side case with its own handling.
How do I write a patch SLA that customers and auditors will accept?
Write the SLA around classes of evidence, not calendar bands. Commit to hours for KEV-listed findings, days for high EPSS on exposed assets, and a risk-based window for the remainder, and state explicitly that compensating controls satisfy the clock where change windows or certification prevent a fix. Measure time to mitigation, including virtual patching. An SLA nobody meets is worse than a looser one people do.
Does this apply to my own first-party code, or only to third-party CVEs?
The published numbers only describe CVE-bearing third-party software, so your own services sit outside that curve entirely. First-party exposure is real but unmeasured: there is no KEV entry for a bug you shipped, no EPSS score, and no patch for an attacker to diff. Judge it on exposure and blast radius, and expect your internal defect queue to be the only signal you get.
How fast does CISA KEV update, and can I treat it as a deadline?
The catalogue is updated within roughly a day of confirmed in-the-wild exploitation, which makes it the fastest reliable public signal you can plan around. Treat it as the start of the clock, not the deadline itself. By the time a CVE is listed, exploitation is already happening, so the question is how quickly you can mitigate, not whether you have time to schedule.
If windows are now measured in hours, should we simply automate patching?
Automation helps only where the change is safe to make unattended, which across most production estates is a small subset. Patching everything automatically trades one exposure for outages and rollbacks, and it does not help where certification or downtime forbids the change at all. Automate the detection, the decision and the containment; keep a human gate on the change itself.
