Methodology
Where the data comes from
Three separate pipelines feed this site, and they don't have the same reliability. It's worth knowing which one produced the number you're looking at.
1. Vendor release data, read directly
For 15 products we parse the vendor's own machine-readable release data every day. No intermediary. These pages carry a footer naming the exact source.
Each collector fails loudly rather than guessing. If a vendor redesigns a page and the parser can't find what it expects, the build stops instead of publishing a plausible-looking wrong date.
2. Vendor policy pages, read by machine
Plenty of vendors publish support dates on a policy page but never as structured data. For those, an extraction pipeline reads the vendor's own page and pulls the dates out. It only accepts a date the page states outright, and it must return the exact sentence it found it in; that sentence is checked against the page text before anything is kept. Anything it cannot quote, it drops. Extracted dates are reviewed before they go live.
Openly licensed public datasets, mirrored into our own repository and compiled locally each day, fill the remaining gaps. Their license files ship with the mirror.
3. Vulnerability data
CVE counts come from the National Vulnerability Database, matched by CPE. This layer exists for 13 products only: the ones where "fixed in the new branch, never backported to the old one" is actually true. Every CPE was tested against NVD before being added; a wrong one produces an empty or, worse, someone else's CVE list.
This product uses data from the NVD API but is not endorsed or certified by the NVD.
What we won't do
- Invent precision. A vendor announcing "April 2028" gets stored and shown as April 2028. It never becomes 2028-04-30, and it never feeds a day counter.
- Derive dates from policy text. "Supported 18 months after release" is a rule, not a date. We don't do the arithmetic and present the result as if the vendor published it.
- Mix sources within a product. When we collect a product ourselves, our data replaces the whole branch list. Field-level merging produces a dataset nobody can explain the provenance of.
- Ship a downgrade. A self-built collector only goes live once it's at least as complete as what it replaces. Several are written and passing but still held back because they would drop a field the existing data has.
Refresh schedule
Everything rebuilds daily and deploys automatically. Last run: 2026-08-12. Current coverage: 462 products, 8,311 branches, of which 73% are past end of life.