Introduction to catalogs

There are a lot of considerations that go into deciding whether or not it’s safe to use a release of an open source package. Each decision you make is critical for engineering teams that are selecting new packages to bring in, and for security and compliance teams that are evaluating risk. Catalogs can make the decision making process easier for you by automatically evaluating the open source you use and synthesizing your decisions into one answer: a release is either approved or denied for use in your applications.

How catalogs work

Catalogs keep track of the decisions you make about violations. Violations are the issues that Tidelift detects with the releases you’re using. How you tell Tidelift to handle these violations will determine if a release is ultimately approved or denied in your catalog.
Developers can use the approved or denied decision to guide their use of open source. In most organizations, denied means something more like “discouraged” because the bar to actually avoid all the issues detected is much too high.

Regardless of how your organization chooses to handle denied releases, a catalog works like this:

  1. A release of a package is added to your catalog.
  2. The release is evaluated against a set of criteria you configure called standards. Each standard you configure represents a different type of issue you’d like Tidelift to check for. For each issue found, Tidelift creates a violation.
  3. Each violation is automatically given an allowed or not allowed decision based on your standards configuration.
  4. Tidelift reviews all of the violation decisions and assigns a release status of approved or denied. A release may have many violations that are allowed or not allowed, but it can only have one release status: approved or denied.
  5. Tidelift continuously monitors the release for new violations or changes to existing violations and automatically updates the release status accordingly.

The end result is a clear list of approved and denied releases for developers to pull from, and a living record of the decisions that were made about the open source you use. You can use this list to track the alignment of your application dependencies with your standards, and engineering, security, and compliance teams can use the catalog’s record of decisions in their respective workflows.

How release status is calculated

Whether a release is approved or denied is based on which violations you decide are allowed or not allowed. In order for a release to be approved, it must be violation-free, or all of the violations must be allowed.

Tidelift will make decisions to allow or not allow violations automatically based on how you configure your catalog standards. If you need to make changes to the automatic decisions, Tidelift gives you the ability to create overrides. If you want to force a release to always be denied, you can block releases.

Note on user roles

There are two different user roles that can be assigned to users in the Tidelift web app: administrator and member.

An administrator has the ability to create and manage a catalog. They are responsible for approving new package requests, reviewing tasks, and managing the catalog. Administrators can save themselves a lot of time by using Tidelift as Tidelift already provides security vulnerability recommendations and licensing data. This delegates the management of thousands of the most common packages to Tidelift. They can further simplify their work by setting up license standards for their organization.

A member is an individual who will be using the approved package releases within your organization’s catalog. They will be able to request new package releases, and will be guided to using the approved releases within your catalog. If you are a developer, see a developer's guide to catalogs.

Was this article helpful?
1 out of 1 found this helpful



Article is closed for comments.

Articles in this section

See more