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 decisionmakers to decide what open source packages are allowed to be used.
To access the catalog tasks page for a catalog, select a catalog and go to Catalog > Tasks in the left sidebar.
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.
Filters
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
- Click Review on the task the user wants to review. This begins what is generically referred to as the Task Remediation Flow.
- 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
Comments
Article is closed for comments.