Reviewing security vulnerabilities
You can ensure that every requested and approved package release is reviewed for known vulnerabilities by enabling the ‘review security vulnerabilities’ standard. Tidelift is pro-actively reviewing these vulnerabilities in our security-advised catalogs, and we will share with you a recommended upgrade path and advice from the upstream maintainers. This lets your designated catalog administrator make an informed decision about whether to upgrade the package (ie. deny the vulnerable release and replace with a safer release) or ignore the vulnerability.
How do I set up security vulnerability review?
To ensure all security vulnerabilities are reviewed, turn on the Review security vulnerabilities standard from the Catalogs > Standards page.
By default, we will notify you about all security vulnerabilities in Tidelift’s Security Database (this includes vulnerabilities from the National Vulnerability Database and maintainer-provided information.) We can also integrate with vulnerabilities from other sources. Reach out to firstname.lastname@example.org for more information.
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 notify you with a task to review the new security vulnerability. When completing the task, you will be presented with additional guidance from the maintainers and Tidelift on how to handle the security vulnerability. You can choose to either Ignore the vulnerability or Upgrade the package.
By choosing to ignore the vulnerability, the release will stay approved in the catalog. A catalog administrator will be asked to provide a note describing why the vulnerability was safe to ignore.
By choosing to upgrade the package, the vulnerable release will be denied and developers will upgrade to a different (likely newer) release of the package. Tidelift will calculate the recommended upgrade path for all affected releases of a package, and will suggest the correct upgrades. When choosing to upgrade the package, the catalog administrator can choose to 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.
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 release.