October 21, 2021

The Hidden (and Not So Hidden) Costs of Unsupported EOL OSS

Open Source

By

In a recent Gartner Report, they stated that "Open-source software is used within mission-critical IT workloads by more than 95% of IT organizations worldwide, whether they are aware of it or not." For those unaware of their open source, or without proper end of life (EOL) planning for that open source software, EOL can present a number of risks -- both known and unknown.

In this blog, we give an overview of the typical OSS community support lifecycle, what happens when OSS reaches EOL, then dive in on the hidden (and not-so-hidden) costs of unsupported EOL OSS.

The OSS Community Support Lifecycle

Each open source software project is different. While most open source projects share common community support lifecycle phases, the timing and duration of those phases varies from project to project. It's also important to note that these phases, and the dates agreed upon by the community, aren't written in stone. Still, open source software typically share three phases -- the release and maintenance phase, the long-term support phase, and the end of life phase.

Release and Maintenance Phase

During the release and maintenance phase, the open source project releases a steady stream of patches, bug fixes, and other security updates. These updates are released to the community as they become available, or as new versions are released. With some distributions, this may mean patches are backported from more recent versions. In general, these updates maintain binary compatibility unless there are significant issues that necessitate a change.

Depending on the software and the ease of upgrade, many organizations try to keep their open source software within this phase by upgrading to the latest supported version of the software.

Long Term Support Phase

After the end of the release and maintenance phase, open source software typically enters the long-term support phase. During this phase, the community updates to the software are typically limited to security updates.

For organizations where upgrading software can be a drawn out process, working with open source software in the community LTS phase is common.

End of Life / End of Support

When the software reaches the end of the long-term support phase, it reaches community support end of life. This means that the community no longer releases updates or fixes for the software. Except for rare cases, any new CVEs found in EOL OSS will remain unpatched unless manually backported.

What Happens With EOL OSS?

As open source software reaches end of life, and remains unsupported, new CVEs go unpatched and systems become more vulnerable. Libraries and other software could have bugs that become more noticeable after years of being used, but there are no releases for this version of your distribution.

Extended support may be available through a third party (or the producer of a commercial distribution). These typically only include security updates, and even then, possibly only major ones. There may be deeper issues with software than a few patches can fix, which have been fixed in a later version (available in a later distribution), but are not able to be backported. These will then be used "at your own risk", and security issues could possibly be mitigated, but not fully addressed.

At this point you are generally on your own to patch the end of life software. There are no more updates or bug fixes of any sort being released. The distribution is effectively abandoned. It is likely most third party application creators will no longer provide versions for your EOLed system. Most likely all support will have to be provided in-house.

The Hidden (and Not So Hidden) Costs of Unsupported EOL OSS

There are a number of risks that impact unsupported end of life open source software. Security is the most discussed, of course, as it's one that can put your organization on the front page of the papers for the wrong reasons. But there are other, less considered costs that can impact your organization.

Security

As mentioned throughout the article, keeping software patched against vulnerabilities is crucial. With unsupported end of life open source software, the steady accumulation of unpatched CVEs means an ongoing and compounding risk of exploit.

Example

As an example, CA certificates expire and get rotated all the time. An out of date certificate bundle can leave your system vulnerable, or even unable to connect to remote sites. Recently we backported the certificate bundle from CentOS 7 to CentOS 6 as part of our extended support, and the customer systems became more secure as a result.

Compliance

For organizations working under established security compliance standards, unsupported end of life open source software means non-compliance with those standards. These organizations must either find an alternative source of patches, upgrade to a supported version, or migrate to a new, supported software.

Example

PCI-DSS requires critical patches to be deployed within a month of release (section 6.2). Non-critical patches need to be applied within “an appropriate time frame, for example 3 months”. With PCI-DSS, there are other sections that have other requirements. Non-compliance can actually result in fees or decertification, which can have long lasting effects, if not permanent.

Libraries and Applications

Unsupported end of life open source software can also present risk via associated libraries and/or applications. This can happen via new patches applied to the end of life open source software, or via the complexity in upgrading these supporting libraries and applications.

Example

Some applications have major rewrites between versions. A bug or security issue may be found in the later version and a CVE produced, but since the old version is out of support, no patches/updates are created and made available for the older version. Your application is now vulnerable to that bug, with no patches to fix it. Only mitigation procedures are available, which may or may not be effective or useful.

System Performance

Open source software is iterative, and often resides within a competitive landscape. In order to maintain or expand market share, open source projects often focus on improving performance of the software. This can mean that organizations are missing out on the potential decreases in hosting or hardware costs if they stay on end of life open source software.

Example

New major versions of languages such as Ruby and Python often come with performance improvements. Sometimes those are because of improvements in the language itself, sometimes it is because of improvements in kernel subsystems or library implementations that the languages (or even any application) can take advantage of. Upgrading to newer versions can increase performance of the system, and decrease costs associated with maintaining it.

Self Support Costs

Self support costs for end of life open source software are two-fold. One, they require development resources be allocated to fixing issues. Two, they pull development resources away from other priorities.

Example

In this day when people tend to have many responsibilities, having one more just adds to the load. It can take hours, even days, to backport a patch, set up a build environment (if one isn’t available already), build the package, and adequately test it. That's assuming a patch is available! If a bug is found that was fixed in a later version, but wasn't deemed necessary to fix by the community for an EOL version, you may have to backport it yourself. Some libraries and applications change so much between versions that it may not even be directly applied, and have to be changed to fit the older code. This necessitates further testing and verification to avoid introducing regressions.

Final Thoughts

Software, whether open source or not, will always be at its most vulnerable when it's unsupported and unpatched. Understanding the risks that accompany end of life and accounting for them with proper support is key. And while securing support and patches for EOL OSS is critical, it's only one part of a fully-developed open source strategy.

Understanding the risks of EOL OSS at the organizational level (as presented here in brief) can serve as a spark to create formal open source adoption, maintenance, and overall management strategies.

Get Support for Your End of Life OSS

From 24/7/365 technical support, to consultative guidance, OpenLogic can help your organization to realize the full benefits of open source software. Learn more about how we can support your project by talking with an open source expert today.

Talk to an Expert

Additional Resources

Lance Dillion Bio

Lance Dillon

CentOS Engineer

Lance has been working in the IT field for over 30 years, most of it concentrated on data centers and infrastructure. For the past 10 years he has focused on SaaS infrastructure, ensuring reliability, high availability, and scalability of systems. He has been working with CentOS related distributions for the past 25 years.