Snyk vulnerability disclosure program: what’s going on behind the scenes?

At Snyk we firmly believe in keeping the open source community secure. This is why we launched our responsible vulnerability disclosure program, supporting all vulnerabilities found within managed open source packages and in languages including Javascript, Java, Python, .NET, Go, Ruby, and PHP.

Why disclose vulnerabilities with Snyk?

With our vulnerability disclosure practice at Snyk, we aim to bridge the gap between researchers and maintainers and try to alleviate some of the challenges and pain points associated with responsible disclosures, as we discussed in a previous blog.

So, how do we bridge that gap? When a new vulnerability is reported to Snyk, it gets sent directly to the security team to triage and verify the report. As a dev-first company, we believe in an approach that also takes the maintainers’ point-of-view into consideration. We engage in an open, mutual discussion from start to finish (in accordance with our vulnerability disclosure policy). We aim to hear both perspectives, ultimately reaching a decision that will be both accepted by the maintainer and is also the most responsible one, based on our experience and expertise while trying to take into account all factors — for example, package context, severity, probability of exploitation, and more.

Snyk is also a CNA (CVE Numbering Authority) and we, therefore, have the option to assign CVE IDs to issues reported to us. Once a fix has been released (or alternatively, if no reply has been received within 50 days), we move on to assigning the issue a CVE ID and publishing a public advisory. Having a CVE assigned for a vulnerability is crucial as it means that the entire ecosystem is made aware of the issue and developers and organizations are able to act accordingly to secure their code.

Throughout the process, we make sure to provide periodic updates to the person who has initially reported the vulnerability, and more importantly, they get credited for their valuable finding.

So far, our vulnerability program has responsibly disclosed 88 vulnerabilities from various external researchers. Let’s have a look at one such case.

Case study: partnership with Johns Hopkins University

Recently, we worked with researchers from Johns Hopkins University on a large-scale disclosure of 57 vulnerabilities.

As part of their thesis, the team at Johns Hopkins University came up with a revolutionary way to automate the finding of vulnerabilities:

"We propose a novel concept, called Object Property Graph (OPG), to capture the interplays of JavaScript objects and facilitate the detection of JavaScript vulnerabilities. An OPG represents all the object name information such as variable names and properties, object scopes, and objects themselves as nodes in a graph-like structure so that one can traverse the graph to resolve an object during execution. There are two major types of utilities of OPG: (i) facilitating the construction of a better, i.e., more accurate, CFG and DFG, when encountering an unknown object resolution, and (ii) providing interplays of objects so that one can query the interplays for certain vulnerability patterns.

We designed and implemented a framework, called OPGen, to generate OPG for Node.js applications during a so-called simulated execution. And we applied OPGen to detect four types of Node.js vulnerabilities, namely command injection, prototype pollution, arbitrary code execution, and path traversal.

On top of CPG, (code property graph), we add the object nodes and related edges. To do that, we do a simulation run of the code and check if there is any data flow that starts from the user input and can reach the sink functions."

- Song Li, JHU Security Labs

The team then reached out to us using the vulnerability disclosure form. We then replied back with an invitation to hold a video call to discuss the nature of the findings, the scale, and how we can support them.

Once we had an understanding of the magnitude of the disclosure, we proceeded to open a shared, private repository, where the team would add new findings. The team provided us with the vulnerability type, the package and version(s) affected, a POC, and a pointer to the vulnerable code. All in a unique format that is fed into a custom-made pipeline for our internal systems which helped us deal with the magnitude of the disclosure effectively.

Using an internal tool we created, we verified the relevant POCs, then proceeded to fully triage and work with the relevant maintainers to disclose the vulnerability responsibly.

To date, we’ve published over 55 vulnerabilities from said partnership with vulnerability types including Command Injection, Path Traversal, Prototype Pollution, and Code Execution. Some examples include SNYK-JS-BLAMER-559541, SNYK-JS-BODYMEN-548897, and SNYK-JS-PULVERIZR-560122.

We are continuing to work closely with the team at JHU Security Labs on new findings, as well as yet-to-be-published vulnerabilities.

How to get started?

An important first step is reading our vulnerability disclosure policy.

Once you have done that, the preferred way to submit a report is to use the dedicated disclosure form.

Please include as much information as possible, namely:

• description of the issue

• steps to reproduce (or a proof-of-concept)

• contact details — so we know who to credit and reach out to in case we need more information.

Alternatively, you can also email us at report@snyk.io Once again, please make sure to include as much information as possible.