From d4d2cf1b7148895c8ce9a2d6ff35bf67f29b1391 Mon Sep 17 00:00:00 2001 From: Morgan Tocker Date: Tue, 3 Mar 2020 08:28:43 -0700 Subject: [PATCH 1/4] Add initial security policy Signed-off-by: Morgan Tocker --- README.md | 6 ++++ SECURITY.md | 93 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 99 insertions(+) create mode 100644 SECURITY.md diff --git a/README.md b/README.md index c541c544693..af1c4b89a1a 100644 --- a/README.md +++ b/README.md @@ -40,6 +40,12 @@ for low-frequency updates like new features and releases. ## Security +### Reporting Security Vulnerabilities + +To report a security vulnerability, please email [vitess-maintainers](mailto:cncf-vitess-maintainers@lists.cncf.io). + +See [Security](SECURITY.md) for a full outline of the security process. + ### Security Audit A third party security audit was performed by Cure53. You can see the full report [here](doc/VIT-01-report.pdf). diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000000..601608c6d80 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,93 @@ +# Security Release Process + +Vitess is a large growing community of volunteers, users, and vendors. The Vitess community has +adopted this security disclosure and response policy to ensure we responsibly handle critical +issues. + +## Maintainers Team + +Security vulnerabilities should be handled quickly and sometimes privately. The primary goal of this +process is to reduce the total time users are vulnerable to publicly known exploits. + +The Vitess [maintainers](MAINTAINERS.md) team is responsible for the entire response including internal communication and external disclosure. In the future, we may delagate responsibility to a sub-team as other projects have elected to do so. + +## Disclosures + +### Private Disclosure Processes + +The Vitess community asks that all suspected vulnerabilities be privately and responsibly disclosed via the [reporting policy](README.md#reporting-security-vulnerabilities). + +### Public Disclosure Processes + +If you know of a publicly disclosed security vulnerability please IMMEDIATELY email +[vitess-maintainers](mailto:cncf-vitess-maintainers@lists.cncf.io) to inform about the vulnerability so that we may start the patch, release, and communication process. + +## Patch, Release, and Public Communication + +For each vulnerability a member of the maintainers team will volunteer to lead coordination of the fix (Fix Lead), and ensure that it is backported to each supported branch. They will then coordinate with the remainder of the maintainers team to coordinate new releases and ensure a communication plan is in place for vulnerability disclosure. + +All of the timelines below are suggestions and assume a private disclosure. The Fix Lead drives the +schedule using their best judgment based on severity and development time. If the Fix Lead is +dealing with a public disclosure all timelines become ASAP (assuming the vulnerability has a CVSS +score >= 4; see below). If the fix relies on another upstream project's disclosure timeline, that +will adjust the process as well. We will work with the upstream project to fit their timeline and +best protect our users. + +#### Policy for master-only vulnerabilities + +If a security vulnerability only affects master, but not a stable release (i.e. Vitess 5) then the following process will apply: + +* The fix will land in master. +* A courtesy email will be sent to [vitess@googlegroups.com](https://groups.google.com/forum/#!forum/vitess) along with a posted notice in #developers on Slack. + +#### Policy for unsupported releases + +If a security vulnerability affects only a stable release which is no longer under active support, then the following process will apply: + +* A fix **will not** be issued (exceptions may be made for extreme circumstances) +* An email will be sent to [vitess-announce@googlegroups.com](https://groups.google.com/forum/#!forum/vitess-announce) identifying the threat, and encouraging users to upgrade. + +#### Policy for supported releases + +If a security vulnerability affects supported branches (i.e. Vitess 5), then a Fix Lead will be appointed and the full security process as defined below will apply. + +### Fix Development Process + +These steps should be completed within the 1-7 days of Disclosure. + +- The Fix Lead will create a + [CVSS](https://www.first.org/cvss/specification-document) using the [CVSS + Calculator](https://www.first.org/cvss/calculator/3.0). The Fix Lead makes the final call on the + calculated CVSS; it is better to move quickly than making the CVSS perfect. +- The Fix Lead will notify the maintainers that work on the fix branch is complete. Maintainers will review the fix branch in a private repo and provide require LGTMs. + +If the CVSS score is under 4.0 ([a low severity +score](https://www.first.org/cvss/specification-document#i5)) the maintainers can decide to slow the +release process down in the face of holidays, developer bandwidth, etc. + +### Fix Disclosure Process + +With the fix development underway, the Fix Lead needs to come up with an overall communication plan +for the wider community. This Disclosure process should begin after the Fix Lead has developed a Fix +or mitigation so that a realistic timeline can be communicated to users. + +**Disclosure of Forthcoming Fix to Users** (Completed within 1-7 days of Disclosure) + +- The Fix Lead will email [vitess-announce@googlegroups.com](https://groups.google.com/forum/#!forum/vitess-announce) + informing users that a security vulnerability has been disclosed and that a fix will be made + available at YYYY-MM-DD HH:MM UTC in the future via this list. This time is the Release Date. +- The Fix Lead will include any mitigating steps users can take until a fix is available. + +The communication to users should be actionable. They should know when to block time to apply +patches, understand exact mitigation steps, etc. + +**Disclosure of Fixed Vulnerability** + +- The Fix Lead will email [vitess-announce@googlegroups.com](https://groups.google.com/forum/#!forum/vitess-announce) + informing users that there are new releases available to address an identified vulnerability. +- As much as possible this email should be actionable and include links to CVEs, and how to apply + the fix to user's environments; this can include links to external distributor documentation. + +### Embargo Policy + +The Vitess team currently does not provide advance notice of undisclosed vulnerabilities to any third parties. We are open to feedback on what such a policy can or should look like. For the interim, the best way to receive advanced notice of undisclosed vulnerabilities is to apply to join the maintainers team. From 9597f6ad76de953115becf3c1804d1d8e4e28988 Mon Sep 17 00:00:00 2001 From: Morgan Tocker Date: Thu, 5 Mar 2020 16:11:11 -0700 Subject: [PATCH 2/4] PR Feedback Signed-off-by: Morgan Tocker --- SECURITY.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 601608c6d80..8720f50653a 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -9,7 +9,7 @@ issues. Security vulnerabilities should be handled quickly and sometimes privately. The primary goal of this process is to reduce the total time users are vulnerable to publicly known exploits. -The Vitess [maintainers](MAINTAINERS.md) team is responsible for the entire response including internal communication and external disclosure. In the future, we may delagate responsibility to a sub-team as other projects have elected to do so. +The Vitess [maintainers](MAINTAINERS.md) team is responsible for the entire response including internal communication and external disclosure. In the future, we may delegate responsibility to a sub-team as other projects have elected to do so. ## Disclosures @@ -20,11 +20,11 @@ The Vitess community asks that all suspected vulnerabilities be privately and re ### Public Disclosure Processes If you know of a publicly disclosed security vulnerability please IMMEDIATELY email -[vitess-maintainers](mailto:cncf-vitess-maintainers@lists.cncf.io) to inform about the vulnerability so that we may start the patch, release, and communication process. +[vitess-maintainers](mailto:cncf-vitess-maintainers@lists.cncf.io) so that we may start the patch, release, and communication process. ## Patch, Release, and Public Communication -For each vulnerability a member of the maintainers team will volunteer to lead coordination of the fix (Fix Lead), and ensure that it is backported to each supported branch. They will then coordinate with the remainder of the maintainers team to coordinate new releases and ensure a communication plan is in place for vulnerability disclosure. +For each reported vulnerability, a member of the maintainers team will volunteer to lead coordination of the fix (Fix Lead), and ensure that it is backported to each supported branch. They will then coordinate with the remainder of the maintainers team to coordinate new releases and ensure a communication plan is in place for vulnerability disclosure. All of the timelines below are suggestions and assume a private disclosure. The Fix Lead drives the schedule using their best judgment based on severity and development time. If the Fix Lead is From 3c84f08415bbfe6ef59dcf9bdf30c5f41966e4c2 Mon Sep 17 00:00:00 2001 From: Morgan Tocker Date: Thu, 5 Mar 2020 17:42:40 -0700 Subject: [PATCH 3/4] Add other related circumstances Signed-off-by: Morgan Tocker --- SECURITY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SECURITY.md b/SECURITY.md index 8720f50653a..d51899fb5f2 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -63,7 +63,7 @@ These steps should be completed within the 1-7 days of Disclosure. If the CVSS score is under 4.0 ([a low severity score](https://www.first.org/cvss/specification-document#i5)) the maintainers can decide to slow the -release process down in the face of holidays, developer bandwidth, etc. +release process down in the face of holidays, developer bandwidth and other related circumstances. ### Fix Disclosure Process From e29d8f1da20c3e26ff008e36e0a304f6e4a1f2af Mon Sep 17 00:00:00 2001 From: Morgan Tocker Date: Thu, 5 Mar 2020 17:51:45 -0700 Subject: [PATCH 4/4] Address feedback on stable versioning Signed-off-by: Morgan Tocker --- SECURITY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index d51899fb5f2..c524bdc11de 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -35,7 +35,7 @@ best protect our users. #### Policy for master-only vulnerabilities -If a security vulnerability only affects master, but not a stable release (i.e. Vitess 5) then the following process will apply: +If a security vulnerability affects master, but not a currently supported branch, then the following process will apply: * The fix will land in master. * A courtesy email will be sent to [vitess@googlegroups.com](https://groups.google.com/forum/#!forum/vitess) along with a posted notice in #developers on Slack. @@ -49,7 +49,7 @@ If a security vulnerability affects only a stable release which is no longer und #### Policy for supported releases -If a security vulnerability affects supported branches (i.e. Vitess 5), then a Fix Lead will be appointed and the full security process as defined below will apply. +If a security vulnerability affects supported branches, then a Fix Lead will be appointed and the full security process as defined below will apply. ### Fix Development Process