Snyk Documentation


How Snyk finds out about new vulnerabilities

Snyk’s security team, based in Israel, maintains our vulnerability database.
This work includes curating vulnerabilities found or reported elsewhere on the web, as well as doing our own research to uncover previously unknown vulnerabilities, which we then responsibly disclose. Snyk Enterprise get early notifications for issues our research uncovers alongside this responsible disclosure process.
Most of the vulnerabilities in our database originate from one of these sources:

  1. Monitoring other vulnerability databases, such as CVEs from NVD and many others.
  2. Monitoring user activity on GitHub, including issues, PRs and commit messages that may indicate a vulnerability.
  3. Bulk research, using tools that look for repeated security mistakes across open source package code
  4. Manual research, investing our researchers time to manually audit more widely used packages for security flaws.

For every issue deemed to be a real vulnerability, we assign the right CVSS (severity) score and package version specification, create an advisory, and make it available in the product.

Snyk’s process for creating patches

Patches are created and maintained by Snyk. If the package owner has made code changes to fix the issues, our patch is based on this official fix, and we remove any cosmetic or unrelated changes. If a package owner has not addressed the vulnerability yet, we write a patch from scratch.
Before releasing it, we verify the patch, backport it to older versions, and test that the patch hasn’t broken functionality.

The patches are a part of Snyk’s open source vulnerability database, so you can check them out before applying them. For example, the patches for the ms ReDoS vulnerability. We don’t have patches for every case - if you need one that’s missing, let us know.

Open Source Packages Disclosure policy

We at snyk value the security community and believe that responsible disclosure of security vulnerabilities in open source packages helps us ensure the security and privacy of the users. ​ A responsible disclosure program includes a policy with clear and simple rules of engagement for security researchers to report vulnerabilities they discover. It protects both the developer and researcher, while allowing developers to safely benefit from vulnerabilities discovered by researchers. ​ Security vulnerabilities can be reported to us, and we will manage the responsible disclosure procedure, (1) receiving the report, (2) notifying the developer, (3) coordinating the fix and (4) publicly disclosing the vulnerability giving full credit to the researcher.

1. Report

Receiving the submitted vulnerability report from the researcher/reporter, sent to Snyk will verify and document each reported vulnerability prior to developer notification.

2. Developer Notification

The first phase of the public disclosure process, with a goal to provide vulnerability details necessary for the developer to begin their internal resolution process.

If the developer has not acknowledged receipt within 30 business days of the original notification, Snyk will retransmit the vulnerability details to the original contact and at least one secondary contact, if a secondary contact is publicly available. If the developer allows an additional ten business days to elapse following the second notification (40 business days since original notification) without acknowledging the information, vulnerability details will be re-sent not only to the previous two contacts, but also to customers or other stakeholders at Snyk’s discretion.

If the product developer does not respond to any of the three notification attempts within an additional ten days following the third notification (50 business days since original notification), or if the developer indicates they do not wish to coordinate disclosure, Snyk may elect to issue a public advisory (Step 4).
Acknowledgement of the notification by the developer should include all of the following items:

a. developer confirms the vulnerability information is received and the schedule for investigation.
b. developer provides a point of contact responsible for coordinating and tracking information on the issue from within their org.
c. developer provides an estimate as to when they expect to complete their initial investigation of the security issue provided in the notification.

3. Developer Coordination

Upon successful acknowledgement of the notification, Snyk will work with the developer to determine how the security issue will be addressed. The following tasks are included within this phase:
a. At developer’s request, Snyk will provide additional information to assist in the development of a solution.
b. At developer’s request, Snyk may review proposed solutions for effectiveness.
c. The developer and Snyk will exchange proposed timing for public disclosure of the issue and related solution for mutual approval.
If developer responses to all communications in this phase are not received within ten business days, Snyk may move directly to the Public Disclosure phase.

4. Public disclosure

Public Disclosure is the final phase of the disclosure process. During this phase, Snyk’s intent is to add the vulnerability to its public database (vulndb), provide information on the vulnerability and related solutions. Public Disclosure may be initiated either by completing the Developer Coordination phase or through a process failure in prior phases.

During the Public Disclosure phase Snyk, and optimally the developer, will disseminate information on the vulnerability and related solution to the public. Snyk may disseminate information through public e-mail lists, web pages or any other medium it deems appropriate to reach the intended audiences.

5. PGP Key

As mentioned above, you can report issues simply by emailing us at, and a member of the Snyk team will review your confidential report.
If possible, we recommend you encrypt such vulnerability disclosures using the following PGP key:



Snyk's Vulnerability Disclosure Program

If you believe you have found a security vulnerability on Snyk, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem. Before reporting though, please review this page including our responsible disclosure policy, reward guidelines, and those things that should not be reported.

Responsible Disclosure Policy

  • If you comply with the policies below when reporting a security issue to Snyk, we will not initiate a lawsuit or law enforcement investigation against you in response to your report. We ask that: a) You give us reasonable time to investigate and mitigate an issue you report before making public any information about the report or sharing such information with others. b) You do not interact with an individual account (which includes modifying or accessing data from the account) if the account owner has not consented to such actions. c) You make a good faith effort to avoid privacy violations and disruptions to others, including (but not limited to) destruction of data and interruption or degradation of our services. d) You do not exploit a security issue you discover for any reason. (This includes demonstrating additional risk, such as attempted compromise of sensitive company data or probing for additional issues). You do not violate any other applicable laws or regulations.


Bug Bounty Program Terms


  1. We recognize and reward security researchers who help us keep people safe by reporting vulnerabilities in our services. Monetary bounties for such reports are entirely at Snyk’s discretion, based on risk, impact, and other factors. To potentially qualify for a bounty, you first need to meet the following requirements:
  2. Adhere to our Responsible Disclosure Policy (see above).
  3. Report a security bug: that is, identify a vulnerability in our services or infrastructure which creates a security or privacy risk. (Note that Snyk ultimately determines the risk of an issue, and that many software bugs are not security issues).
  4. We specifically exclude certain types of potential security issues; these are listed under “Ineligible Reports and False Positives” (see below).
  5. Submit your report to (one issue per report) and respond to the report with any updates. Please do not contact employees directly or through other channels about a report.
  6. If you inadvertently cause a privacy violation or disruption (such as accessing account data, service configurations, or other confidential information) while investigating an issue, be sure to disclose this in your report.
  7. Use test accounts and the dedicated bug bounty server ( when investigating issues.

In turn, we will follow these guidelines when evaluating reports under our bug bounty program:

  1. We investigate and respond to all valid reports. Due to the volume of reports we receive, though, we prioritise evaluations based on risk and other factors, and it may take some time before you receive a reply.
  2. We determine bounty amounts based on a variety of factors, including (but not limited to) impact, ease of exploitation, and quality of the report. If we pay a bounty, the minimum reward is $20 USD. Note that extremely low-risk issues may not qualify for a bounty at all.
  3. We seek to pay similar amounts for similar issues, but bounty amounts and qualifying issues may change with time. Past rewards do not necessarily guarantee similar results in the future.
  4. In the event of duplicate reports, we award a bounty to the first person to submit an issue. (Snyk determines duplicates and may not share details on the other reports.) A given bounty is only paid to one individual.
  5. You may donate a bounty to a recognised charity (subject to approval by Snyk), and we double bounty amounts that are donated in this way.
  6. We reserve the right to publish reports (and accompanying updates).
  7. We verify that all bounty awards are permitted by applicable laws, including (but not limited to) US trade sanctions and economic restrictions.

Note that your use of Snyk services, including for purposes of this program, is subject to Snyk’s Terms and Policies. We may retain any communications about security issues you report for as long as we deem necessary for program purposes, and we may cancel or modify this program at any time.

Bug Bounty Program Scope

To qualify for a bounty, report a security bug in one of the following qualifying products or components:

  1. Snyk’s web site (dedicated host for the program is:
  2. Snyk’s Command Line Interface (CLI) npm package
  3. Snyk’s Broker component


Out of Scope

  1. Spam or social engineering techniques.
  2. Denial-of-service attacks.
  3. Security issues in third-party apps or websites that integrate with Snyk. These are not managed by Snyk and do not qualify under our guidelines for security testing.