Welcome to Tidelift!
We’re on a mission to help organizations reduce risks to their revenue, data and business continuity by proactively improving the resilience of the open source powering their applications.
There are better and worse open source packages, and it matters which ones you choose. Using bad open source packages exposes your organization to unexpected future risk vectors.
The status quo for most organizations is to reactively chase problems that arise from open source dependencies—vulnerabilities in old packages that are sometimes hard to resolve, or abandoned open source projects that don’t keep up with the latest frameworks. The truth is, many open source packages aren’t suitable for enterprise use. These bad packages are end-of-life (EOL) already, or on their way to end-of-life. They lack development activity and may not plan to fix vulnerabilities or continue improving the package. This means loss of productivity, frustration, and burnout for your development team.
It’s easy to take a reactive approach; “find problems and fix them.” But there are so many problems, and this becomes an unpredictable waste of time, that often results in ignoring most of the problems.
Organizations are using Tidelift's package intelligence to choose the best open source software upfront. Getting started is easy with default “recommended” and “not recommended” guidance, learn more about Tidelift’s recommendations.
Looking to dive in deeper and perform specific analysis? We also provide the raw data to make your own determination about what’s recommended for your team. Learn more about the data we provide, that some organizations use to roll out their own recommendations.
Four paths to reduce your reliance on bad open source packages
Organizations must improve productivity and reduce the risk of vulnerabilities for their development team by continuously improving their dependencies, and avoiding and eliminating bad packages from their software development lifecycle.
To get started, think about four activities or practices which can be individually considered. Each activity can be adopted in different ways using different Tidelift capabilities, such as integrations, SBOM tracking, or custom policies. However you adopt them, the actions below lead to the same end goal: using fewer bad packages, which means you move faster and stay safer.
We recommend you adopt these four activities one at a time, and that you be pragmatic. Focus on the easiest approach and the quickest wins. Don’t boil the ocean.
In general, large organizations with existing tools may find it easier to perform the actions below using Tidelift APIs to integrate into their existing workflows, while smaller organizations with less open source management in place may find it easier to use some of Tidelift’s pre-built tools such as SBOM tracking and custom policies.
- When considering adoption of a new package, check whether it is recommended first.
- Monitor packages and track changes over time. Open source packages are abandoned daily; new versions are released, licenses are updated. Be aware of emerging issues.
- For packages already adopted, identify a list of bad packages and work down the list removing any that are practical to remove.
- Reinforcing “at risk” packages to reduce the rate of already adopted packages becoming abandoned or insecure over time. Tidelift does this by providing an income stream to maintainers in exchange for contractual commitments to meet enterprise standards.
Demonstrate the success of your efforts
It is important to report back on the progress of your efforts, to give stakeholders the necessary visibility into how effective the organization is in reducing risk vectors. We’ve built some out-of-the box reporting capabilities to make this easy for you:
- If you are using the Tidelift tools to store your SBOMs, on request we can generate reports for:
- Count or % of bad packages in use
- Vulnerability counts
- We can create a maintainer impact report based on a list of packages you give us, or SBOMs you have uploaded to our tools, showing how we are preventing packages from “going bad” over time.