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.
Any vulnerability or critical bug in an end-of-life package will not be fixed, and you will have to attempt to fork and fix the problems yourself, spend time moving to a new package, or carry the risk.
By proactively monitoring and moving away from end-of-life packages, you can reduce your risk before it becomes a critical emergency.
An example is Apache Avalon. Customers should not expect any security or maintenance on this package.
How does Tidelift detect end-of-life packages?
Tidelift researches and pulls information on end-of-life packages from places such as upstream package managers, collection sites such as https://endoflife.date, and foundation sites such as the Apache Attic. Tidelift also performs continuous manual research to validate our automated detection.
We aggregate and normalize this data across all of our supported ecosystems, and we provide documentation of our findings. This ensures your developers and compliance teams have the appropriate documentation and steps to remove the risk.
Why our data is better
Tidelift partners with the creators of thousands of upstream open source packages to map their security maintenance plans. This gives your team a better way to forecast and plan time allocation for major and minor upgrades.
Tidelift’s contractual partnership with maintainers ensures that packages don't end up end-of-life. We have also assisted partnered maintainers when taking over an end-of-life package to ensure business continuity and software supply chain stability for our customers.
We also give this data to our partnered maintainers, so that they can take care of their own dependencies and remove that burden off of your team.
Use cases
This data allows our customers to answer the following questions:
- How widespread is unsupported open source software in my applications?
- What packages should we move to as a replacement?
- What packages or versions in my applications have the most pre-CVE risk, and should be prioritized to address?
- For version-level end-of-life, how many versions behind are my applications?
- How many days out-of-date from the next supported version is the end-of-life version currently being used?
Outcomes
- We reduce the number of end-of-life packages in your application
- We give you a prioritized prediction of where security risk is likely to emerge over time, before it becomes a fire-drill
- Time and effort savings for compliance with emerging FDA and NY500 financial regulations specific to 'end-of-life' or 'end-of-support' software
Using end-of-life data
If you're pulling data into other tools, Tidelift's package information APIs contain end-of-life data, and there are additional dedicated APIs that provide more nuanced end-of-life information. There is more detail on using our data to analyze a package here. We recommend unifying this with the SBOM, scan results, or technical debt workflows your team has in place.
If you are storing and analyzing your data within Tidelift's software, the end-of-life standard can flag the use of end-of-life packages in your SBOMs. You can also generate a report with a list of end-of-life packages in use to prioritize and work through.