Reviewing security vulnerabilities

You can ensure that every requested and approved package release is reviewed for known vulnerabilities by enabling the Releases have no 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 Releases have no 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 'Releases have no 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.

Based on the configurations your team selects, Tidelift creates catalog tasks for the security vulnerabilities you want to manually review. You can configure the standard using vulnerability severity ratings (a score range) and aligning the specified ranges to one of the following corresponding actions:

• Require manual review - Requested releases will generate a catalog task for review
• Approve - Requested releases will be automatically approved for use
• Deny if newly introduced - Requested releases will be automatically denied if they don't already exist in the catalog

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 exception 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 exception.

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 exceptions

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

1. Select Catalogs
2. Click Standards
3. Navigate to Releases have no vulnerabilities
4. Select View 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.