73% of the Software Versions We Track Are Already End of Life

Of the 8,307 software and hardware versions in end-of-life.org, 73% are past their end-of-life date. Another 142 branches reach EOL within the next 90 days. The honest reading of that first number is: it is not very interesting. Software accumulates dead versions the way a filesystem accumulates old files. Python 2.7 being EOL is not news, and nobody's risk register needs a line item for it. The number that matters is much smaller, and getting to it means throwing away most of the 73%. Key Takeaways - "73% end of life" is mostly historical sediment - versions nobody runs. The figure is a denominator problem, not a finding. - What matters is the intersection of dead and still deployed, which no public dataset knows for you. Only your inventory does. - Among branches that are both dead and plausibly in production, rank by critical CVE count and by accumulation rate, not by total CVEs. - The 90-day window is the more useful number to put on a roadmap: it is the only part of the dataset that is actionable before it becomes urgent. Most of that 73% is sediment Every product carries its whole history. MySQL has 18 tracked branches, Go has 27, PHP has 23, PostgreSQL has 29. The overwhelming majority of those are ancient and uninteresting, and they will stay in the denominator forever, pushing the percentage up every year regardless of what anyone does. So the number does not describe risk. It describes how long the industry has been shipping software. The full directory covers 462 products, and browsing it makes the shape obvious: for any given product, a couple of branches are maintained and a long tail behind them is not. That tail is normal. The number that isn't sediment The intersection you care about is dead and still running in your environment. That second half is the part no external dataset can answer. A lifecycle database knows when Oracle stopped patching MySQL 5.7. It has no idea whether you have four of them in a VPC somewhere. Every EOL dashboard that shows you a big scary percentage without reading your inventory is showing you the sediment. Which means the useful workflow runs in the opposite direction from how these tools are usually pitched: - Enumerate what you actually run - lockfiles, container images, AMIs, whatever is authoritative in your environment. - Look each one up against lifecycle data. - Rank only the matches. Step 3 is where most of the value is, and where most teams get the ordering wrong. Ranking: the trap is sorting by CVE count The obvious sort is "how many vulnerabilities has this version missed since it went EOL." It is the wrong primary key, and the current data shows why cleanly. MySQL 5.7 sits at the top of that list with 127 missed CVEs. Zero of them are rated critical. Go 1.15 sits just below it with 122 missed CVEs, and twelve of those are critical. Sort descending by volume and you fund the wrong upgrade first. I went through the full ranking and the arithmetic behind it in Your EOL Risk List Is Probably Sorted Wrong; the short version is below. There is a second distortion in the same column: CVE count rewards age. Normalise by time and the ranking inverts. | Version | Days EOL | CVEs missed | Critical | CVEs/year | |---|---|---|---|---| | MySQL 5.7 | ~1,060 | 127 | 0 | ~44 | | MySQL 8.1 | 1,020 | 103 | 0 | ~37 | | Go 1.17 | 1,469 | 106 | 10 | ~26 | | Go 1.16 | 1,609 | 111 | 10 | ~25 | | Go 1.15 | 1,820 | 122 | 12 | ~24 | Go 1.15 had nearly twice as long as MySQL 5.7 to accumulate a slightly smaller number. The Go branches cluster at 24-26 missed CVEs per year, the MySQL branches at 37-44 - the same measurement, from the same source, separating the two ecosystems by roughly 50%. Counts published by the NVD; lifecycle dates from vendor policy documents such as Oracle's Lifetime Support Policy and Go's release policy. That rate is the number to bring to a planning conversation, because it answers the question that actually gets asked: what does it cost us to defer this another quarter? Total CVE count answers a question nobody asked, which is how long the thing has been dead. The 90-day window is the part you can act on 142 branches reach end of life within 90 days. Unlike the 73%, this number is small, forward-looking, and maps directly onto a planning cycle. Everything in it is by definition something a vendor is still supporting today, which means the upgrade path exists, is documented, and has not yet acquired the compatibility debt that accumulates after a branch goes cold. Upgrades scheduled before the EOL date are maintenance. The same upgrades six months later are incidents. The window is the cheapest part of the dataset to act on and the easiest to ignore, because nothing is broken yet. What I would put on the roadmap | When | What | Sort by | Why | |---|---|---|---| | Now | Dead and deployed | Critical CVE count | Severity is the only column that maps to blast radius | | This quarter | Dead and deployed, high accrual rate | CVEs/year | Where the next critical shows up, before it does | | Next two quarters | The 90-day list | EOL date | Cheapest window - it is maintenance now, remediation later | | Never | The rest of the 73% | - | Sediment. Treating it as a backlog is how a risk register becomes something nobody reads | The only hard part is the first column of row one, and it does not come from any lifecycle database. It comes from your inventory. Two caveats worth stating plainly Vulnerability analysis currently covers 13 products - the runtimes, databases and app servers where post-EOL exposure is easiest to reason about. The other 449 products in the directory carry lifecycle dates only. If a field comes back empty for those, it means not analysed, not no vulnerabilities, and any dashboard that renders it as zero is lying to you. And CVSS severity is a scoring model, not a measure of exploitability in your environment. "Zero criticals" does not mean MySQL 5.7 is fine - 127 unpatched vulnerabilities is a real number. It means that between two upgrades competing for the same window, severity is a better tiebreaker than volume. Lifecycle dates are read from vendor policy documents and release notes; vulnerability data comes from the NVD API. The per-product source list is published on data sources, so every figure here is reproducible. Not endorsed or certified by the NVD, and not affiliated with any vendor - about · contact. Top comments (0)