Enterprise users are risk averse, so knowing your packages comply with the Tidelift security requirements gives them added confidence when they are choosing packages and when responding to new vulnerabilities that may arise in the future.
Tell us about historical vulnerabilities
We keep a database of vulnerabilities along with affected package versions. If you've had any security vulnerabilities in the past, when you start lifting your package, we have you tell us about them—there's a place to do this on the lifter dashboard.
We use this information to notify subscribers if they're using any affected versions of your package.
Create a coordinated disclosure plan
A discoverable vulnerability-reporting policy, or coordinated disclosure plan, helps ensure that you will be notified of vulnerability reports for your project before they are made public. This reduces the risk that subscribers will be exploited by a publicly disclosed vulnerability before the fix is issued and applied, so we need you to let us know how security reports will be handled for your project.
There are two elements of this:
- By agreeing to lift your package, you agree that you'll follow responsible disclosure practices.
- If someone reports a vulnerability to you, actually use a responsible disclosure process.
If your project already has a security policy or you'd like to handle it on your own, just point us to the URL for the policy. If you'd prefer, you can use the Tidelift security policy and we'll help coordinate the fix and disclosure. We'll walk you through this on the lifter dashboard when you start lifting a package.
If you're creating your own process, these projects with mature, detailed security policies might be interesting to see how other projects handle security bugs:
Detecting policies on GitHub repositories
We take advantage of GitHub's community health repository and
SECURITY.md file to autodetect if you want to use Tidelift's process, or if you've set up a process already for another package and want to reuse that.
To automatically use Tidelift's plan, add
https://tidelift.com/securityto one of the three files we check (community repo's
SECURITY.md, or repo's
README) and, once we detect it, we'll send you an email with what we detected and a link back to the task to tweak it if needed.
If you've set up a custom policy URL with another package in the same GitHub organization and want to reuse that URL, place that policy URL into one of the security files in the other repository and, once detected, we'll send you an email. Remember, you'll have to have set up at least one other package's coordinated disclosure plan manually for this to work.
Security maintenance plan
With this task, we ask you to identify which release streams you’ll be willing to provide security updates for. Please note that this task specifically is only currently asking about security updates. It does not relate to bug fixes, new features, or anything else that may fall under the “support” umbrella.
A few things to consider when completing this task:
- There are three security update plan options:
- you’ll provide security fixes on a given release stream for all users
- you’ll only provide a fix on that stream if paying Tidelift subscribers are using it
- you won’t provide any fixes on that stream
- Use the “End of life date” feature to indicate that you will stop “supporting” a release stream on a given date.
- If you wish to only provide security updates on the latest release, you can check the “Only provide security updates for the latest release stream” checkbox at the top, and that will automatically update your “recommended version” to your latest release upon each subsequent release of your package.
- If you’d like to assign up policies in batches, you can do that by selecting the check boxes or drop down, then selecting the relevant release streams. You can then select the “update level” and apply the update plan for all of those release streams at once.
Agree to be responsive to security issues
You are expected to be responsive around security issues and work to resolve them. Not all reported issues are severe (or even real), but it's important to assess each one and respond.
We aren't imposing a firm time limit or deadline, because we feel it wouldn't be viable for smaller projects, at least not without more support from Tidelift. However, please put security issues at the front of your priority queue.
Tell us about new vulnerabilities
If you're handling a responsible disclosure yourself, please enter the new vulnerability into the lifter dashboard when it becomes public. We'll then notify any affected subscribers.
Set up two-factor authentication
Avoid unauthorized package publication and ensure safer installs by setting up two-factor authentication for your project. Subscribers will know the dependencies they install haven't been tampered with by a compromised account.
We will provide instructions for setting this up based for your package manager. If you already have this set up, just let us know and we'll confirm.
In particular, if applicable:
- Enable 2-factor auth on GitHub, GitLab or Bitbucket.
- Enable 2-factor auth for package publishing
For services which do not have 2-factor authentication, please use a strong password unique to each service (most people do this via a password manager).