Reviewing security vulnerabilities

You can ensure that every requested and approved package release is reviewed for known vulnerabilities by enabling the Vulnerabilities standard.

Tidelift maintains a security database of vulnerabilities and is proactively reviewing these vulnerabilities. For each vulnerability, we share a recommended upgrade path and advice from the upstream maintainers. This lets your designated catalog administrator make an informed decision about whether to remove the vulnerable release or create an exception.

How do I set up security vulnerability review?

To ensure all security vulnerabilities are reviewed, turn on the Vulnerabilities standard from the Catalogs > Standards page. NOTE: You must select a specific catalog before Standards are shown. 

Configuring the standard

Your team likely has a review process for any new open source package that your developer wants to start using. The 'Vulnerabilities' standard helps save your team time by creating tasks only for the items you want to review. Additionally, developers can move quickly when the standard is configured to automatically approve or deny a requested release.

For more information on setting up auto statuses, visit the auto status article. 

What happens if a package release in my catalog doesn’t meet this standard?

If Tidelift learns about a new security vulnerability on an already-approved package release, we will send a notification with a task to review the new security vulnerability for anything not set to approve (see above). When completing the task, you will receive recommendations from Tidelift on how to handle the security vulnerability.

For example: A new CVE of 7 or above is disclosed (on an already-approved package release) and your team has set CVE scores 7 or above to "Deny if newly introduced". A task to review whether you'd like to deny this request is then created. In this scenario, Tidelift would not automatically deny this release.

You can choose to either Accept Tidelift’s recommendation or make a decision yourself on how to handle each vulnerable release. Your options include:

• Replace with an unaffected release The vulnerable release is denied on a specified date, a newer and unaffected release of the same package is approved for use immediately.
• Remove the vulnerable releases The vulnerable release is denied on a specified date, no other release is approved.
• Create an override The vulnerable release stays approved in your catalog.

When choosing to deny the vulnerable release, the catalog administrator can specify the date that the vulnerable package release will become denied, giving developers a buffer period in which they can make the requisite changes to their repositories. To deny the release immediately, select today’s date.

What happens when a newly requested release doesn’t meet this standard?

If a newly requested release contains a security vulnerability and this standard is turned on, you will be warned that the release contains a standards violation. You can review the vulnerability and all related information before deciding whether to approve or deny the request, or you can have Tidelift automatically deny it by selecting denied in the configuration. In either scenario, approving the request creates an override.

For example: Your organization has a mandate to have disclosed security vulnerabilities 7.0 and higher (High-Critical) denied. Setting "Deny if newly introduced" will automatically deny the release for use. Next, your team wishes to evaluate security vulnerabilities ranging from 4.0-6.9 (Medium) case-by-case. Your team would set the Medium range of scores to "Require manual review." And lastly, your organization can automatically approve any security vulnerabilities between 0.1-3.9 (Low) by setting this range to "Approved". 

Creating and removing overrides

You can review the overrides created for this standard by doing the following:

1. Select Catalogs
2. Click Standards
3. Find the Vulnerabilities standard
4. Select Manage exceptions
5. From here you can view, create new exceptions, remove exceptions, and export as a CSV.

Known vulnerabilities in projects report

You can also get vulnerability information from the known vulnerabilities in projects report.