Had enough of the zero-day exploit and fire drill?

Yeah, there will always be more.

But there's a simple issue making this worse: 80% of open source projects have no vulnerability disclosure policy in place—meaning there's no obvious way to report a security issue other than filing a public report on GitHub. Moreover, many maintainers are unaware of coordinated vulnerability disclosure practices, and therefore don't follow them.

Result: the zero-day exploit and fire drill.

How can you improve this for the software you use? It needs to be fixed upstream, in the original open source project that will receive vulnerability reports.

We recently shipped a feature to address this for the packages our subscribers use. Here's how it works.

Background on the Tidelift Subscription

A refresher if you aren't familiar with our subscription:

• Through a simple CI or GitHub integration, we know the manifest of dependencies you rely on.

• We tell you about known issues in those dependencies (including security, licensing, and maintenance problems).

• But most importantly: we get to work proactively preventing issues with those dependencies.

To proactively improve your dependencies we reach out to the projects you rely on and sign up their maintainers as lifters. Lifters commit to a set of tasks and guidelines for their project, intended to eliminate common headaches faced by professional teams that rely on open source. We use a big slice of your subscription dollars to pay the upstream project to get problems addressed proactively at the source.

If you've heard of the "shift left" principle (solving problems as early in the development lifecycle as possible), this is the ultimate version of it: solving problems before your team even sees them!

A coordinated disclosure policy for every lifted package

With this latest feature, we set out to be sure our lifted packages all have a way to report vulnerabilities privately, and knowledge of how to handle any reported vulnerabilities. This isn't rocket science, but 80% of projects don't do it—so let's get that cleaned up.

We want to educate upstream projects that aren't familiar with responsible disclosure, and give them the tools to make it easy to implement.

We ask all lifted projects to have a vulnerability reporting and handling process. To make this easy, we give them the option to use a pre-built reporting page and a process managed by Tidelift; or they can choose to use their own process. In either case, they're required to link to their reporting instructions and process in their README. Here's what it looks like for lifters:

If the project opts in to the Tidelift-managed process, they'll link to our reporting page.

Security matters for every package

Sometimes we hear people say that their application isn't Internet-facing or otherwise isn't security-critical, so they don't worry about vulnerabilities.

Here's the problem: not all vulnerabilities are remote exploits. In the recent event-stream incident, a seemingly innocuous npm package had a trojan intended to steal passwords from workstations installing the package. This can happen to any package. If you're going to put the code on your developers' laptops or on your servers, then it is security-sensitive code!

Coordinated disclosure isn't all we do

This new coordinated disclosure feature gives our subscribers another layer of protection, but it isn't all we do around security. Critical other steps include:

• Telling subscribers about any known vulnerabilities in their dependencies.

• Requiring our lifters to set up two-factor authentication.

• Requiring our lifters to notify us of any vulnerabilities (we've already discovered through this requirement that some past vulnerabilities never made it into official channels or had a CVE number).

• Keeping maintainers around by paying them. In his statement on the event-stream incident, Dominic Tarr mentions this as a critical part of the solution. No maintainer means no security process.

Let us go to work for you

If this all sounds interesting to you, here are some things you can do right now:

• Learn more about the Tidelift Subscription or request a demo

• Get an open source assessment to help you understand your open source dependencies better

• Download the definitive guide to professional open source