Responsible disclosure: the impact of vulnerability disclosure on open source security

It’s a common mistake to think that once a vulnerability is found, the responsible thing would be to make it widely known as soon as possible. The truth is quite the opposite.

Responsible vulnerability disclosure is a disclosure model commonly used in the cybersecurity world where 0-day vulnerabilities are first disclosed privately, thus allowing code and application maintainers enough time to issue a fix or a patch before the vulnerability is finally made public. Otherwise, we would have sacrificed the security of the end-users. As always, balance is the key — the aim is to minimize both the time the vulnerability is kept private, but also the time the application remains vulnerable without a fix.

This model has been around for years. It’s very common to find software companies providing a disclosure policy document that details their own responsible disclosure process —  explaining what they do in case someone finds a vulnerability in their application. However, in the world of open source, things work a little differently.

Challenges of following a responsible disclosure process

It’s really exciting to find a new vulnerability. It’s understandable that researchers want to publish their work as quickly as possible and move on to the next challenge. However, more often than not, this process is inconvenient:

• Official disclosure policies do not always exist when it comes to open source packages.

• Even if there is a policy, it usually differs from package to package.

• The process tends to be long, complicated, and there are multiple steps involved.

• Other steps may involve assigning a CVE ID which, without a median authority — also known as a CNA (CVE Numbering Authority) — can be a pretty tedious task.

These are some of the reasons that a lot of researchers do not follow a responsible or coordinated disclosure process these days. The “easy” alternative is disclosing these vulnerabilities publicly instead, creating a sense of urgency. Fixes pushed out in short timeframes and under pressure can often be incomplete, or buggy — leaving the vulnerability open, or opening new attack vectors in the package.

Why follow a proper vulnerability disclosure process?

Following a reasonable disclosure process allows maintainers to properly triage the vulnerability without a sense of urgency. Then, they can choose whether or not to assign a fix, and prepare any backports if necessary. Finally, once the new releases are out, they can safely disclose the vulnerability publicly to their users. During this whole process, the vulnerability details are kept private, which ensures it cannot be abused negatively.

Open source vulnerability disclosures at Snyk

Snyk launched its vulnerability disclosure program in 2019, with the aim to bridge the gap and provide an easy way for researchers to report vulnerabilities while, of course, fully crediting the researchers’ hard work for the discovery.

Our security team carefully triages each and every vulnerability report. This requires specific knowledge and understanding of both the language at hand, the package, and its context. Once the vulnerability details are verified, the team proceeds to work hand-in-hand with maintainers to get the vulnerability fixed in a timely manner. Finally, as a CNA (CVE Numbering Authority), we assist with assigning the issue a CVE ID and publishing a detailed advisory.

In 2019, we have helped disclose over 130 vulnerabilities. Some notable ones are RCE in mongo-express and Arbitrary File Write in yarn.

We have worked with both independent researchers, security personnel, and the academic community! We kicked off 2020 with a big partnership with the Johns Hopkins University Security Lab team, where we helped them disclose over 50 vulnerabilities.

The team at Johns Hopkins University came up with a new way to automate finding new vulnerabilities. Together, we built a custom-made solution to help deal with a large number of vulnerabilities. Stay tuned for an upcoming article that will dig deeper into the specifics of this project.

How to get started?

The preferred way to submit a report is to use the dedicated form here. Alternatively, you can also email us at report@snyk.io. Please make sure to review our vulnerability disclosure policy before submitting a report.