Key takeaways

• Critical software can outlive its package maintenance by decades. Applications often remain operational long after the open source packages, runtimes and tooling underneath them reach EOL.
  
  
• EOL doesn’t mean software stops working. It does mean that maintaining it gets harder. Community patches disappear, vulnerabilities accumulate and upgrading one dependency can create compatibility issues across an entire distribution.
  
  
• Modernization is the goal, but security can’t wait. A controlled software supply chain can help organizations maintain and remediate legacy applications while creating a realistic path toward modernization.

• A vetted open source catalog provides a safer middle ground. Secure repositories, software provenance and continuously remediated components can help teams reduce their reliance on unsupported upstream projects, including the components that used to require separate, bespoke builds to keep alive.

There’s a familiar piece of advice whenever a software vulnerability is discovered: upgrade to the latest version.

That makes perfect sense for many organizations, because modern applications are built around things like frequent releases and infrastructure that can be updated or replaced relatively quickly.

But what happens when the software in question is expected to keep running for another decade?

In the UK, the National Health Service (NHS) learned just how complicated that question can become during the 2017 WannaCry ransomware attack. At the time, around 5% of its IT estate, including medical equipment, was still running Windows XP, which was released back in 2001. WannaCry ultimately affected at least 80 of England’s 236 NHS trusts, disrupting healthcare services across the country. 

This particular incident illustrates a much broader problem. Across regulated industries like healthcare, financial services, and manufacturing, legacy software can remain embedded and operational systems for 10, 20 or even 30 years. And while the hardware may still work exactly as intended, the software underneath it is open to vulnerabilities. 

So, how can organizations keep critical applications secure when upgrading to the latest version simply isn’t an option? Here’s what it takes to keep these long-lived systems secure as the software they depend on grows old, reaches its natural end of life (EOL), and becomes increasingly difficult to maintain.

Between 5% and 15% of Enterprise Dependencies Are Already EOL

According to Sonatype’s 2026 State of the Software Supply Chain report, between 5% and 15% of components in enterprise dependency graphs have already reached EOL. The research identified more than 81,000 EOL package versions with known CVEs that can no longer be patched upstream.

For engineering teams responsible for long-lived systems, this is where things start to get a bit complicated. A lack of community maintenance makes the original environment and its toolchain increasingly difficult to maintain.

So what’s the issue with maintaining EOL?

First and foremost, the projects responsible for maintaining software are no longer expected to release bug fixes, security patches or compatibility updates. That means newly discovered vulnerabilities can remain unresolved, leaving many organizations exposed and required to take responsibility for maintaining the software themselves.

Applications rely on an interconnected system of packages, libraries and runtimes. Change one dependency, and you’re likely to create compatibility issues somewhere else in the stack. Fixing this vulnerability within an EOL environment may require rebuilding packages or updating other dependencies elsewhere. It may also mean retesting the entire distribution to make sure everything still works as intended.

The older an environment gets, the harder this becomes. Original build tools may no longer be available, newer package versions may not support legacy runtimes and the people who originally understood the software likely moved on years ago.

Security has to hold while modernization takes years

For this reason, regardless of  what industry you operate in or how regulated you are, modernization is likely the goal. That said, replacing a decades-old application can take years, and in the meantime, that software still needs to run, and it still needs to be secure.

That's the gap a controlled software supply chain is built to close. ActiveState has offered two different answers to it, and which one applies depends on where the software runs.

A Managed Distribution rebuilds the whole runtime. A Catalog patches the component.

A Managed Distribution is a fully working runtime environment, built and maintained for whatever operating system a team deploys on. Because the components have to work together as a single reproducible unit rather than as packages a build tool resolves on demand, they're vendored directly into the codebase. When a vulnerability turns up, the sequence is: identify it, locate a version of the dependency that resolves it, rebuild the runtime from source, verify it still works, then package and ship the revised runtime with your configurations updated. That cycle runs on a scheduled basis. It's the right model for teams whose environment is treated as one fixed artifact.

The Curated Catalog solves the same underlying problem differently. Instead of a separate runtime with its own build and delivery cycle, EOL and actively-supported components sit in the same private, policy-governed repository, and get consumed the same way: through the package managers, CI/CD pipelines and artifact repositories a team already uses, as standard artifacts, not a proprietary format. 

ActiveState owns the remediation backlog for whatever is in the Catalog. When a fix becomes available, it gets applied, built from source and redistributed against a contractual SLA.

A Managed Distribution treats the legacy environment as its own island, with its own rebuild schedule. The Catalog treats an EOL component as just another component: same pipeline, same policy, same remediation clock as the rest of your stack. For a team trying to modernize, that second model is what makes it easier. There's no second delivery mechanism to maintain alongside the one already in use, and no separate schedule to track for the one part of the stack nobody wants to think about.

Federal systems show how long modernization actually takes

In 2025, the U.S. Government Accountability Office identified 11 critical federal legacy systems most in need of modernization. Eight of those systems run on outdated languages, and seven were still operating with known cybersecurity vulnerabilities.

These figures underscore that the lifespan of critical software doesn’t always line up neatly with the lifespan of the open source software running it.

Knowing exactly what's running, and having a way to keep it patched on the same terms as everything else, is what lets a team hold a legacy application secure while modernization is still years out.

To learn more about how ActiveState can help secure and continuously maintain the open source software your critical applications depend on, explore the ActiveState Curated Catalog today.