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
Different policies for different vulnerability severity
Your team may have different policies for what vulnerabilities need to be remediated before code can be deployed. For example, maybe your policy is that code that contains High and Critical vulnerabilities cannot be deployed to production.
To configure the standard in detail, choose a policy for each severity class of vulnerability. Severity is determined by the CVSS score of the vulnerability. You can choose different policies for Critical, High, Medium, and Low severity, as well as for vulnerabilities that do not have a CVSS score.
Vulnerabilities will be categorized by the highest available CVSS score for the vulnerability. CVSS scores are pulled from both NIST and GitHub where available.
Ignoring false positive vulnerabilities
Tidelift's partnered maintainers review all vulnerabilities that affect their projects. Occasionally, vulnerabilities are false positives; they may have been filed in error by an AI tool, they may not actually be exploitable, or they may be a normal bug without any security impact.
You can configure the vulnerability standard to ignore false positive issues. When this is enabled, vulnerabilities that have been confirmed by the maintainer to be false positives will be ignored when denying releases or creating tasks to review, and no violations will be created, shown, or reported on for releases for that vulnerability.
What happens if a package release in my catalog doesn’t meet this standard?
When Tidelift learns about a new security vulnerability on an already-approved package release, it will check the severity of the vulnerability, and match it against your policy. If the policy is to deny usage, the approved release will be denied. If the policy is also to create a task for review, a task will be created for the catalog manager to review the vulnerability and where it is present in your software.
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 "Create a task". A task to review whether you'd like to deny this request is then created. Unless "Allow the use of releases ... " is checked, the release would be automatically denied as well.
Managing overrides
You may want to allow something that the vulnerability standard has not allowed. For example, this could be in an internal application that can't be accessed by an attacker, or it's something you aren't prioritizing right now.
To do so, see Creating Overrides.
All projects violation report
You can also get vulnerability information from the all projects violation report.