Tidelift helps organizations remove risk to their revenue, data, and customers from bad open source packages. Bad packages (by which we mean bad-for-enterprise-use packages that are end-of-life, abandoned, or insecure) lead to more vulnerabilities, many of which are difficult to fix. This is making your application development team less productive, and creating more risk for your security team to manage.
Tidelift takes a unique, data driven approach to addressing the issue of bad packages. Tidelift partners with the maintainers of thousands of the most-relied-upon open source packages and pays them to implement industry-leading secure software development practices and document the practices they follow. The result is a unique source of cross-ecosystem package intelligence that customers use to identify and eliminate bad packages.
Today, Tidelift is excited to announce the availability of end-of-life package data to further customers’ ability to identifyt bad open source packages. End-of-life data is now being used in our evaluation of open source packages and is also available to our customers via our web UI and APIs.
What is end-of-life?
An end-of-life package is one whose maintainers have declared that it is no longer maintained. In the case of a vulnerability or an attack, end-of-life packages do not receive updates or security patches, thus putting the burden of remediation entirely on users. End-of-life packages are highly risky and should not be used for application development.
Why are end-of-life open source packages bad?
Everyone scans for vulnerabilities. But what about the latent risk from packages that are officially no longer maintained, meaning future vulnerabilities will no longer be fixed. In many instances, organizations are often unaware of their dependence on end-of-life open source packages due to the challenges associated with gathering the relevant data.
Take Log4Shell as an example. Many organizations spent millions of dollars and hundreds of hours doing an emergency remediation of a critical vulnerability. But the original log4j package that was affected by the vulnerability had been declared end-of-life in 2015—six years before Log4Shell. Users who were aware of the end-of-life event and had already migrated to its replacement made a simple, small upgrade to remediate the vulnerability. Users who weren’t aware of the end-of-life had a major migration that required code changes in their applications, under extreme time pressure.
An end-of-life package will not be fixed if there is an issue. If a vulnerability is discovered, you will have to find a replacement and then possibly have to re-architect your application to use it. This isn’t something you want to do in an emergency. It's a severe technical risk that could create a time and resource-consuming emergency fire drill for your engineering team.
Regulatory requirements
Regulatory authorities are noticing the risk associated with end-of-life software, and beginning to require that organizations track and report their usage. Examples include:
PCI-DSS certification
To comply with PCI-DSS requirements regarding end-of-life software, organizations must regularly monitor software, assess end-of-life related risk, implement mitigation by upgrading or replacing software to reduce risk, and maintain documentation of end-of-life software within their organization. Failure to remediate end-of-life software related risk in a timely manner can put PCI-DSS certification at risk.
Cybersecurity requirements for financial services companies
The state of New York has instituted new cybersecurity requirements for financial services companies that require companies to attest to the risk brought in by the cybersecurity practices of third parties, which includes open source software they depend on. In the event that open source software is end-of-life, that risk transfers to the company and needs to be tracked and accounted for. This directive took effect in April of 2024.
Cybersecurity in medical devices
The United States Food and Drug Administration implemented new cybersecurity requirements for medical devices in October 2023, and explicitly states that device manufacturers must, for all their software dependencies, include the software maintenance status, support status, and end-of-support date. These requirements do not distinguish between third-party commercial and open source dependencies.
These are just some examples, regulations such as these are likely to spread to other industries and other jurisdictions in the future. Not tracking the end-of-life state of the software you rely on opens your organization up to regulatory risk as well.
How is Tidelift helping organizations eliminate the risk of end-of-life open source packages?
In order to minimize risk, organizations need to prioritize the work of migrating away from end-of-life open source packages. However, gathering data and identifying end-of-life packages is time consuming and challenging as there is no centralized source for this information.
Tidelift is addressing this area of need for organizations. Our data scientists comb a number of sources, including package manager data, foundation data, and package READMEs, and source repositories to collect this data. We’re expanding our open source package analysis by merging end-of-life data with existing information about deprecation, maintenance, and other secure development practices into a holistic recommendation that organizations use to eliminate entire categories of risky and bad open source packages from their environments.
Organizations use of end-of-life related data to eliminate bad packages by:
- Evaluating new open source packages before using them for application development: By looking at the Tidelift recommendation that now incorporates end-of-life data, a developer, engineering manager, or architect can avoid a package that has been declared end-of-life, or has an upcoming end-of-life date.
- Monitoring the open source packages in use: An engineering manager or architect can implement ongoing evaluation to check if the open source packages previously adopted may have an upcoming end-of-life date. When a new end-of-life date is detected, they can prioritize a remediation process to fix this latent risk before it causes larger scale problems.Additionally, a compliance manager can take this assessment and use it to satisfy any regulatory needs for documenting the end-of-life status of all the open source packages being used in the organization.
- Identifying and eliminating potentially bad packages already adopted: An engineering manager or architect can perform a check of their open source dependencies against Tidelift’s recommendation when doing technical debt analysis. For every “not recommended” package with an existing or upcoming end-of-life, they can prioritize remediation efforts to fix this latent risk before it becomes a problem.
- Reinforcing packages to keep them from becoming end-of-life: Tidelift customers play a direct role in ensuring the packages they rely on keep getting better. In the case of end-of-life packages, gathering the necessary information is just one part of the challenge. The real task lies in the significant effort required to transition away from these packages once they've been identified as reaching their end-of-life stage. This is where Tidelift is uniquely positioned to help by leveraging our network of partnered maintainers:
- Tidelift requires that its partnered maintainers provide a 30-day end-of-life notification period. This proactive measure enables our customers to prioritize the migration process efficiently.
- Throughout this period, we engage in outreach within our partnered maintainer community, encouraging and incentivizing other maintainers to take over responsibility for maintaining the package, hence extending its life as an actively maintained packagee.
- When we identify end-of-life information for packages that fall outside our partnered maintainer community, we collaborate with our partnered maintainers once again, incentivizing them to step in and take over the responsibilities of maintaining the project. Here are a few success stories where Tidelift’s partnered maintainers stepped in to prevent open source packages minimist and sockjs from getting deprecated.
Avoiding end-of-life risk in your enterprise
If you’re not tracking the end-of-life status of software that you use, you open up your organization to both technical risk from future vulnerabilities, and regulatory risk that would impact business initiatives.
Tidelift’s new end-of-life capabilities allow you to avoid bringing risky packages into your organization, plan initiatives to remove existing end-of-life packages, and detect when software is end-of-life. By undertaking these efforts, you remove entire categories of risk before it becomes a problem for your organization, and you can focus on the value that you were hired to provide.
More to come
Today we’re announcing the availability of package end-of-life data. We’re working on getting more granular and diving down to open source package version level end-of-life data, and gathering alternative packages that users can use instead. Keep checking this space as we’ll be making an announcement about version level information soon!
Contact us or read our documentation to learn more about how Tidelift can help you with end-of-life data and to eliminate bad open source packages.
50 Milk St, 16th Floor, Boston, MA 02109