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.
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 readsThe 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.