Documentation

Security

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:

  • Monitoring other vulnerability databases, such as CVEs from NVD and many others.
  • Monitoring user activity on GitHub, including issues, PRs and commit messages that may indicate a vulnerability.
  • Bulk research, using tools that look for repeated security mistakes across open source package code
  • 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. We also accept pull requests!

Currently patches are unavailable for Ruby projects.

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 report@snyk.io. 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 organization.
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 report@snyk.io, 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:

-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFmR918BEADrS77g30ejwt+ecbqJax4ZIBzQC6KSJxbuZ2slEDYdB2aDFj0G
bYhj685q7so6VXzko7weJKzfpbttaaFDPznx752T2nbPdh/ci0HFdbzPHvEBcmIK
aoJAWhiTICT7ys+sdzEXQbtGqsNltExD+ylqws6ovRf1wWA1oCLMLy2/wGl3n67p
jNW2ZkF/5Ke/GOfAM6CCdadUVHx+2d9dYhMrMuatBdhkOZMlOqAI1yvTXNAbE7mJ
mB5c4EfiC0ARiDl785yNgu8e+ONSZDqYaqiDKDen1JdUA0/qgU1E0cT/9rM96UhE
WkKlXMHwWLxA9CBU1dkFEukWwwaXDBpm0Zbx/1RaYc8M/s3yGH9TDbfMHSQ/qebK
oRXOCQjuXUU4JlnnFc9SPzquBdZSHBhF9mSEwR55CmQVZhxeyGJMfeZIbyD5u8dr
hfWQ9MiWY2qH5XUr++6PJJnGWlkYTxXJGgic/gTwstfIHGtizLN/SEZ0hmquX40t
mcqM1/P3PIMRYYx8lw0D+8w8Wm2QJyzIOnRlJhSEsBBl8FNvxIuaO7EjdABRZFba
rfah6bnUIKZeIUdLJuO0l2ki9eIKbP3ASI4mQ94HE0riIVtEhvCtqs/woiws55t0
0y/1QBHk1BlmOGYcHynG3GlxHcCSlWzazLiAGE2g+aF5ZhDfdWy3Row99QARAQAB
tCZTbnlrJ3MgRGlzY2xvc3VyZSBOZXcgPHJlcG9ydEBzbnlrLmlvPokCPQQTAQoA
JwUCWZH3XwIbAwUJB4YfgAULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRB9qLDN
W73LHgFCD/9iOZsBHjVPHGZ/audEe2IwEfCpRM+ZM3SAvmGB31A0Vg7X+g1a+ZcZ
3nOTXGBdKHk66xYJ0H0C0iLamziwJvJpgOQqhgSews4qaJyJMaTyZkuabdRiscks
Dp9AL1nsEAPrA0y9Ny3sjeUSCRL8/ZZ0Thy2TfPhMonuyLwkEpQQB+mup8qWHf4Q
jVQvtXab3BPCyl33Ci1fsYirfAnh2HKZzb83cUcexKU7YSFTeA8wcBr7HBo4mZeO
5IfmhuZRplb/1hkoSwWTLMggmjaY338R7m36xuSUF818TaReLcHtzZcl+Rwb36VJ
zSKiYx+S69llpVR5Wh3weTwligBfaH/3gE/lf790Gv0fIy9UblfAa2lODqdyAuwW
l79XsBBt399KNnfKcGtR/S0rKt4iU0DwZOGel239301DUmoPbCo4PLWuv2GRfXBk
NSoSlwJkIJcEhM7RBaZc76CNyioTU/W8oYOnhzrgbE3xqiS1+s//lh3H42FsvJnP
8Yc3UGv4LhEP/BN9h9w5mYkcvX6o8Blg8fMNRlU8UP3RWBLDrm6Epdvj73pP6ifR
iZof1wJeAbqXf5gKQjKX8jEqgquTSB2IJQPXtzNn2lpjMWMdmWUbWwVQ5i2/LrBt
dxgfuOpLAfJs/gjbhgJCaA8L7KCdCTyiZUrOke2N7XOR53ttRB7uwLkCDQRZkfdf
ARAA3iatkrY3yrgnbp59MMQyyHSG/kpyTUfBOqvnP9haBPh8iyMXqHnJoD2grCIg
9Z9glhIT5o1sl8OmjcWwtpSBYBs63bM84r0b+S+/RtyvHsaJoRxjiWe8wsVwC0Dd
cUWpvvVpLT1AKi0Mx0IuNt9cvaGQjhKje3sGZ76TqrTUes32ABOOR48iFNbYuLgS
UaUw/Sw4gv0okixl5EJRZKhYtjBEcQybxWk0In1FcuVaQrQrbSqMmXGgtaDWYJ+M
gCUw+n3QjGaDszFlDcDOoRTl+lMj8Zx5+c9jbji11o3eQ+mI/oy3lrx2gX7XdUW3
wCcQG3fdjfCtLnEyIUjtUJMDP3mwNmyyE65Rzb4rD7bQ4A9uG+UGW0LfBh+nqFS4
imHVIAuhETP++ITQ7AcLadVPRjlRSpFQ/X5PG8wXrbsGKfEiQYKcYnD78NZji8sD
Gnbazvf5DY8sM10bdM+7+m/eY7dtCGQhA8N/QlN5SBBhVTbIgZY6MTXs6RTupiF9
NJrKltWPDcVPISwXPi7n9T7GHFYiaQCo9zePAwGU8craJVvOpHwUFAQHjmxv5EV5
8mOXPFPjvdUfAMmn4ngPU1YccjiQVnsxfeVTSCzfblctkUZ8qnaifwiS7HaK3d9Z
SeT/5dPikCH/d1aZ6fYmh4+AwdBPM76SeeJUHdCd8NHEov0AEQEAAYkCJQQYAQoA
DwUCWZH3XwIbDAUJB4YfgAAKCRB9qLDNW73LHqdcD/936EqsLwZ5QIOozjubK0ma
/aNKRYImAM5C46YJZ+Fkl/Y42Qey3Tgrr7Su+sUKlJlgPWbDlA2fsoV9kjVmK98z
JvrWUovxFmR3c63m0zWFHaDKmpExzTmz4SCuxS+5BY8qh4BucF/JdFulUGwfoTax
PYPJi2OoEM3KE3DJoNIC7l6UeSyMWhnTrvDWESWJL1ES2fIAxpr68Wjpz4aPRLpP
GVqupAYhjSW3hdkkUmzspM+pNSyLguBD/on8qs2l7c/vXx3nWPGPfqFbcuxOwFND
ar3k4iIXKZ/O78o6p+kAjsmEMtPDkOe1GmUnyKEm1zH0/OXGd0q8s6R9FZ7KgVtc
Ad52OmkopgktPrEGokNU57uv8KXqSEcQMCdHFTly8MWuCBdgoAzRgXFnbrLSVNxU
UBW6rFlqh1+npFbVAoPmi8mbv4w8Af1bi1HGQexDUjpB80P84cgzOQwgjNARU0v/
3IO0ErkyoFwUnig+lpKRBYX6y7xZm/GJAdo/w5f3mqIlr5G0RMwVh5yi5F2/8Lpx
YFu06/0/Ssh/vsOp6PeAfWctzdVR69uZbXN/CkCXyVeKBy8lKc2jsYsJPTL8Hqlu
4tOgNB/sgzJ2IRaMZOA9WOjpUInH/iShW5Nj6uozCWc2GjHVc8NTJ6uVA2hMR36i
V7JD6Yv5YR5K0Wf9MsSHZA==
=6Uz+
-----END PGP PUBLIC KEY BLOCK-----

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

  • 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:
  • Adhere to our Responsible Disclosure Policy (see above).
  • 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).
  • We specifically exclude certain types of potential security issues; these are listed under “Ineligible Reports and False Positives” (see below).
  • Submit your report to security@snyk.io (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.
  • 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.
  • Use test accounts and the dedicated bug bounty server (beemo.snyk.io) when investigating issues.

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

  • We investigate and respond to all valid reports. Due to the volume of reports we receive, though, we prioritize evaluations based on risk and other factors, and it may take some time before you receive a reply.
  • 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.
  • 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.
  • 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.
  • You may donate a bounty to a recognized charity (subject to approval by Snyk), and we double bounty amounts that are donated in this way.
  • We reserve the right to publish reports (and accompanying updates).
  • 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:

  • Snyk’s web site (dedicated host for the program is: https://beemo.snyk.io)
  • Snyk’s Command Line Interface (CLI) npm package https://github.com/Snyk/snyk
  • Snyk’s Broker component https://github.com/Snyk/broker

Out of Scope

  • Spam or social engineering techniques.
  • Denial-of-service attacks.
  • 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.