End of life software for agencies is (and isn’t) what you think
TL;DR - Insecure apps are as much of a risk for agencies as they are for their customers. Agencies want support and maintenance contracts with their customers, but are often unable to adequately convince them. But of those contracts which are in place, agencies often only offer a bare minimum of a service.
Risk, in the context of application security is of course always relative: The owners of a low-traffic recipe blog have fewer regulatory or legislative guidelines to adhere to than a government department running a nationwide identity system with millions of daily users.
In the context of website, and web-application security, the focus on risk isn’t unreasonable considering the regular tide of reported data-leaks, exploits, and hacks, as well as industry research - particularly the most recent 2025 OWASP Top 10 report - all of which serve to cement-in that the threat to industry remains real.
But it pays to consider that for a number of organisations; agencies, studios, and in-house development teams, the analysis required to assess risk for themselves and on behalf of their customers, is made more difficult by the very nature of their business.
Ironically, it’s the Project Managers, Product Owners, and Account Managers working within agencies who require access to risk-orientated data for planning with their customers and stakeholders - but is instead siloed within traditional engineering and security teams.
If a way can be discovered to present data in a meaningful way for proactive planning purposes, then there are financial as well as reputational opportunities for agencies in the form of currently unrealised income and a reduction in churn.
And if all this is true, it means there exists an alternative, parallel lens through which we may view the issue of unsupported software in an agency context, other than pure risk alone.
What is end-of-life software?
An agency typically manages dozens or hundreds of customers’ software applications, where each one performs some essential function which the customer’s business relies on. They comprise individual software components which the agency has selected based on their own expertise and their knowledge of the customers’ requirements.
An agency typically selects components from numerous available container images, language run-times, application frameworks, databases, web and application servers to serve specific use-cases. Each one is an independent product developed by a maintainer; a company, team, or independent contributor who delivers new features, bug-fixes, technical support, and documentation for it.
At some point in a software product’s lifespan, it becomes necessary for maintainers to drop support for one or more versions of it. That point in time is known as the end of life date and usually applies to a subset of its version(s). For larger, or more mature products, this work is usually done according to publicly available roadmaps, but it’s important to understand that the reasons for dropped support can vary:
Cost: Reducing the overall time spent on an otherwise expanding product line
Sales: Vendors may elect to promote one product version over another
Deprecation: When support for software the product itself relies on, is dropped
Key person risk: When key staff leave an organisation and take some IP with them
Security: Old versions contain security vulnerabilities which are impossible to fix
Compliance: Older versions don’t comply with certain business regulations
Engagement: Falling product usage becomes a financial liability to support
The problem with end of life software
Any company is liable to suffer any number of problems derived from end-of-life software without proper management, but ultimately they’re beholden to a regulatory landscape which is mostly within their capability to adhere to.
The same cannot be said for agencies specifically, where the cost of inaction is proportional to the cost to both the agency and the customer.
Agencies are typically experts in a small set of available technologies and draw upon these expertise in most of their customer engagements. It follows then that an end-of-life software component such as an application-framework discovered in one customer’s project, is very likely to exist in other customers’ projects too.
But how should an agency know which of its managed applications contains unsupported software? Which tools should it use to get a list of software end-of-life dates for Python, or PHP, or for Dotnet? Moreover, exactly what is the problem faced by agencies and its customers should things be left as-is anyway?
Every day literally millions of automated malicious access attempts are made against hosted web-applications. If you’ve ever even glanced at the real-time logging data produced by a web-server or any internet facing appliance, you’ve seen the scale and sophistication involved.
The longer unsupported software continues as a building block of larger applications, the higher the likelihood that such attempts are ultimately successful and which may be traced back to the faulty component.
It’s useful to understand the reasons why such malicious access attempts occur in the first place. The reasons are varied, but by way of demonstration, here’s a non-exhaustive list which provides a flavour of what’s out there.
Scenario: The Data leak
What is it? Personal information belonging to website users is accessed via stolen or phished administrator credentials, or the website’s database is found separately to the website which is itself poorly secured. You can use the popular haveibeenpwned website to check if email addresses under your control have been found in major data leaks.
What’s the motivation? Usually financial gain, sometimes informational. The stolen data can be on-sold on dark-markets to scammers and spammers.
Scenario: Defacement
What is it? Offensive or controversial content is posted or uploaded to a website which replaces or is displayed more prominently, than the original content. In 2022, several Ukrainian government websites were attacked and defaced.
What’s the motivation? Usually political or ideological.
Scenario: Ransomware
What is it? Critical data such as application configuration or authentication credentials are accessed and rendered inaccessible by encryption. A ransomware attack happened in September 2023 to MGM Casinos, resulting in critical IT infrastructure having to be shut down.
What’s the motivation? Usually financial. Data is decrypted on receipt of a ransom payment.
Scenario: Distributed Denial of Service (DDoS)
What is it? A critical piece of a company or government’s digital infrastructure such as a banking website or identity platform is flooded with requests it wasn’t designed to receive. In September 2025 the largest DDoS attack seen by the cloud defence service Cloudflare was observed and stopped.
What’s the motivation? Financial, political or ideological. The affected applications are unable to operate normally. Coupled with announcements from hacking groups, the effect is a temporary perception of control which may increase awareness of a cause.
Scenario: Malware
What is it? There are numerous kinds, but in the most recent example we’re aware of, a software maintainer’s version control system account was compromised and malicious code added to their software. This occurred in September 2025 with the Shai-Hulud attack.
What’s the motivation? Financial. Informational. In the case of Shai-Hulud, the aim was to obtain cryptocurrency through wallet monitoring and mining.
By definition, a software version which has reached its end-of-life, has no support whatsoever and the original maintainer is henceforth unwilling and unable to fix any bug or issue found subsequently.
What this means practically is that all software applications ever built on the affected software version, automatically become vulnerable to the same exploits, should they be found.
Discovery is harder than you think
If remediation is the industry word used to describe the follow-up activities involved in resolving an issue identified in software such as reducing permissions on a cloud service or fixing a user-interface problem, then discovery is always the necessary precursor step.
Agencies first need to locate those customer projects that are affected by end-of-life software. However, they also need to understand the end-of-life dates of each of their commonly used technologies, before being able to reconcile them with their customers’ projects - a two step task.
There are several vendors whose products provide per code-base or per container-image insights into end-of-life data for open source and commercially licensed software. Some also provide a search facility for security vulnerabilities and dependency packages. But when delivering hosted applications using multiple cloud providers on a range of different technologies (or multiple versions of a single technology), agencies derive most benefit from both discovery and reconciliation.
Even better would be to present end-of-life discovery in the context of an agency’s own managed application portfolio, killing two birds with one stone.
There’s an argument which contends that customers themselves should inventory their own applications using their own tools. After all, it is they who shoulder the burden of any compliance risk. However, because the technical skill required for application development has already been contracted to a third party, it’s unlikely customers have skills necessary.
There’s also an opposing argument which suggests that agencies should advocate more for the benefits to customers of regular maintenance through paid support contracts to cover end-of-life scenarios. But experience shows that many agencies have great difficulty in explaining the benefits to customers of long-term and even routine maintenance work, given what little there is to show of the work done; no shiny UIs and no new features or integrations.
Stumbling block scenarios
In order for agencies and ultimately their customers to benefit from the opportunities we believe are present in this space, some things might need to change on both sides of the agency and customer divide.
We’ve seen that the provision of development services in an agency context are mere table stakes. The time is long past where all agencies needed was to demonstrate a capability to deliver. Customers and buyers are now allocating increasingly significant resources to understanding an agency’s capability to maintain their solutions in production.
What this means is that application security, application monitoring, end-of-life notifications, security composition analysis are all on the table for discussion from a customer’s perspective.
So the solution sounds simple enough; agencies propose, draft and sell maintenance contracts, perform regular end-of-life monitoring, and communicate with their stakeholders regularly.
But there are issues to be addressed which suggests things aren’t so easy. They broadly slot into three overlapping scenarios.
1. The Stalemate: Agency Initiated
An agency has developed three web-apps for a customer and wants to offer a support and maintenance contract. The contract includes provisions for pre-paid support hours, guaranteed security patching, and proactive end-of-life monitoring.
However, the customer declines, citing a lack of any cost/benefit analysis from the agency. The customers’ apps remain unsupported beyond their operating system’s end-of-life date.
There is little incentive on the agency’s part to perform anything more than a cursory check-in periodically with the customer, should either party discover a component approaching its end-of-life date.
2. The Stalemate: Customer Initiated
An agency’s customer - a government department - has requested specific maintenance activities from the agency in light of new procurement and security legislation.
The requested activities comprise application security patching with a three day turnaround for CVEs with a CVSS score greater than 0.7 and proactive end-of-life monitoring.
The agency lacks experience in proactive monitoring and patching of this kind. It does however review the available tooling and finds they require either a paid subscription, or manual configuration effort which amounts to more of either than the agency is willing to deploy on a single customer.
The agency concedes it’s in the best interests of both organisations that the customer approaches a larger, more security-mature agency and declines the request accordingly.
In the interim, the application itself remains essentially unsupported to the extent the customer has been mandated to procure.
3. The Poor Delivery
Agency and customer have both agreed a support and maintenance contract which does contain a provision for end-of-life date monitoring.
Over time, the quality of the agency’s contract performance is reduced due to unforeseen circumstances including staff and customer churn. In addition, come renewal time, the customers’ requirements have become more onerous than the agency is willing to support, which leaves the agency close to being in breach of contract, or losing yet another customer.
The net result is that the paid support service as it stands isn’t fit for purpose. And the application in question lies unsupported beyond the end-of-life date of one or more of its components.
Agency opportunity
These legitimate scenarios demonstrate that for entirely understandable reasons, both agency and customer can find themselves in the unenviable position of being in possession of a number of software applications that neither of them is able to satisfactorily support.
But if the agencies of those scenarios could have been better prepared in terms of an investment in tooling and process, then at least two scenarios are effectively rendered moot.
Things begin to look rosier too with the benefits to be had from predictable revenue through pre-paid hours, pipelines of locked-in upgrade work and a reduction in potential customer churn.
Future customers benefit too, assuming these new or improved maintenance capabilities are marketed well.
For agencies looking to maximise profit, and minimise losses derived from poorly managed (or completely unknown) end-of-life software components, there is more than one way to skin the proverbial cat, but first we should discuss software versioning.
A note on versioning
There are several “schemes” used to communicate a software version, the most popular of which for open source software products is Semantic Versioning known as “Semver” for short.
Semantic Versioning is an informal versioning scheme. As such, adherence to it (or any) scheme is entirely voluntary. However, the benefit to software maintainers is understood when inferring meaning from a version change.
Consider the following, typical software version which follows Semantic Versioning:
Major version: Breaking, backwards incompatible or significant functionality changes (e.g., 4.2.1 to 5.0.1)
Minor version: New features, backwards-compatible API additions, or enhancements (e.g., 4.2.1 to 4.3.1)
Patch version: Bug fixes, security fixes, or minor backwards-compatible changes only (e.g., 4.2.1 to 4.2.2)
The most expensive, time consuming, and potentially problematic upgrade for agencies and customers is usually considered to be a major version upgrade.
The following example illustrates the point: A maintainer drops support for version 4.x (where ”x” is any number), but still supports versions in the 5.x “range”. Should security vulnerabilities subsequently be found in 4.4.3 for example, they will not be fixed, leaving agencies needing to react quickly with a solution.
Because maintainers are unconstrained by any assumptions around their software’s use when incrementing a major version digit, they’re free to introduce so-called “breaking changes”. Applications using this software which have come to rely on features now earmarked for change or removal, now have the potential for significant rework to become compatible with the upgraded software’s new way of doing things - also known as its Application Programming Interface (API).
Agency and customer next steps
Upgrade Project
What it is: When a software component of a larger, “consuming” application needs to be upgraded to its next major version, the incumbent agency will usually review the complexity of the application and estimate the effort required to modify it to suit the new version’s API, as well as perform the upgrade itself.
Pros and cons: Locking-in a pipeline of upgrades is a great way for agencies to bring in additional income. Done proactively enough, it also assures customers that the agency is skilled enough for what can be a challenging task. Occasionally maintainers do disappear, become insolvent, or are bought out by other companies. Each of these scenarios has a bearing on the main application, its operation and expected lifespan which is worth taking into consideration.
Providers: Most agencies should welcome the opportunity to estimate the effort required to upgrade to the next major version of a key software component.
Never Ending Support (NES)
What it is: A never ending support contract (NES) undertaken between a customer or an agency, and a third-party company. The third-party is unaffiliated with the original maintainer of now end-of-life - usually open source - software, and commits to providing ongoing support and maintenance services for it.
Pros and cons: There’s no guarantee that the contracted support duration matches the intended lifetime of the affected application, but that’s really little different to the situation from official maintainers. There may also be significant costs associated with access to NES software. Research and cost comparisons are necessary with those quoted by any agency for major version upgrades.
Providers: Shop around as there are several companies offering NES services.
Long Term Support (LTS) or Extended Security Maintenance (ESM)
What it is: A long term support contract (LTS) undertaken between a customer or an agency, and the original maintainer of now end-of-life - usually open source - software. While the original maintainer has now ceased free support of one or more versions of their software, they do commit to priority bug-fixes and/or security fixes for a fixed subset of versions under a paid support contract.
Pros and cons: LTS contracts have a defined, limited duration. Depending on the affected application’s intended lifespan, customers may find that a major upgrade to a supported, open source version of the otherwise affected software is needed in time anyway. Research and cost comparisons are necessary with those quoted by an agency for major version upgrades.
Providers: Not all maintainers are guaranteed to offer an LTS or ESM license service. But for larger software components with commercial arms such as some popular Linux operating systems, many maintainers do offer LTS/ESM licensing options.
Decommission
What it is: The process by which an application is retired and its underlying infrastructure is decommissioned. When customers and stakeholders decide that the cost of application security, maintenance and feature development outweighs the business benefits of the app itself, one option available is to retire the application completely.
Pros and cons: If an application is no longer profitable, or has served its purpose, then depending on its size and complexity, significant amounts of money can be saved in maintenance, license, and cloud costs. On the flip side, careful consideration should be applied with consensus reached by customers and product owners, that a “decom” as it’s known, is the only viable option.
Providers: There is of course a cost to the time required for due diligence to occur with respect to assessing infrastructure, API endpoints and touch-points. However, as with major upgrades, most agencies as the incumbent should welcome the opportunity to estimate for the effort required.
There is of course nuance to everything, so there may be some overlaps, but the above represent the main approaches for what to do with applications containing end-of-life software, or software which is close to end-of-life.
Conclusion
If you didn’t feel qualified to comment on your own organisation’s policies towards end of life software prior to reading this article, you should certainly feel so now!
We’ve covered common definitions, scenarios, rationales, solutions and strategies for the existence, analysis, and mitigation of unsupported software from the perspective of agencies and their customers.
If you represent an agency, you know there’s of course always more you can do for your customers. But when was the last time you took time out to review your approach to maintenance and support contracts?
If you represent the customer in these scenarios - an organisation which outsources its software and web development to an agency - when was the last time you revisited the support contracts you have with them? Are they still fit for purpose with what you now understand of end-of-life software?
As we’ve mentioned, we’ve found several tools which will manage various aspects of an application’s security posture, but very few comprise an EOL software notification feature, and practically none presents it for use by an entire delivery team alongside traditional AppSec data points.
If you haven’t yet reviewed what Metaport can do for your team, we’re currently taking bookings for conversations with interested agencies and studios.