Understanding EOL OSS risks – and what to do

A couple of the big hitters in the open-source software (OSS) world — CentOS 8 and AngularJS) have hit their end-of-life (EOL), a timely reminder that organisations need to have clear, planned strategies around OSS release lifecycles. In addition, with some unpatched vulnerabilities making the news recently, such as Log4Shell, the risks around unsupported or out-of-date software are painfully clear. So, organisations need to have a planned EOL strategy for OSS.

The challenge is that, as we all know, software development teams are busy people with tight deadlines and often work with limited resources. Deciding on software updates or migration plans when OSS community long-term support ends and just before going into EOL can be difficult and time-consuming. It is tempting to keep heads down and carry on working with EOL OSS in the hope that nothing will happen, or if it does, it is going to be someone else’s problem. Unfortunately, that is a hazardous approach and the longer dealing with EOL OSS is deferred, the more the risks will accumulate.

When the end-of-life or end-of-support phase of the OSS lifecycle arrives, the open-source community no longer releases updates or fixes for the software. In practice, this means that even if new vulnerabilities (CVEs) are discovered, the EOL OSS remains unpatched by the community, and no new versions are released. As a result, software using EOL OSS becomes more vulnerable and at risk of exploits on those unpatched vulnerabilities.

SEE ALSO: Collaboration in the cybersecurity industry: It’s time to start disrupting disruption

Other risks and costs

When OSS reaches the EOL date, software developers and operations teams will effectively be on their own. In-house support is viable, but it can bring some significant challenges, take up valuable manpower, and present hidden costs. For instance, unsupported software can breach compliance: companies with PCI-DSS certification require critical patches to be deployed within one month of release. Failure to do so can lead to fees and decertification. Other organisations have their own internal IT policies about keeping up with the latest releases of every software component, and breaching that internal IT policy is out of limits.

Performance is another potentially costly issue. Businesses may miss out on potential reductions in hosting or hardware costs available on the market by keeping EOL software. New software versions could include optimisations to make better use of hardware and, with that, performance improvements.

A final but crucial aspect of supporting EOL OSS in-house is the drain on resources, requiring development teams to be allocated to software maintenance and away from other activities. Assuming a patch is available, it can take hours or days to backport a patch, create a build environment if one does not exist, build the package, testing, regression testing, pre-production deployment and production deployment.

Support options

Extended support may be available through a vendor providing a commercial version of the OSS or via a third-party vendor providing OSS support. When organisations offer commercial versions of OSS, typically, this is via a subscription that includes maintenance and support for their specific software versions (not the community version). While this has been proven to be a successful business model for vendors, customers become locked in with those commercial versions of OSS.

A third-party vendor providing OSS support could be a more flexible option, it brings access to experts on the required open source packages, plus options for professional services and training. The key is to find the right expertise to support OSS, and for EOL versions, that means a vendor able to patch or backport patches for EOL software.

It is also vital to understand the different types of commercial open-source offerings that are here to stay. In fact, today, commercial OSS offerings are mostly available via a SaaS offering where users do not have to deal with installation and maintenance, or Open Core offerings where vendors offer complementary paid-for functionality on top of community OSS. However, organisations must ensure that what they select for OSS support has the necessary expertise and the right service level agreements for their OSS.

SEE ALSO: Observability in 2022 – more open, more insight, more collaboration needed

Migration

Dealing with EOL needs to be an integral part of an overall, more planned OSS lifecycle management strategy, including the day when migration to new software is inevitable. Elements to consider when planning a migration to a new OSS are multiple, starting with research into how well-backed the OSS is, community participation, size of the project, stability, available documentation, and the volume of knowledge-sharing between contributors and users.

Migrating or moving to a newer version of the same software could be the most logical approach, even if it is very different. That said, in cases where the open-source project ends, such as CentOS and AngularJS, there are no new community-supported versions available as migration options.

Right now, organisations worldwide depend on OSS, so making the right decisions around it have never been so critical: it is time to recognise the risks of EOL OSS and implement a more managed, formalised approach around the software on which these organisations depend.

The post Understanding EOL OSS risks – and what to do appeared first on JAXenter.