The KEV Field That Rewrites Your Backtest After You Score It
Two of the five signals feeding a vulnerability risk model cannot serve as targets at all, and the one everyone trains on updates silently, years after the prediction window closes.
This is a formulation bug, not a feature bug
The temptation is to fix a censored label with better features. It does not work, because the defect is in the problem statement. A model consuming KEV's ransomware-use field as a binary is sampling from a population where an unknown share of the negative class are future positives, then being evaluated against a label table that caught up after the prediction window. That is positive-unlabeled contamination and point-in-time leakage in the same pipeline, and they push error in the same direction: offline precision looks strong, production precision cannot match it, and nobody can explain the gap.
The two defensible reformulations are well established. Treat it as time-to-event with explicit right censoring, where a CVE not yet confirmed is censored rather than negative. Or treat it as PU learning with an estimated label frequency. Either way, every backtest joins against a point-in-time snapshot of the label table, not today's. If you buy a vendor exploitation score, the question worth asking is which of the two they do; the concrete finding here is that the underlying field changes without notification, so a vendor that re-scores history against current labels has the same defect you do.
Rank your label sources by whether you can train on them
| Signal | What it measures | Label latency | Known bias | Usable as target? |
|---|---|---|---|---|
| CVSS score | Theoretical severity rubric | None, assigned at disclosure | Not a probability; both exploited Windows privilege-escalation zero-days this cycle scored 7.8 | No, feature only |
| KEV exploited listing | Confirmed in-the-wild exploitation | Days to months | Left-truncated; absence is not evidence of no exploitation | Yes, positive-only |
| KEV ransomware-use field | Confirmed ransomware association | One day to 3.5+ years | Right-censored, silently updated | Only with censoring modelled |
| Vendor priority rating | Suggested patch timeline | Static rubric | Vendor-defined, predates AI-accelerated discovery | No |
| Internet-scan telemetry | Observed unpatched exposure | Days | No denominator, scan coverage bias | Covariate, not target |
A remediation prior worth stealing
Shadowserver counted roughly 11,000 unpatched WatchGuard Fireboxes in December 2025 and about 9,000 nine months later — near 18% remediation on a KEV-listed, CVSS 9.3, ransomware-exploited flaw. Plex still showed 36,000-plus exposed servers a week after its advisory. If your exposure or time-to-remediation model assumes exponential decay, it is badly optimistic; the empirical hazard for edge appliances looks closer to flat. No denominator is published for either count, so use them as relative trend only.
The regime break sitting in the same dataset
Microsoft's monthly CVE volume reached 974 in September against 622 in July, roughly 5x May and 10x February. That is a level shift, not a noisy month, and a rolling-window baseline will smear it into a gentle trend and stop alerting on anything real for a year. Declare a changepoint or reset the window.
The headline count also fails to reconcile across outlets: 974 per Dark Reading and The Register, 972 with 113 critical per CrowdStrike, 966 per BleepingComputer — and CrowdStrike's tidy 45% privilege-elevation / 26% RCE / 18% information-disclosure split rides on its own denominator. ZDI separately counts 2,760 Microsoft CVEs year to date, more than double the prior record with a quarter left. The popular explanation, that AI-assisted code analysis drove the surge, has no ablation separating it from CVE-assignment policy, bounty scaling, or third-party bundling. Ingest the machine-readable vendor feed and persist your denominators, or your severity-mix charts will drift for editorial reasons alone.
A censored label with silent updates is not a data-quality ticket. It means your backtest measured a future you had already been told about.
What to do
Re-specify any KEV-derived target as positive-unlabeled or time-to-event with explicit censoring, and re-run one existing backtest on point-in-time label snapshots this sprint.
Add a changepoint indicator, or reset baselines to a post-February window, for every monitor or SLO keyed on monthly CVE volume before the next release lands.
Replace CVSS as the prioritization target with KEV listing plus exploit prediction by the next model review, keeping CVSS as one feature among many.