Will AI End Vulnerability Management?

Opening model

Persistence does not mean AI fails, workflows remain unchanged, or defects never decline. It means that on 2028-02-06 a mainstream enterprise still faces enough materially exploitable post-release vulnerabilities—and enough applicability, exposure, patch, rollout, and exception decisions—that an ongoing reactive vulnerability-management function remains necessary.

My causal model is:

installed vulnerable stock + material new escapes + newly discovered legacy defects + attacker weaponization − pre-release prevention − safely deployed remediation = residual operational burden

The extinction thesis is conjunctive: rapid AI capability must become reliable blind coverage, then broad enforced adoption, then safe deployment across a heterogeneous estate, while outpacing software growth and attackers. Persistence requires only a material residual path.

First, current exploitation-relevant stock and flow are substantial. CISA added 177 KEVs across exactly 31 complete 2026 weeks—every week nonzero—versus 617 across 156 complete baseline weeks. More importantly, about 21% of the 2026 additions had been published at least a year earlier, and the 90th-percentile publication-to-KEV-addition lag was 1,552 days. New-code gates therefore cannot alone remove the installed-stock queue (EV-006, EV-007). This is not a raw-CVE argument: source onboarding, backfills, registry policy, and changed enrichment materially distort publication series (EV-003, EV-004, EV-029).

Second, this stock is operationally consequential. Vulnerability exploitation accounted for 31% of initial access in Verizon’s incident corpus, making it the most common reported vector (EV-008). Google still observed 90 exploited-before-public-patch zero-days in 2025, including 43 affecting enterprise technology, although the browser category improved materially (EV-034). The last point matters: focused engineering can suppress particular channels without making the heterogeneous enterprise queue marginal.

Third, patch creation is not deployed remediation. In 515,170 KEV/organization observations, 26% were fully remediated, 16% wholly unremediated, and median full remediation was 43 days. Separate scanner data showed 35% of 2025 instances open at day 28 and a 9% long tail representing approximately 47 million detections (EV-009, EV-010). AI may draft a correct patch quickly while asset discovery, ownership, compatibility, release authority, testing, maintenance windows, and downstream installation remain unresolved.

Fourth, AI discovery can enlarge queues before automation closes them. Glasswing’s reviewed subset was 90.8% valid, strong evidence that high-volume AI discovery is real (EV-013). Yet the same campaign had 827 confirmed high/critical findings awaiting disclosure and only 75 of 530 disclosed high/critical findings then marked patched. Its young cohorts are right-censored, but maintainers asking the campaign to slow down directly identifies coordination capacity as a bottleneck (EV-014). Census III strengthens that mechanism: among the examined leading non-npm projects, 40% depended on one or two developers for more than 80% of commits, and 81% depended on ten or fewer (EV-027). Some critical legacy systems cannot be repaired independently of modernization (EV-028).

Fifth, current autonomy remains endpoint-sensitive. On 920 CyberGym-E2E tasks, GPT-5.4 achieved 87.1% patch-only and 65.9% S3, but only 22.2% strict hidden-target S4 closure; uncapped Opus 4.6 reached 26.2% S4 (EV-012). That is rapid progress and a large remaining gap. Independent code-security results likewise show functionality without security: one adversarial repository benchmark reported 61% functional success but only 10.5% secure-and-functional success, while a peer-reviewed C-family study left roughly 21–25% of identified vulnerabilities unresolved after explicit security prompting (EV-019, EV-020).

Finally, the race is two-sided. A randomized field-study synthesis estimated 26.08% more completed developer tasks with AI, increasing defensive capacity and change volume simultaneously (EV-024). ExploitGym shows frontier agents producing intended-target exploits for meaningful subsets of supplied vulnerable programs (EV-021). Persistence does not assume every extra change is insecure; it assumes prevention, deployment, and governance must improve faster than code volume, latent-stock discovery, and weaponization.

Why the strongest extinction mechanisms are not yet decisive

I grant rapid benchmark progress without qualification. AIxCC found 86% of its synthetic targets, patched 43 of 63, found 18 novel real vulnerabilities, and averaged about 45 minutes per patch (EV-011). CyberGym’s S3 result is already roughly two-thirds for a leading configuration (EV-012). Static capability would be an indefensible assumption.

I also grant the first-party advantage. Glasswing first-party users reportedly patched more than 2,100 findings in three weeks (EV-014), and GitHub reports supported Autofix alerts reaching a fix in a median 28 minutes rather than 90 minutes manually (EV-018). Source access, CI, tests, merge authority, telemetry, and deployment control can collapse the loop. Managed SaaS and auto-updating platforms are therefore the strongest candidates for early practical obsolescence.

Platform distribution makes that pathway plausible: multiple major vendors are converging on continuous find/verify/fix workflows through existing cloud and developer channels (EV-017). But availability is not enforced coverage. The adoption evidence shows broad assistant use alongside distrust, “almost right” outputs, debugging overhead, and limited appetite for deployment autonomy (EV-023). Most importantly, no representative audited baseline establishes enforced repository coverage, reduced post-release escapes, reduced vulnerability-days, or reduced total VM labor (EV-035).

Backlog burn-down is also a valid extinction mechanism. An AI discovery wave can expose old debt, temporarily raise findings, and then prevent replenishment. But that hypothesis needs cohort evidence separating pre-gate legacy discoveries from post-gate escapes. Current evidence instead shows old vulnerabilities continuing to enter KEV, discovery outrunning coordination, and persistent exposure tails (EV-007, EV-010, EV-014). Burn-down is plausible; completion by the central horizon is not yet demonstrated.

Forecast

My probabilities are:

• 12 months, 2027-08-06: Persistence 93%; Extinction 7%.
• 18 months, 2028-02-06: Persistence 88%; Extinction 12%.
• 24 months, 2028-08-06: Persistence 82%; Extinction 18%.

Persistence declines with time because capability, integration, and platform defaults can compound quickly. I nevertheless expect elite first-party and managed environments to improve much faster than the representative heterogeneous estate.

The three most important falsifiable assumptions controlling my 18-month probability are:

1. Capability-to-reliability: A refreshed, broad, private benchmark will not exceed 90% strict intended-target repair while also achieving at least 95% high/critical precision and no more than 1% severe verifier-passing regression.
2. Coverage-to-prevention: Fewer than 75% of mainstream high-impact repositories will have enforced proof-and-repair gates, or fewer than 80% of material first-party vulnerabilities will be fixed before production.
3. Patch-to-outcome: Representative data will not jointly show median full KEV remediation below seven days, less than 10% open at day 28, and at least an 80% reduction in conventional VM labor from a preregistered 2026 baseline.

The strongest current fact favoring Extinction is the reported 2,100-plus first-party patches in three weeks (EV-014). It directly supports the claim that ownership, context, and integration can turn discovery into repair far faster than the open-source campaign.

Cross-examination for the Extinction Advocate

1. What ledgered evidence converts first-party patch counts and platform availability into representative, enforced repository coverage, and what denominator supports that adoption forecast?

1. By what measurable mechanism does your 18-month model eliminate the material burden from old, unsupported, third-party, appliance, and customer-managed stock documented in EV-007, EV-027, and EV-028?

1. What joint 2028 thresholds for strict target repair, verifier-passing regression, deployed remediation, vulnerability-days, and human labor would make you admit that “AI helps enormously” has not made reactive VM marginal?

Probability update: 12 months—Persistence 93%, Extinction 7%; 18 months—Persistence 88%, Extinction 12%; 24 months—Persistence 82%, Extinction 18%.

CONTINUE

Direct answers

1. The ledger does not establish an enterprise-applicability fraction for the 177 KEV additions. EV-006 measures CISA catalog additions, not how many affected a representative mainstream enterprise or how much human work remained after vendor or managed-service action. EV-009 and EV-010 show substantial KEV remediation and exposure burden in separate selected partner datasets, but they cannot be joined record-for-record to EV-006, and their underlying data are private. My Round 1 presentation therefore used KEV flow too close to an enterprise-workload proxy. The defensible inference is narrower: known-exploited flow is continuing, and available operational samples show that some KEV exposure persists. The ledger cannot quantify the conversion rate between those facts.

1. No evidence supports making the volunteer-maintainer queue the governing rate for the entire estate. EV-014 directly cautions against that extrapolation: first-party users reportedly patched more than 2,100 findings in three weeks, while open-source disclosure and patch queues moved much more slowly. Owned commercial software and managed SaaS can resemble that favorable first-party case because the owner controls source, tests, merge authority, and deployment. I treat volunteer maintenance only as one material segment. Its relevance is that mainstream enterprises also consume dependencies whose review and release authority remains concentrated: in the Census III sample, 40% of examined leading non-npm projects depended on one or two developers for more than 80% of commits (EV-027). Critical legacy systems add another segment that ordinary patch synthesis may not resolve (EV-028). Persistence does not require those segments to govern the whole estate; it requires their residual burden, together with customer-managed and newly exploited stock, to remain material.

1. A 70% relative reduction would produce a major downward update, but it is not by itself an automatic concession. A relative reduction does not reveal whether the remaining 30% is an occasional exception or still a recurring queue requiring a dedicated function. I would concede practical obsolescence if the study were representative of the whole mainstream estate, sustained rather than a short post-adoption comparison, measured both vulnerability-days and all conventional VM labor with no displacement, and showed that the absolute residual was exception-only rather than a continuing operational queue.

My predeclared quantitative endpoint remains: at least an 80% whole-estate reduction in conventional triage, applicability, patch-decision, and coordination labor, alongside median full KEV remediation below seven days and less than 10% open at day 28. That is not literal zero. If a representative study met those criteria without labor displacement, I would concede. If it showed 70% reductions plus direct evidence that the remaining work no longer sustained an ongoing function, I would also concede rather than insist on the extra ten percentage points.

Observation versus forecast

Ledgered observation: Current operational burden is large in the available samples. Vulnerability exploitation was 31% of initial access in the DBIR corpus (EV-008). The partner data reported only 26% of KEV/organization combinations fully remediated and a 43-day median to full remediation (EV-009); 35% of detected instances remained open at day 28, with a 9% long tail (EV-010). Strict intended-target repair remains much lower than patch-only or alternate-bug closure: 22.2% for GPT-5.4 and 26.2% for uncapped Opus 4.6 in CyberGym-E2E (EV-012). Adoption evidence shows broad assistant use but substantial distrust and limited willingness to automate deployment (EV-023). No representative audited enterprise baseline measures enforced gates, post-release escape reduction, vulnerability-days, or total VM labor (EV-035).

Ledgered transformation evidence: The opposing mechanism is strong. AIxCC, CyberGym-E2E, and Glasswing show rapid capability progress (EV-011–EV-013). First-party repair can move much faster than volunteer coordination (EV-014). Integrated Autofix compresses supported alert-to-fix time (EV-018), and multiple major platforms are distributing find/verify/fix workflows (EV-017). I cannot convert absence of representative outcomes into evidence that this transformation will fail.

Forecast inference: My high persistence probability comes from the number of distinct handoffs that must change within 18 months: strict blind reliability, enforced repository coverage, safe deployment, dependency and legacy handling, and favorable attacker response. These links are correlated, so I am not multiplying independent probabilities. A platform-default verified control could improve several simultaneously. Conversely, failure at deployment or heterogeneous-estate coverage can preserve a material function even if model capability advances dramatically.

The cross-examination exposes two upward biases in my prior 88%: I lacked an applicability denominator for KEV additions, and the first-party evidence is stronger than a volunteer-queue extrapolation. I therefore reduce the central persistence estimate to 82%.

As a decision rule, my model can accommodate roughly two-thirds of today’s vulnerability-days and conventional VM labor disappearing while the remaining third still may be material; the classification would depend on its absolute recurring workload. At a representative 70% reduction, I would move close to or below even odds unless the residual clearly retained a dedicated function. At 80% or more with the exposure thresholds above and no displacement, I would concede.

Strongest point granted to Extinction

The strongest point is the ownership-and-integration contrast in EV-014, reinforced by platform distribution in EV-017: once source, CI, tests, authority, and deployment are unified, AI can turn a discovery queue into rapid repair. That mechanism could eliminate much of first-party and managed-service VM work rather than merely accelerate existing tickets.

Counterquestions

1. If a 70% relative reduction leaves a recurring exploit-driven queue that still requires dedicated applicability and deployment operations, what absolute criterion makes that residual “marginal”?

1. What ledgered evidence supports the share of the mainstream whole estate that will receive the favorable first-party or managed-service loop by 2028-02-06?

Probability update: 12 months—Persistence 90%, Extinction 10%; 18 months—Persistence 82%, Extinction 18%; 24 months—Persistence 70%, Extinction 30%.

CONTINUE

Direct answers

1. Yes. Jointly meeting all five Extinction thresholds would establish practical obsolescence under the locked definition: broad strict target repair with high precision; the severe-regression ceiling; rapid tested repair and deployment; at least 70% lower whole-estate exploitable vulnerability-days; and at least 70% lower conventional labor plus 60% lower queues without displacement. Taken together, those conditions measure capability, safety, deployment, exposure, and human work across the estate. I would not insist on my previously stated 80% labor threshold after that stronger joint package had been satisfied. A residual can exist while the conventional reactive function becomes marginal.

1. I can no longer defend 82% after an adversarial calibration audit. EV-035 does not support Extinction, but it widens uncertainty in both directions: we lack representative measurements of current enforced coverage and of AI’s effect on escape rates, vulnerability-days, and total labor. My 82% estimate over-weighted selected current-burden samples and under-weighted how a platform-level transition could improve several correlated handoffs together. I revise substantially below.

What directly measures burden

The ledger has three evidence groups, and they should not be blurred.

Direct operational measurements, but only in selected samples:

• EV-008 directly measures breach initial access in Verizon’s contributor corpus: exploitation was 31%. It is operationally relevant but not statistically representative.
• EV-009 directly measures remediation in a large private partner sample: 26% of KEV/organization observations were fully remediated and median full remediation was 43 days. It is selected, and the underlying records cannot be rerun publicly.
• EV-010 directly measures detected-instance survival in partner scanner data: 35% remained open at day 28 and 9% formed a long tail. Detection instances are not unique vulnerabilities or representative enterprises.
• EV-034 measures detected exploited-before-public-patch zero-days, but vendor visibility and disclosure determine the observed set.

These show that current material burden exists. They do not establish its population prevalence or forecast how fast integrated AI controls will reduce it.

Exploitation-relevant disclosure evidence, not enterprise workload:

• EV-006 measures KEV catalog additions, not applicability or human effort.
• EV-007 measures NVD-publication-to-KEV-addition lag. It establishes that older stock becomes newly urgent, not what fraction affects a mainstream enterprise.
• EV-013 and EV-014 measure a selected AI discovery/disclosure campaign. They expose both high precision and coordination queues, but neither supplies a representative estate denominator.
• EV-027 and EV-028 establish that maintainer concentration and hard legacy cases exist; they do not measure their share of a mainstream enterprise’s burden.

Disclosure volume only:

EV-001, EV-002, and EV-005 describe NVD or OSV publication. EV-003, EV-004, EV-029, and EV-030 show why registry, enrichment, CNA, and scoring changes prevent those series from answering the operational question directly.

Removing NVD and OSV

I remove raw NVD/OSV volume entirely from my decision. That lowers my central Persistence probability only two percentage points, from the already revised conceptual starting point of 82% to 80%, because my core case rests on exploitation, remediation, strict target closure, adoption, and heterogeneous-estate constraints—not publication volume.

The larger correction comes from recognizing that the operational evidence itself is selected. Applying that correction lowers my central estimate another 12 points, to 68% Persistence / 32% Extinction. This is the appropriate uncertainty penalty for EV-035; it is not an inference that transformation fails.

Conditioning on a large capability jump

Assume by 2028 that strict S4-like repair reaches 65%, high/critical precision reaches 90%, and major platforms make verified find-and-fix generally available. That is a major advance over current strict S4 results of 22.2–26.2% (EV-012) and is consistent with rapid progress in AIxCC, Glasswing, Firefox, and selected production systems (EV-011, EV-013, EV-015, EV-016).

Under that counterfactual, I reduce Persistence from 68% to 58%, with Extinction at 42%. Persistence remains only slightly more likely because three links are still unresolved:

1. Availability is not enforcement. The adoption survey shows broad AI use but distrust, debugging friction, and little appetite for deployment autonomy (EV-023). It is not a repository audit, so it should impose uncertainty rather than become a fixed adoption ceiling.
2. Repair is not safe whole-estate deployment. Current selected data show long remediation and exposure tails (EV-009, EV-010). First-party owners can move dramatically faster—more than 2,100 reported patches in three weeks—but the same Glasswing record shows external coordination queues (EV-014).
3. The estate extends beyond integrated first-party code. Old stock continues to become urgent (EV-007), maintainer authority is concentrated (EV-027), and some legacy remediation is inseparable from modernization (EV-028).

That 58% is deliberately close to even odds. If the capability jump also produced representative enforced coverage and the Extinction Advocate’s joint outcome thresholds, I would concede.

Overreach audit

My own too-aggressive inference was treating weekly KEV additions as if they strongly supported a recurring mainstream-enterprise labor queue. EV-006 establishes catalog flow; it lacks applicability and labor denominators.

Extinction’s remaining overreach is converting generally available platform capability into sufficient enforced whole-estate coverage and operational closure. EV-017 establishes distribution channels, not enforcement, while EV-035 confirms the decisive denominator is absent. Its Round 2 conditional coverage and deployment probabilities are forecasts, not measurements.

Strongest opposing point

The strongest Extinction point remains the first-party contrast: more than 2,100 reported first-party patches in three weeks (EV-014), combined with integrated platform distribution (EV-017). It demonstrates a credible mechanism by which multiple bottlenecks can collapse together rather than improve independently.

Probability update: 12 months—Persistence 86%, Extinction 14%; 18 months—Persistence 68%, Extinction 32%; 24 months—Persistence 52%, Extinction 48%.

CONTINUE