Disclosure of a vulnerability in an open-source package
Through the program described on this page, Snyk encourages the community to report potential vulnerabilities in open-source packages, facilitating quick identification, validation, and remediation to enhance security.
Snyk values the security community and believes that responsible disclosure of security vulnerabilities in open-source packages helps us ensure the security and privacy of our users. Snyk aims to provide a disclosure program for the security community by which you can report security issues found within managed open-source code.
The Snyk responsible disclosure program aims to protect both the maintainer and the reporting researcher, allowing maintainers and developers who use open-source code to safely benefit from the discovery of these vulnerabilities prior to public disclosure, and crediting those researchers for their dedication.
Snyk's vulnerability disclosure program
The primary steps of the Snyk vulnerability disclosure program are:
Any researcher or developer is invited to submit a report regarding an open-source security vulnerability with full details.
The Snyk Security team validates the claims in the report and the severity of the associated risks. See Triaging and validation for details.
Snyk contacts the owner or maintainer of the affected Project through multiple channels. See Notification of the package maintainer for details.
Snyk relays the vulnerability details, advises on potential fixes, and collaborates on a public disclosure timeline with the maintainer. See Fix assistance for details.
Snyk publicly discloses the vulnerability, giving full credit to the researcher. See Public disclosure for details.
Snyk, as an officially recognized CVE Central Naming Authority (CNA), assigns a CVE to the vulnerability.
Reporting vulnerabilities to Snyk
Vulnerability reports can be submitted by a researcher to report@snyk.io directly or by using the Snyk Vulnerability Disclosure form: https://snyk.io/vulnerability-disclosure/. A submitted vulnerability report should contain the following details at minimum:
affected module
relevant package manager and ecosystem
vulnerability details
steps to reproduce
Upon receipt of the report, Snyk validates and documents each reported vulnerability prior to notifying the maintainer.
Vulnerability disclosures sent to Snyk by email can also be encrypted using the following PGP key:
Triaging and validation
After validating a submitted vulnerability report, an analyst contacts the submitter, using the contact details attached to the report, to acknowledge receipt of the report and to discuss vulnerability details as well as the severity the analyst has assigned.
If the submitted vulnerability was already publicly disclosed and is missing from the Snyk vulnerability database, then, once validated by Snyk, this vulnerability will be added and published in the database.
Notification of the package maintainer
Upon successful validation of a submitted vulnerability, Snyk contacts the maintainer of the package to provide vulnerability details needed to begin any internal resolution process.
Snyk follows a 90-day responsible disclosure and fix timeline, allowing the maintainer of the affected package to ensure a fix is available prior to the vulnerability's being made public. An extension can be provided at the maintainer’s request, and depending on the severity of the disclosed vulnerability, Snyk is happy to wait for public disclosure until a patch is made available.
After 30 days
If the maintainer does not acknowledge or reply to the initial disclosure email within 30 business days of the original notification, Snyk retransmits the vulnerability details to the original point of contact of the affected package and at least one secondary contact if a secondary contact is publicly available.
After 40 days
If an additional ten business days elapse with no response from the maintainer after the second notification (a total of 40 business days), vulnerability details are re-sent not only to the previous two contacts, but also to customers and other affected stakeholders at the discretion of Snyk.
After 50 days
If the package maintainer does not respond to any of the three notification attempts within an additional ten business days following the third notification (50 business days after the original notification), or if the maintainer indicates they do not wish to coordinate disclosure, Snyk may elect to issue a public advisory with no further collaboration.
Acknowledging receipt
Maintainers should acknowledge receipt of the notification with the following details:
Confirmation that the vulnerability information has been received
The scheduled timeline for an investigation.
A point of contact responsible for coordinating and tracking information on the issue from within their organization.
An estimate of when they expect to complete their initial investigation of the security issue as provided in the notification.
Fix assistance
After the maintainer acknowledges receipt of the notification, Snyk works with the maintainer to determine how to handle the security issue within ten business days. The following tasks are included in this phase:
Snyk is happy to provide additional information to assist the maintainer in the development of a solution.
The maintainer and Snyk collaborate to time public disclosure and fix of the issue.
Public disclosure
As part of the public disclosure phase, Snyk:
Assigns a Common Vulnerabilities and Exposures (CVE) ID for public tracking
Adds the vulnerability to its public vulnerability database, providing information about the vulnerability and the related fix
Public disclosure may be initiated either by completing the fix assistance phase or through a process failure in prior phases.
During the public disclosure phase, Snyk, and preferably the maintainer, disseminate information about the vulnerability and the fix to the public. Snyk may disseminate information through public email lists, web pages, or any other medium it deems appropriate to reach the intended audiences.
Last updated