The modern software supply chain is a complex web of dependencies, but a critical vulnerability lies hidden within it: unsupported, End-of-Life (EoL) code. Often referred to as ‘abandonware,’ these components no longer receive security patches, creating persistent and often invisible risks inside countless applications. High-profile security incidents in recent years have revealed this isn’t an isolated issue, but a systemic weakness. The lack of a clear, universal standard for how developers communicate when a product is no longer safe to use has left organizations exposed.
To understand how the industry is moving to solve this problem, we spoke with Sergii Demianchuk. As a cybersecurity expert and a key member of the OASIS OpenEoX Technical Committee—a global consortium developing a new standard—he is on the front lines of defining a more secure future. We discussed the nature of the EoL threat, the push for standardization, and what it means for both security and compliance.
From your perspective, what is the biggest security challenge the software industry faces today regarding unsupported or End-of-Life (EoL) software?
The biggest problem is that there’s no common language. Every company announces software end-of-life differently, if they announce it at all. It’s chaotic. This leaves companies running unsupported code—what I call “abandonware”—which is a huge, open door for attackers.
Your work introduces a data-driven way to measure when software is in decline. Could you briefly explain the value of quantifying this risk?
You can’t fix what you can’t measure. We needed to find the warning signs—things like how often code is updated or how quickly issues are closed. By tracking these signals, we can spot a dying project before it’s officially declared dead. The most startling thing we found was that around 42% of the open-source software people are actively using is already showing these signs of decline.
You’re part of the OASIS OpenEoX committee, working with major tech and government players. What is the main goal of this collaborative effort?
The goal is simple: get everyone speaking the same language. The OpenEoX committee brings together the people who build software, like Cisco and Microsoft, and the people who defend our infrastructure, like CISA and the NSA. We’re creating a single, machine-readable way for any developer to say, “This version is no longer supported after this date.” It’s about creating clarity in a very messy ecosystem.
With new compliance rules like PCI DSS 4.0 now requiring EoL management, what does this mean for the future of software development and maintenance?
It means EoL management is no longer optional. Rules like PCI DSS 4.0 are making it a formal requirement for doing business. You now have to prove to auditors that you’re tracking and dealing with unsupported software. This forces the conversation out of IT and into risk management. Our work with OpenEoX gives companies the tools they need to pass those audits.
Looking ahead, what is the single most important step for improving software supply chain security over the next few years?
Getting this standard widely adopted. That’s the most important step. We need to make checking a component’s lifecycle status as automatic and routine as checking for vulnerabilities. If we get this right, we start fixing the foundation instead of just reacting to the latest crisis.
Beyond compliance requirements, what’s the business case for investing in standardized EoL management? How do you quantify the ROI of implementing these frameworks compared to the potential costs of security incidents from abandonware?
The ROI calculation is actually quite compelling when you break it down. The direct costs are relatively small, implementing OpenEoX typically requires minimal infrastructure changes since it leverages existing security tools. The savings are substantial.
First, there’s operational efficiency. Manual EoL tracking costs organizations roughly 40-60 hours per month for a typical enterprise environment. Automation eliminates most of that. Second, there’s risk reduction. The average cost of a supply chain security incident is now over $4.4 million according to recent studies, and abandonware creates persistent attack vectors that are often missed by traditional vulnerability scanning.
But the most significant ROI comes from compliance efficiency. With regulations like PCI DSS 4.0 now requiring EoL management, the cost of manual compliance documentation can run hundreds of thousands of dollars annually for large organizations. OpenEoX provides automated audit trails that dramatically reduce these costs.
We’ve seen organizations calculate payback periods of 6-12 months, primarily from the operational efficiency gains and reduced compliance overhead. The risk mitigation is essentially a bonus on top of those direct savings.
What are the biggest obstacles you’ve encountered when trying to get organizations to adopt standardized EoL frameworks, and how do you address resistance from development teams who might see this as additional overhead?
The biggest obstacle is what I call ‘security fatigue’, development teams are already overwhelmed with vulnerability management, compliance requirements, and delivery pressures. When you introduce another framework, their first reaction is often ‘not another thing to track.’
We address this by focusing on automation and integration rather than manual processes. The key is showing teams that OpenEoX actually reduces their workload by providing clean, machine-readable data that integrates directly into their existing CI/CD pipelines and security tools. The other major challenge is organizational silos. Security teams understand the risk, but procurement teams are buying software, and development teams are choosing dependencies, often without talking to each other. We solve this by making EoL data visible across the entire software lifecycle, from vendor selection to deployment monitoring.
With the rise of AI-powered development tools and automated dependency management, how do you see OpenEoX standards integrating with these technologies to proactively identify and remediate EoL risks before they become critical vulnerabilities?
This is where things get really exciting. AI-powered tools are already analyzing code patterns and dependency health, but they’re missing the critical piece – the official lifecycle information. OpenEoX provides that missing structured data.
Imagine an AI system that not only identifies a vulnerable dependency but also knows that the project maintainer announced end-of-support six months ago. Instead of just flagging the vulnerability, it can prioritize migration to an actively maintained alternative. We’re seeing early implementations where AI tools consume OpenEoX data to automatically suggest replacement libraries that are functionally similar but actively supported.
The real game-changer is predictive analysis. By combining our decline indicators, like reduced commit frequency and slower issue resolution with AI pattern recognition, we can predict when a project is likely to become abandonware months before it’s officially announced. This gives organizations time to plan migrations rather than scrambling when support suddenly ends.
