Getting started with Tidelift

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 activities 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 by augmenting your existing tools and workflows using our APIs, OR by adopting Tidelift’s default web UI and CLI. 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 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.

  1. When considering adoption of a new package, check whether it is recommended first.
    • Using the API: Learn how to integrate our data into your tools and make it available to decision makers and developers to consult in making package decisions. 
    • Using Tidelift’s tools: Learn how developers can run the Tidelift CLI to assess packages, or evaluate the package in the Tidelift web UI. 
  2. 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.
    • Using the API: Learn how to pull the Tidelift package details API for new changes and trigger new package assessments as needed. 
    • Using Tidelift’s tools: Learn how to use the Tidelift CLI to send Tidelift SBOMs, and enable tasks to review new violations. 
  3. For packages already adopted, identify a list of bad packages and work down the list removing any that are practical to remove.
    • Using the API: Learn how to use our data to generate a list of bad packages in your existing tooling. 
    • Using Tidelift’s tools: Learn how to use the Tidelift CLI to send Tidelift an SBOM and get a prioritized action report for each project. 
  4. 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. This can be done using either our APIs or web UI and CLI to identify at risk packages and building a plan with Tidelift to prevent them from becoming problematic.

We have designed Tidelift to be flexible to ensure simplicity and ease of integration into your organization’s existing workflows. Learn how to integrate Tidelift into your workflows. 

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. 
Was this article helpful?
0 out of 0 found this helpful



Article is closed for comments.

Articles in this section

See more