Catalog tasks

The catalog tasks page is designed to be used by the catalog administrator (whoever is making decisions about what open source is allowed). The catalog tasks page and related workflows are the primary way for decision makers to decide what open source packages are allowed to be used.

With auto status set up, tasks created are for reviewing the automatic decision that was made, and then deciding if you want to change the decision manually. Manual changes to automatic decisions are called overrides.

Catalog standards can be set to automatically allow (but track violations) or automatically deny. If you choose "generate tasks," each task can be closed with a manual decision in the form of an override.

  • If the standard is configured to automatically deny, then an override of Not Allowed confirms you have reviewed the task and agree with the standard;
  • an override of Allowed actually overrides the standard.

If the standard is configured to automatically allow, then the Allowed override will confirm that you have manually reviewed and kept the automatic decision, while Not Allowed will mean you are overriding the standard. Either way, an override closes a task. 

Interpreting the tasks list

The list of tasks is composed of all standard violations found on requested packages. Eg. If a single package is requested that is deprecated and has a security vulnerability, two tasks would be created.

The column categories are as such: 

Type This indicates the type of violation that was found: Licensing, Maintenance, or Security.
Name This is the name of the item that needs to be reviewed for the task. This is almost always the package name and version. The only exceptions are “Releases use approved licenses” standard violations, which will show the license name instead.
Affected This lists the projects that are affected by the violation, and the versions that are associated with those projects.
Date Created This shows the date the task was created
Tags This shows the CVSS score and severity of security vulnerabilities. Only Security tasks have a Tags value.


An example task

In this example, there is a security vulnerability with a CVSS score of 7.5 that is being brought in by the package globalID in the rubygems package manager. The task was created on Feb 10 2023, and version 0.4.2 of this package is being used on two projects: NewCLIProject and rubygemsCLI.


We offer a variety of filters on the catalog tasks page to allow users to see the data that is most important to them.

  • Task Types: Filter based on the standard (or standard type) that generated the task
  • Dependency Source: Filter based on whether the violation is brought in by a direct or transitive dependency
  • Dependency Scope: Filter based on whether the violation is brought into the development scope or the production scope. We consider everything production unless we can reasonably assume it’s not (EG. the scope name contains "dev" or "test").
  • Groups: Filter based on the groups that are associated with the affected project(s).
  • Projects: Filter based on the projects affected by the violation.
  • Package Managers: Filter based on the package manager associated with the affected package.

How to use the tasks page

  1. Click Review on the task the user wants to review. This begins what is generically referred to as the Task Remediation Flow.
  2. Review the package and violation information presented (example below). This is also where a Tidelift recommendation will appear if one exists.

The overall goal of this flow is to decide whether to Approve or Deny package(s) based on the violation. There are other options as the decision is made:

  • Apply your decision to the requested package only, or to all packages affected by the violation
  • Update the standard (only present for licensing tasks)
  • Decide when the decision takes affect
Was this article helpful?
0 out of 0 found this helpful



Article is closed for comments.

Articles in this section

See more