Method

A CVE ID in the Reserved state that is referenced in one or more public sources while no CVE Record has been published. That is the CVE Program's own definition, quoted from RBP Policy v2.0.0 and still live in the cve.org glossary.

RBP is a state, not a verdict. The policy defines the state on its own terms, then separately conditions its notification steps on an RBP “in violation of Program Rules 4.5.1.4 or 4.5.1.6 exceeding the 72 hours”, and assigns that determination to Roots, TL-Roots and the Secretariat. The headline count on this site is the state, which makes it the Program's own definition, measured from outside. Violation language is confined to the rule column, always marked candidate, and never aggregated into the headline.

State comes from the CVE Services reservation endpoint, which returns it directly:

GET https://cveawg.mitre.org/api/cve-id/CVE-2026-2574
{"cve_id":"CVE-2026-2574","cve_year":"2026",
 "state":"RESERVED","owning_cna":"[REDACTED]"}

This matters because the more commonly used /api/cve/ endpoint returns 404 for a reserved ID, making it indistinguishable from an ID that was never allocated. Using the reservation endpoint instead means a row here is a confirmed reservation and not an inference about absence. IDs that were never allocated return CVE_ID_NOT_FOUND and are excluded. That screens IDs that do not exist. It does not screen a mistyped ID that happens to land on a real reserved neighbour, which passes every check this site makes, so some small number of rows are likely transcription errors in the citing advisory rather than genuine RBPs.

The bulk CVE List contains zero reserved records, and the cvelistV5 git tree carries none either, so no tool sourcing only from those can see any of this.

How often this site has actually published, which feeds the last run read, what each returned and which standing caps fire on every run are all on the status page. They are kept apart from this page deliberately: those figures describe one run and change four times a day, while everything here is a claim about the method and is true of every run.

Rows are reportable once publicly referenced for at least 7 days, which is 2.3x the 72-hour window. That multiple is derived from the buffer in force, not asserted: the buffer is configurable and the sentence was previously true only at seven days or more.

What the buffer does is make latency an implausible explanation, which is a weaker and more defensible claim.

Days public is a floor, not a deadline measure. It counts from the earliest public advisory this site can see. The rule's clock starts when the CNA became aware of the disclosure, and that is not observable from outside. So the column reads days public and never days overdue.

3 reserved IDs are excluded entirely because their feeds publish no usable date. They cannot be aged at any threshold, which is a permanent limit on coverage rather than a temporary gap.

4.5.1.6 SHOULD is the default: publish within 72 hours of becoming aware that a third party disclosed. This is the ordinary case, where a distribution or ecosystem advisory appears first.

4.5.1.4 MUST applies where the CNA itself disclosed. This site claims it only when the owning CNA's own advisory feed carried the advisory:

• redhat: redhat
• microsoft: msrc
• mozilla: mozilla

Aggregators are deliberately excluded even where they carry a CNA's data. OSV re-publishes GHSA, so an OSV row is not evidence that GitHub disclosed anything. Counting it would upgrade a SHOULD to a MUST on the strength of a mirror.

CVE IDs are issued to CNAs in runs, so an ID whose published neighbours all share one assigner is very likely assigned to that CNA too. A name is published only when the 3 published CVE IDs on each side all agree. Anything less abstains, and the row says unattributed.

Coverage and precision are different things. The leave-one-out figure is measured over published IDs, which are spread evenly through the ID space. A live RBP set is not: these cluster in regions where no single CNA owns the neighbourhood, so the share of rows that can be named is lower than the validation coverage suggests. Both are shown, and they are never presented as the same number.

A second signal, a product-to-CNA map built from the corpus, is used only to corroborate. Tested on its own it reached 85% precision, below this project's floor, so it can promote a named row to Corroborated but never create a name.

No misses recorded yet. They will be listed here when they occur.

alas, ubuntu, ubuntu-osv, debian, ghsa, ghsa-repos, redhat, alpine, osv, mozilla, arch, csaf, msrc, samsung, jvn, zdi, certcc

What each of these returned on the most recent run, and whether any of them failed, stopped early or shrank, is on the status page. Counts here are a floor: only configured feeds are read.

How much of the CNA landscape this site can see. Three different answers, because "covered" is doing three different jobs. They are listed together because quoting the largest one alone would overstate what the feeds actually reach.

The denominator is the CVE Program's own list of 539 certified CNAs, pinned in this repository and refreshed deliberately. It used to be the 459 distinct assigners seen publishing in a rolling 4-year window, which moves as CNAs publish, shrinks as the window rolls and steps overnight on 1 January: a percentage trended over a base like that is weather, not progress. Measuring against the roster lowers every figure below, because a CNA that has published nothing is still one whose advisories this site cannot read. A further 25 assigner name(s) in the corpus match no current roster entry, usually a rename (3DS, @huntrdev, Baicells), so coverage is understated by up to that many.

Launch gate: 98.0% of 80.0% required, measured on top-50-by-volume at the 3-sighting floor. Cleared with 9 CNA(s) to spare.

The gate was a share of the whole 539-CNA roster until 2026-08-23, and it was unreachable: only 371 roster CNAs have published three CVEs in the window at all, so that figure cannot exceed 68.8% however many feeds are added, and the threshold had never been re-derived after the metric changed underneath it. The roster share is still measured and still published above (49.7%). It no longer gates anything.

Feeds surfaced 51.57% of published CVEs in the window. An RBP held by a CNA outside the sighted set is invisible here, which is the single largest reason this site understates the problem.

How this site identifies itself when it fetches. Every request carries rbp-cves/1.0 (+https://rbptracker.org), which names the client and gives any publisher a route to complain or to block it. No request sent by this pipeline claims to be a web browser, and none claims to be another tool. If a publisher ever refuses a client that identifies itself honestly, the advisories it holds go unread and are counted as unread.

Two publishers needed a different knock, and neither needed a disguise. Cisco's edge refuses a client whose identifier carries no contact route, and refuses a browser string just as firmly; it accepts the identifier above. CISA's edge serves its metadata to an ordinary desktop and refuses the cloud machines this site is built on, so its advisories are read instead from the feeds CISA's own metadata points at, published in CISA's own GitHub organisation. When that second route is used, the status page says so on the CSAF row for that run, because a route that quietly changed is a route nobody can check.

Counts are a lower bound. Only configured feeds are read, so an RBP in an ecosystem not listed above is invisible here. That is the main reason this site understates the problem.

Three different accuracy figures exist and they rest on very different samples. A single number would hide that, and the composition is the part that makes any of them readable. So all three are here with theirs.

Contiguous-run length is recorded on every prediction from now on, so a future build can report accuracy by block width. Without it there is no way to separate "the method is accurate" from "the method is accurate on wide blocks and has never been tested on narrow ones", and it cannot be backfilled: it is a property of the corpus at prediction time and the corpus moves.

Because of block width and feed coverage, not behaviour. A CNA is nameable here when its published CVE IDs form runs wide enough for the 3-either-side test to resolve and this site reads its advisories. A CNA that assigns from large contiguous blocks and publishes through a feed we ingest will dominate this list. A CNA that assigns sparsely, or publishes only through a channel we do not read, is invisible here no matter how long it sits on a record.

So is the largest holder the worst offender? No, and this site cannot support that reading. It is the CNA whose ID blocks are widest and whose advisories this site reads best, which makes it the most visible holder rather than the largest one. Any CNA outside the 268 CNAs these feeds reach could hold more and never appear here at all.