The EOL Risk Score: Why CISOs and DevOps Teams Are Measuring Software Risk Wrong

The Metric Everyone Is Using Is Wrong

Ask any security engineer how they measure software risk and they will tell you the same thing: CVE count. How many known vulnerabilities does this package have? What is the CVSS score? Is it in the NVD? Is there a patch?

This is a reasonable framework for software that is actively maintained. When a vendor is issuing patches, the CVE count reflects real, current exposure. But the moment software reaches end of life, the CVE framework breaks down completely — and most teams never notice.

Here is what happens when software goes EOL: the vendor stops issuing patches. Full stop. CVEs that are discovered after the EOL date are publicly disclosed on the NVD with no patch available. Exploit code appears on GitHub within days. The attack surface does not shrink — it grows, permanently, with every passing month.

Your vulnerability scanner, by design, looks for known CVEs with available patches. It has nothing to say about the accumulating pile of unpatched vulnerabilities in your EOL dependencies. The CVE count stays at zero. The scanner stays green. The risk keeps climbing.

This is the CVE blind spot. And it is why we built the EOL Risk Score.

What the EOL Risk Score Measures

The EOL Risk Score is a 0–100 score assigned to every software product and version on endoflife.ai. It quantifies lifecycle exposure risk — not current CVE count, but the structural risk created by running software past its supported lifecycle.

Four factors drive the score:

Scores map to four risk bands:

Critical 76–100   High 51–75   Medium 26–50   Low 0–25

What the Scores Actually Look Like

Here are real scores for software you are almost certainly running somewhere in your stack right now.

Node.js 18 hit end of life in April 2025. It is one of the most widely deployed JavaScript runtimes in the world, present in CISA's KEV catalog ecosystem, and has no free extended support path. A security team running Node.js 18 and seeing zero CVE alerts from their scanner is not safe — they are flying blind.

PHP 7.4 is over 900 days past end of life. It powers a significant portion of the web — WordPress installations, legacy Laravel apps, internal tools that nobody has touched in three years. The attack surface is enormous and the unpatched CVE accumulation has been compounding for almost three years.

Spring Framework 5.3 has been EOL since August 2024. It is in the CISA KEV catalog — Spring4Shell was one of the most actively exploited vulnerabilities of the last five years. Running 5.3 today means running software with a known exploitation history and no patch path.

Python 3.8 is a common fixture in data pipelines, ML infrastructure, and internal tooling. It went EOL in October 2024 and is deeply embedded in environments that are rarely audited for lifecycle status. It does not show up on CVE dashboards. It shows up here.

Why This Changes How You Think About Risk

The CVE framework answers one question: is there a known vulnerability with a patch available? That is a useful question. But it is not the only question that matters.

The EOL Risk Score answers a different question: how exposed is this software by virtue of being outside its supported lifecycle?

These are complementary signals, not competing ones. A CISO running both frameworks gets a complete picture:

CVE scanner: no critical vulnerabilities detected in Node.js 18.
EOL Risk Score: 85/100 Critical — 380 days past end of life, CISA KEV ecosystem, no extended support available.

The first line creates false confidence. The second line is the actual risk posture.

For DevOps teams, the score functions as a migration priority signal. When everything feels urgent, a score of 90/100 Critical versus 50/100 Medium gives you a defensible, data-driven prioritization framework. You are not arguing about feelings — you are pointing at a number.

For CISOs presenting to boards, the score translates technical lifecycle debt into executive language. A dashboard showing that 14 production dependencies score above 75 is a conversation starter. A spreadsheet of package names is not.

How to Use the EOL Risk Score

Every product and version page on endoflife.ai now includes the EOL Risk Score. You can look up any software in the product index, run your full dependency file through the stack scanner, or check specific versions directly.

Each score also has a dedicated shareable card URL — drop endoflife.ai/score/nodejs/18 into a Slack message, a security report, or a vendor assessment and the score renders immediately. No login. No friction.

The full methodology is public. The scoring logic is documented. This is not a black box — it is a transparent, reproducible framework designed to be audited, challenged, and improved.

The Bottom Line

CVE count is a lagging indicator. It tells you what vulnerabilities have been discovered and patched. It has nothing to say about the risk that accumulates silently in software that nobody is patching anymore.

The EOL Risk Score is the leading indicator. It quantifies the structural exposure created by lifecycle status before the CVEs pile up — and it surfaces the risk that scanners, SBOMs, and asset inventories consistently miss.

Your stack has EOL software in it. The question is not whether your scanner is finding it. The question is whether you have a framework to understand how exposed you actually are.