Which publishers revise their records?
1.4%[0.81–2.5%]
Of the 848 records microsoft published with CVE ID year 2023 that stated a fix, 12 later raised the stated fix version on the same release branch. The first revision appeared after a median of 55 days.
Ranked by the lower bound of the Wilson 95% interval on the share of records stating a fix whose fix later moved, among publishers with at least 100 such records and at least 5 raised; the bracket is that interval. One publisher clears both floors this year, so there is no order to compare it against.
Not checked: for some 2023 records the earliest copy anyone can read was written days after the record itself was published. A raised version inside that window is invisible, so 2023 reads low for a measurement reason rather than because its records were more accurate.
Filled and named: ranked. Hollow: too few raised to rank, drawn for the interval alone. Whisker: the 95% interval.
| Publisher, The CVE Numbering Authority that published the record, as the catalog names it. Links to every counted change in its records. | Stating a fix, Records this publisher put out with CVE ID year 2023 which stated a fix version that could be put in order. The denominator of the rate. | Raised, Of those, records whose stated fix later moved to a different version. | Rate [95%], Raised as a share of records stating a fix, with the Wilson 95% interval in brackets. | Median days to revision, For fix moves: median days from publication to the initial value’s first observed replacement, over this publisher's raised records. Same day is under one day. | Events, Distinct correcting commits behind this publisher's counted rows. One commit that re-issued fifty records is one event. | Shape: fix · range · bulk, What changed, in records: a stated fix moved, a last-affected version was raised, and how many of the fix moves sat in a bulk commit of fifty rows or more. The three are not added. | Edits: same day → over a year, Days until the initial value’s first observed replacement, binned same day, within a week, within a month, within a quarter, within a year, over a year. Bar height is the share of the publisher's edits in that bin. | Feed, An RSS feed of every counted change in records this publisher assigned. |
|---|---|---|---|---|---|---|---|---|
| microsoft#1 | 848 | 12 | 1.4% [0.81–2.5%] | 55 days | 6 | 12 fix moved·0 range extended·0 in bulk | RSS | |
| Too few to rank: fewer than 5 records raised. Listed for interval overlap alone. This is not a test of whether their rates differ. | ||||||||
| GitLab | 115 | 1 | 0.87% [0.15–4.8%] | 19 days | 1 | 1 fix moved·0 range extended·0 in bulk | RSS | |
| apple | 531 | 1 | 0.19% [0.033–1.1%] | under a day | 1 | 1 fix moved·0 range extended·0 in bulk | RSS | |
| Linux | 1,668 | 1 | 0.060% [0.011–0.34%] | 13 days | 1 | 1 fix moved·0 range extended·0 in bulk | RSS | |
The rate divides by the records that stated a fix version at all, never by everything a publisher put out: a publisher whose versions are rarely comparable would otherwise read low for that reason rather than for accuracy. Records, not rows, in every column: a record that raised the fix for four products is one record here and four rows in the change list.
Shape, in records: fix is records whose stated fix moved, range is records whose last-affected version was raised, and bulk is how many of the fix moves sat in one commit of fifty rows or more. The three are never added. Events are distinct correcting commits.
A high rate is not bad practice. A publisher that finds its first patch incomplete should raise the version; what this measures is that nobody downstream is told.
Data sources and quality
The organisation that publishes a CVE record is its CNA, a CVE Numbering Authority: a vendor, a research team or a national CERT that writes the record and can edit it afterwards. A rate here is the share of its records that stated a fix version whose fix later moved. It ranks one of the 15 kinds of change this site watches, and it is not a quality score.
We compare each record as it read on the day it was published against the same record today. The older copies come from the catalog's public git history, where a commit is one dated save; the first commit is the earliest copy anyone can read, and “backfilled” means a file was added to that history in a batch, later than the day the record itself went out. “Days”, for fix moves, measures from publication to the initial value’s first observed replacement. It does not date when a value became wrong.
These figures are concentrated. One publisher, microsoft, accounts for 12 of the 21 records raised with CVE ID year 2023. The 1 ranked publisher published 963 of the 31,404 records compared and hold 12 of the raised ones, so the year's pooled rate is an average over all of them, not a typical publisher.
Records this site refused as false positives, product lines renumbered rather than a fix raised, are counted in no figure on this page. They are listed, marked, under every change so the filter can be checked; that list counts rows, this page counts records, so the same filter reads as two different numbers on the two pages. 263 refused with CVE ID year 2023.
Not listed: a publisher with fewer than 100 records stating a fix version with CVE ID year 2023, or none whose fix moved, is absent from this page (3 such publishers had a raised record with CVE ID year 2023). Below that floor a single record swings the rate by a whole point. Absence here is not a clean record.
Not checked: a record published before 2023 cannot have its state at publication recovered and was never compared, so no publisher is credited or blamed for one. Left-censoring: where the first commit lands more than 7 days after the record's own datePublished, the catalog backfilled it, so the blob we call 'state at publication' already contains whatever was amended in between. Moves inside that window are invisible and are not estimated. This is part of why the earliest in-scope year reads low; the larger part is that the 2026 bulk re-edits by a few publishers fell on 2024-2025 records.
A change shown here is a change to a public record, evidenced by a commit anyone can read in the publisher's own history. It is not an assertion of wrongdoing, negligence or bad faith by any publisher or vendor, not evidence that any fix was incomplete, and not a statement about anyone's systems.
Shipped snapshot computed 2026-09-07 from catalog commit f5f9fc6fd7dc. Real findings, not live ones: records amended since are not reflected. A later fix version is evidence that the record changed, not evidence that the first fix was incomplete.