Managing your catalog
Software changes over time, and that goes for the contents of your catalog as well.
Managing a catalog means that you are keeping it up-to-date so that the necessary package releases are approved to use within your organization and that it continues to meet its defined standards.
To handle such changes, managers will complete tasks that are associated with a catalog. These tasks usually result in package releases being added or removed from the catalog, generating an audit log of changes that can help others understand why a given package release is denied.
There are several different types of tasks that can appear and be completed.
Overview of different tasks
Updates from a Tidelift-managed catalog
A team at Tidelift creates and manages many different Tidelift catalogs. To reduce your management load, you can subscribe to updates from one or more of these catalogs.
A new task is generated when there is an update to one of the Tidelift-managed catalogs that affects packages in your catalog.
The task will include the changes, why they were made, and if accepting the change would violate any standards specific to your catalog (eg. licensing). You can accept or deny the changes.
Resolve security vulnerabilities
When a new security vulnerability is detected on a package you use, a task will be created to determine how to resolve the vulnerability. Whenever possible, we will present additional guidance from the upstream maintainers on how to handle a security vulnerability.
There are two ways to resolve a Task in a Tidelift catalog:
By resolving a security task with ignore, a manager will indicate that downstream developers should ignore any warnings about a given vulnerability. A manager will be asked to provide a note describing why the vulnerability was safe to ignore.
By resolving a security task with upgrade, a manager will indicate that downstream developers should upgrade to a different (likely newer) release of their library in order to resolve a significant security vulnerability. Upon choosing upgrade, Tidelift will calculate the recommended upgrade path for all affected releases of a package, and will suggest the correct upgrades. The manager will then be responsible for submitting these changes to their catalog.
When resolving a security vulnerability in a catalog, managers can choose to specify the date that the vulnerable package release will become denied, giving downstream developers a buffer period in which they can make the requisite changes to their codebases.
If a vulnerability has been resolved in a Tidelift-managed catalog that you subscribe to, then this task will not be created unless you deny Tidelift’s guidance.
As technologies change, your development teams will want to use new packages and package releases. When a developer wants to introduce a new package or package release into the catalog (and into production), that release must go through a package request approval process.
Packages that have been requested for approval will appear on the tasks page for managers to review and either approve or deny along with relevant information about the release. When denying a request, you will be prompted to provide notes that can later be reviewed by the requesting developer as well as future developers.
Package requests can be made via the Tidelfit user interface or in bulk using Tidelift CLI.