How businesses can manage software end of life
Traditionally, Halloween, or All Hallows’ Eve, was a time to remember the dead. And as the nights grow longer and the end of October approaches, there are plenty of reminders of the festival, from shop window displays to pumpkin-flavoured coffees.
Should we, though, also spare a moment to reflect on software that has reached the end of its life?
Both enterprise software and personal applications have a lifecycle, set by the vendor’s support and maintenance. Once an application or operating system goes out of support, it will continue to run. But there will be no further feature updates and vitally, often no security patches. And organisations running end of life packages might no longer have access to the vendor’s support.
Some software’s end of life, or end of support, dates are trailed a long way in advance. Microsoft’s end of life date for Windows 10, for example, received plenty of advanced publicity.
Microsoft did make some changes to its support arrangements for Windows, including the paid for Extended Security Updates programme. But as of mid October Windows 10 is now, officially at least, no more.
Software end of life: preparing for the end
Commercial software vendors do usually publish their plans to end support in advance, although the timescales do vary. Operating system support, whether it is Windows, Mac OS, Android or iOS are also known in advance, with a guaranteed minimum support period for both updates and security patches.
Other applications, though, are more likely to fade away. Not all vendors actively publicise their products’ end of life dates or arrangements. Some smaller applications or even components might simply no longer receive developer attention.
Open source components can be a mixed bag: while some authors give their a specific end of life date, others might also simply stop working on or maintaining their code.
In both cases, this leaves packages or components vulnerable to any flaws or undetected vulnerabilities, and can impact any downstream applications that rely on the code to function.
When software end of life is unexpected, it can cause serious disruption to business processes. In the very worst-case scenarios, enterprises will only know there is a problem when a key application no longer functions, or if a malicious actor exploits a vulnerability.
The problem for CIOs and CISOs is keeping track of the end of life dates for applications across their entire stack, and understanding and mapping dependencies between applications. This applies equally to in-house applications, off the shelf software and open source.
“End of life software is not necessarily bad,” says Matt Middleton-Leal, general manager for EMEA at Qualys. “It’s just not updated any more, and that can lead to vulnerabilities. According to our research, nearly half of the issues on the CISA Known Exploited Vulnerabilities (KEV) list are found in outdated and unsupported software.”
As CISA points out, attackers are most likely to exploit older vulnerabilities, and to target unpatched systems. Risks come from old, and known vulnerabilities, which IT teams should have patched.
But in addition, when software is no longer being maintained, developers will not act to fix any new flaws. This compounds the problem of technical debt, where businesses face the growing costs of maintaining older software.
Further research, from end of life software specialists HeroDev, suggests that end of life or end of service systems are four times as likely to be targeted as current, maintained applications. The same research found that 20% of critical enterprise applications run end of life code with high-severity vulnerabilities.
Software end of life: track and trace
Part of the problem for CIOs is knowing exactly which applications are used across the enterprise, where they’re being used, and which are moving to end of life or end of support. In addition, in-house or customized applications often draw on third-party code, often open source.
Then there are the connections between on premises applications, code deployed in the cloud, and software as a service (SaaS).
Keeping track of all these elements is no trivial task but there are some projects to bring this data together in a more digestible format. The very useful, open source site endoflife.date service pulls together end of life and end dates for, currently, 423 products, across operating systems, infrastructure and applications.
Software bills of materials (SBOMs) can also go a long way to help. But as the UK’s National Cyber Security Centre (NCSC) points out, SBOMs are still maturing as a tool. And although IT teams might insist on SBOMs for new projects, cataloguing old and legacy systems will be time consuming and expensive.
And there is the further challenge of what CIOs should do with unsupported software, once they have found it.
In some cases, development teams might be able to keep applications running, if they can access the code. In others, such as Microsoft Windows 10, or popular packages such as the MySQL database, it is possible to pay for first-party or third party extended maintenance. MySQL 8.0 reaches its end of life in April 2026, for example.
But, as Peter Zaitsev, founder at Percona, a software support company focusing on open source, tells ITPro, plenty of companies still run MySQL 5.7. This version hit its end of life two years ago, with extended support ceasing in October 2023.
If organizations do opt for extended support, they risk finding that they are running older software that is unable to make use of the latest technologies. Even if these packages are secure, performance will be limited.
“Those components might not run on newer hardware or on updated cloud infrastructure,” Zaitsev warns. “Over time, you limit your choices and see issues around performance or security.”
“End of life software projects can be hard to get support for internally too,” he warns. “You are making changes to the application to keep it running and you might not see any improvements in performance. You may also have some issues around change management, where you are taking down applications that work and you have to then ensure they come back successfully. That is a risk in its own right.”
Whether that risk is worth taking depends on how critical the application is, as well as the costs of migration or refactoring to a more up to date platform.
“There are lots of examples of old software that still works as expected, and those applications carry on working. But it’s highly recommended adding mitigating controls around these applications to protect them,” advises Middleton-Leal.
After all, end of life software will not stop working on a given date. It just carries on into the twilight.
link
