Pipeline status
Whether the most recent run was complete, what it read, and how often this site has actually published. Every count on the rest of the site comes from the run described here.
The last run
This run is incomplete. 1 feed(s) stopped early, outside their configured limits. Every count on this site is a lower floor than usual and is not comparable to the previous run.
A run is marked incomplete when a feed failed outright, stopped for a reason that is not a configured cap, returned far fewer IDs than last time, or when the CVE Services reservation endpoint dropped rows. A configured page cap is not a degradation: it fires every run by design and is listed under standing limitations below.
| Snapshot | 2026-09-15 |
|---|---|
| Built | 2026-09-15 17:10 UTC (0.0h ago) |
| Code | 8a29a842ab74 |
| Rows published | 2,182 |
Does this site actually run every six hours?
26 of 28 scheduled runs published in the last 7 days (92.9%), most recently 2026-09-15T11:57:43+00:00.
This site also publishes on every merge to its main branch. Counting those, it published 35 times in the same 7 days, and the longest it went without publishing anything was 9.1 hours. A merge-triggered publish keeps the site fresh but is not evidence that the schedule fired, so it is not counted in the figure above.
Of the 28 ticks expected in that window, 26 published, 0 ran and did not publish, and 2 left no record at all. A tick that leaves no record never started. GitHub delays and drops scheduled workflows under load: on 2026-09-02 the four runs of the day began at 04:35, 11:19, 16:35 and 21:04 against a cron that asks for 00:17, 06:17, 12:17 and 18:17, and six of the 28 expected ticks never fired at all. That is worth seeing and it is not this pipeline failing, which is why the two are no longer added together.
The last figure is a residual rather than a measurement: it is what is left of the expectation after the runs that left a record. Ticks that ran and failed have only been recorded since 2026-09-02, so for the first week after that date this number still carries some of them.
Counted from a ledger appended by the step that actually publishes, so a run that built and failed to deploy is not counted as delivered. This exists because the six-hourly claim had no evidence behind it and was false at least twice: two scheduled ticks on 2026-08-21 produced nothing, with no pushes in the window, and nothing on the site could have told you. Until 2026-09-01 the figure above divided every publish by the scheduled ticks alone and read 164.3%, which could not have told you either.
What moved since the previous run
| Bucket | Rows |
|---|---|
| New | 53 |
| Published, verified in the CVE List | 39 |
| Rejected under rule 4.5.3.5 | 0 |
| No longer listed, cause unverified | 55 |
| Still open | 2,129 |
Only the first of those is good news. A row is counted as published only where the CVE List confirms a published record, taken from the resolution ledger rather than from the difference between two lists.
Rejected is not resolved. Rule 4.5.3.5 requires CNAs to reject unused or unpublished IDs, so rejection is lawful and is the likely end state for the oldest rows here. For anyone consuming the CVE List it is worse than an open RBP: the ID stays cited in advisories and no record is ever coming.
No longer listed means we do not know. A row leaves this list for reasons that have nothing to do with a CNA: a transient API error, a feed that failed or was truncated, a change to the feed set, a raised buffer, or a revised advisory date. None of those are a publication and none are counted as one.
CVE-2026-41573, CVE-2026-44202, CVE-2026-44203, CVE-2026-44300, CVE-2026-44778, CVE-2026-44793, CVE-2026-45048, CVE-2026-45051, CVE-2026-45052, CVE-2026-45794, CVE-2026-46488, CVE-2026-46498, CVE-2026-46619, CVE-2026-46623, CVE-2026-47424, CVE-2026-47426, CVE-2026-48717, CVE-2026-52819, CVE-2026-52820, CVE-2026-52821, CVE-2026-52822, CVE-2026-52823, CVE-2026-52824, CVE-2026-52825, CVE-2026-52826, CVE-2026-52827, CVE-2026-52828, CVE-2026-53658, CVE-2026-53660, CVE-2026-53710, CVE-2026-53941, CVE-2026-54503, CVE-2026-54561, CVE-2026-55149, CVE-2026-55690, CVE-2026-55691, CVE-2026-55692, CVE-2026-55863, CVE-2026-57112, CVE-2026-57133, CVE-2026-57134, CVE-2026-57135, CVE-2026-57136, CVE-2026-57137, CVE-2026-57138, CVE-2026-57139, CVE-2026-57140, CVE-2026-57141, CVE-2026-57147, CVE-2026-57148
Showing 50 of 55. The full list is in rbp.json by difference against the previous snapshot; it is deliberately not rendered, because a wall of identifiers reads as a finding and this bucket is explicitly not one.
Feeds read on this run
Every configured feed and what it returned. A feed that fails is reported here rather than simply yielding fewer rows, because counts are a floor and a silent shrink would read as improvement.
IDs read is how many CVE IDs the feed returned. Rows is how many of the IDs listed on this site that feed referenced, and Only source is how many of those no other feed referenced. The three are very different numbers, and a feed can return tens of thousands of IDs while accounting for none of the list.
A feed that reads from many third-party providers lists each provider beneath it. Capped on any of those rows means this site read only the newest advisories that provider publishes and stopped, which is a limit this site sets rather than anything the provider did. The note column says how many of how many. Those providers hold more than is counted here.
| Feed | State | IDs read | Rows | Only source | Note |
|---|---|---|---|---|---|
| alas | OK | 20,184 | 120 | 1 | 20184 ids |
| alpine | OK | 4,134 | 112 | 0 | 4134 ids |
| arch | OK | 95 | 0 | 0 | 95 ids |
| certcc | OK | 300 | 12 | 12 | 300 ids |
| csaf | OK | 66,635 | 695 | 291 | 18 providers; 66635 ids; 1 read via pinned feeds; 1 no advisories in scope; see the provider rows below |
| csaf:advisories.ncsc.nl | OK | 13,769 | 13769 ids in scope; caught up across all 1,060 advisories this provider lists | ||
| csaf:advisories.stackable.tech | OK | 15 | 15 ids in scope; caught up across all 24 advisories this provider lists | ||
| csaf:cert-portal.siemens.com | OK | 2,833 | 2833 ids in scope; caught up across all 592 advisories this provider lists | ||
| csaf:csaf.data.security.nozominetworks.com | OK | 40 | 40 ids in scope; caught up across all 122 advisories this provider lists | ||
| csaf:intevation.de | OK | 6 | 6 ids in scope; caught up across all 6 advisories this provider lists | ||
| csaf:psirt.abb.com | OK | 148 | 148 ids in scope; caught up across all 67 advisories this provider lists | ||
| csaf:psirt.kunbus.com | OK | 15 | 15 ids in scope; caught up across all 19 advisories this provider lists | ||
| csaf:security.access.redhat.com | OK | 27,063 | 27063 ids in scope; caught up across all 46,145 advisories this provider lists | ||
| csaf:wid.cert-bund.de | OK | 54,949 | 54949 ids in scope; caught up across all 26,690 advisories this provider lists | ||
| csaf:www.cisa.gov | OK | 5,077 | 5077 ids in scope; caught up across all 2,597 advisories this provider lists via pinned feeds, its canonical metadata refused us | ||
| csaf:www.cisco.com | OK | 773 | 773 ids in scope; caught up across all 741 advisories this provider lists | ||
| csaf:www.huawei.com | OK | 0 | 0 ids in scope; caught up across all 0 advisories this provider lists | ||
| csaf:www.innomic.com | OK | 0 | 0 ids in scope; caught up across all 1 advisories this provider lists | ||
| csaf:www.open-xchange.com | OK | 118 | 118 ids in scope; caught up across all 22 advisories this provider lists | ||
| csaf:www.se.com | OK | 210 | 210 ids in scope; caught up across all 147 advisories this provider lists | ||
| csaf:www.sick.com | OK | 167 | 167 ids in scope; caught up across all 51 advisories this provider lists | ||
| csaf:www.suse.com | OK | 23,888 | 23888 ids in scope; caught up across all 93,627 advisories this provider lists | ||
| csaf:www.trendmicro.com | OK | 27 | 27 ids in scope; caught up across all 8 advisories this provider lists | ||
| debian | OK | 29,059 | 281 | 1 | 29059 ids |
| ghsa | OK | 17,341 | 146 | 0 | 17341 ids |
| ghsa-repos | OK | 12,957 | 1,261 | 1,027 | 12957 ids |
| jvn | OK | 1,973 | 5 | 3 | 1973 ids |
| mozilla | OK | 1,115 | 0 | 0 | 1115 ids |
| msrc | OK | 18,883 | 3 | 0 | 18883 ids |
| osv | OK | 20,985 | 325 | 112 | 20985 ids |
| osv:Android | OK | 2,140 | 2138 new of 2140 in-scope ids from 9MB | ||
| osv:crates.io | OK | 588 | 545 new of 588 in-scope ids from 3MB | ||
| osv:GitHub Actions | OK | 35 | 31 new of 35 in-scope ids from 0MB | ||
| osv:Go | OK | 3,419 | 3398 new of 3419 in-scope ids from 12MB | ||
| osv:Hackage | OK | 10 | 8 new of 10 in-scope ids from 0MB | ||
| osv:Hex | OK | 240 | 238 new of 240 in-scope ids from 1MB | ||
| osv:Maven | OK | 2,904 | 2837 new of 2904 in-scope ids from 10MB | ||
| osv:npm | OK | 3,846 | 3811 new of 3846 in-scope ids from 215MB | ||
| osv:NuGet | OK | 554 | 521 new of 554 in-scope ids from 2MB | ||
| osv:opam | OK | 16 | 16 new of 16 in-scope ids from 0MB | ||
| osv:Packagist | OK | 3,211 | 3176 new of 3211 in-scope ids from 11MB | ||
| osv:PyPI | OK | 3,890 | 3890 new of 3890 in-scope ids from 34MB | ||
| osv:RubyGems | OK | 381 | 352 new of 381 in-scope ids from 4MB | ||
| osv:SwiftURL | OK | 33 | 24 new of 33 in-scope ids from 0MB | ||
| redhat | OK | 26,314 | 98 | 0 | 26314 ids |
| samsung | OK | 541 | 36 | 15 | 541 ids |
| ubuntu | Capped | 3,993 | 134 | 0 | hit the 200-page cap at 4,000 records of 78,533 (5.1%); read back to 2026-08-12, a 34-day window; the configured window opens 2023-01-01, so most of it was not read |
| ubuntu:dates | OK | 1 | dated 1 of 4 undated row(s) by name | ||
| ubuntu-osv | Truncated | 26,267 | 254 | 2 | stream stopped after 26267 ids: decompressed 8,000,267,617 bytes, past the 8,000,000,000 ceiling; refusing to read a partial archive |
| zdi | OK | 4,368 | 37 | 23 | 4368 ids |
These feeds publish no dates at all, so their freshness cannot be checked by any threshold. That is not the same as checked and fine: alpine: returns no dated rows; arch: returns no dated rows; debian: returns no dated rows
Standing limitations
These fire on every run, by design. They are not a fault and not a bad day; they are the permanent shape of what the feeds can see, and they are listed apart from the degraded state above because a warning that is always on is not a warning. Recording them as truncation made every single run read as incomplete.
- ubuntu: hit the 200-page cap at 4,000 records of 78,533 (5.1%); read back to 2026-08-12, a 34-day window; the configured window opens 2023-01-01, so most of it was not read
The consequence worth stating plainly: a paginated advisory API read to a fixed cap is observed over a much shorter window than a distribution tracker read in full, so counts from the two are not directly comparable, and a CNA whose advisories arrive mainly through a capped feed will be under-represented here relative to one carried by a tracker.
How the count itself is built, what it excludes and how far the feeds reach is on the method page. The machine-readable version of everything here is in rbp.json, under degraded, degraded_reasons and feeds.