From 723185b3e6ee790e34b246a036bbfe3987db06a4 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Thu, 1 Dec 2016 11:17:35 -0800 Subject: [PATCH 1/6] docs: devel: add security release process After the v1.4.3 release I know we are all thinking about the security disclosure and response plan for Kubernetes. I think we need to document some internal processes, external communication templates/process, and improve the disclosure systems. This document is based on discussion and a Google doc on SIG Auth: https://groups.google.com/forum/#!topic/kubernetes-sig-auth/Xq2f8bWCNDM **Known issues** - We haven't specified a way to cycle the Product Security Team; but we need this process deployed quickly as our current process isn't working. I will put a deadline of March 1st 2017 to sort that. Tracking issue: https://github.com/kubernetes/kubernetes/issues/35462 --- .../devel/security-release-process.md | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 contributors/devel/security-release-process.md diff --git a/contributors/devel/security-release-process.md b/contributors/devel/security-release-process.md new file mode 100644 index 000000000..c6d77313a --- /dev/null +++ b/contributors/devel/security-release-process.md @@ -0,0 +1,65 @@ +# Security Release Process + +Kubernetes is a large growing community of volunteers, users, and vendors. The Kubernetes community has adopted this security disclosures and response policy to ensure we responsibly handle critical issues. + +## Product Security Team (PST) + +By their nature security vulnerabilities should be handled quickly and sometimes privately. The Product Security Team is responsible for running the communication, disclosure, and CVE/patch processes. They are not solely responsible for fixing issues and can loop in necessary engineers to test and verify the fixes. + +The initial Product Security Team will consist of five volunteers who are all subscribed to the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list. These are the people who have been involved in the initial discussion and volunteered: + +- Brandon Philips [4096R/154343260542DF34] +- Jess Frazelle +- Eric Tune +- Jordan Liggitt +- Matthew Garrett [4096R/BE99F8F0AE90F416] (temporarily advising because he has been on boards like this in the past) + +**Known issues** + +- We haven't specified a way to cycle the Product Security Team; but we need this process deployed quickly as our current process isn't working. I (@philips) will put a deadline of March 1st 2017 to sort that. + +## Disclosures + +### Private Disclosure Processes + +We ask that suspected vulnerabilities should be responsibility disclosed via our disclosure process. Please visit [http://kubernetes.io/security](http://kubernetes.io/security] to learn more. + +### Public Disclosure Processes + +If a security issue has been publicly disclosed please IMMEDIATELY email [kubernetes-security@googlegroups.com](mailto:kubernetes-security@googlegroups.com) to inform the Product Security Team about the vulnerability and start the patch, release, and communication process. + +Next, ask the reporter if the issue can be handled via the private disclosure process. If the reporter denies it is best to proceed publicly and swiftly with the fix and release process. In extreme cases you can ask GitHub to delete the issue but this generally shouldn’t be necessary and is unlikely to make a public disclosure less damaging. + +## Patch, Release, and Public Communication + +- Request CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) (for embargoed issues) or [oss-security](http://www.openwall.com/lists/oss-security/) (for public issues) +- Set the issue priority based on rough criteria + - P0 - **Critical impact**, flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact. + - P1 - **Important impact**, flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service. + - P2 - **Moderate impact**, flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a Critical impact or Important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations. + - P3 - **Low Impact**, other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences. +- Invite relevant developers to have access to the private security fix repo. +- Work on a fix in a private repo, you can keep track of the issues on this repo as well. Put CVE number in commit and changelog. Please note although CVE is nice, code patch is nicer, better to move ahead without a CVE then to delay in waiting for a CVE. +- Make sure the CVE is mentioned in the commit log and changelog. Changelog for sure, commit log is a “nice to have”, also note situations where security have been fixed and not recognized as such until after the fact +- Apply the fixes to the release branch and any other release branches you will backport to + - Get LGTM on patches on the private repo + - **User disclosure** (1-5 days) + - Email kubernetes-announce@googlegroups.com informing users that a security vulnerability has been disclosed and that a fix will be made available at YYYY-MM-DD HH:MM in the future via this list. + - Communicate any mitigating steps they can take until a fix is available + - **Private distributors announce** (1-5 days): + - If the issue is Important or Critical email a patch to kubernetes-distributors-announce@googlegroups.com so distributors can prepare builds to be available to users on the day of the issue's announcement. Distributors can ask to be added to this list by emailing kubernetes-security@googlegroups.com and it is up to the Product Security Team's discretion to manage the list. + - **What if a vendor breaks embargo?** Sometimes could be small or big, just assess the damage and if you need to release earlier because of it, do that, otherwise continue with the plan. Generally speaking when that happens you just push forward and go public ASAP + - **On release day** + - Rebase the branch[es] with the fixes, including any other additional branches you applied or backported patches on, with the specific branch on the public repo you will eventually have this in, nothing should have changed upstream unless there were any public cherrypicks. + - Run the release on these branches (release branch, any additional backported release branches). + - Make sure all the binaries are up, publicly available, and functional. + - Open the patches in a PR on the public repo for each release branch you applied the patches to (1 PR per branch). + - Merge immediately (you cannot accept changes at this time, even for a typo in the CHANGELOG since it would change the git sha of the already built and published release[s]). + - Cherry-pick the same patches onto the master branch from the release branch. LGTM and merge. + - At this point everything is public. + - Email kubernetes-{dev,users,announce,etc}@googlegroups.com to get wide distribution and user action. + - Remove developers who developed the fix from the private security repo + + +[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/devel/security-release-process.md?pixel)]() + From 7af7d262e47298588831625e6e323ba35f77b46a Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Sun, 29 Jan 2017 10:12:23 -0800 Subject: [PATCH 2/6] security-release-process: remove mjg59 from PST mjg59 has changed his role and has requested to be removed from the responsiblity of the PST. --- contributors/devel/security-release-process.md | 1 - 1 file changed, 1 deletion(-) diff --git a/contributors/devel/security-release-process.md b/contributors/devel/security-release-process.md index c6d77313a..aa3fdd12d 100644 --- a/contributors/devel/security-release-process.md +++ b/contributors/devel/security-release-process.md @@ -12,7 +12,6 @@ The initial Product Security Team will consist of five volunteers who are all su - Jess Frazelle - Eric Tune - Jordan Liggitt -- Matthew Garrett [4096R/BE99F8F0AE90F416] (temporarily advising because he has been on boards like this in the past) **Known issues** From 347ed932129504e71a53a8bd2f7fd72ce1480d9b Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Sun, 29 Jan 2017 10:13:15 -0800 Subject: [PATCH 3/6] security-release-process: add release managers The release managers should be on the list as they are going to be the central point of coordination for testing, release, and communication. --- contributors/devel/security-release-process.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/contributors/devel/security-release-process.md b/contributors/devel/security-release-process.md index aa3fdd12d..6d62873f1 100644 --- a/contributors/devel/security-release-process.md +++ b/contributors/devel/security-release-process.md @@ -17,6 +17,12 @@ The initial Product Security Team will consist of five volunteers who are all su - We haven't specified a way to cycle the Product Security Team; but we need this process deployed quickly as our current process isn't working. I (@philips) will put a deadline of March 1st 2017 to sort that. +## Release Manager Role + +ALso included on the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list are all [Release Managers](https://github.com/kubernetes/community/wiki). + +It is the responsbility of the Product Security Team to add new Release Managers and remove Release Managers as Kubernetes minor releases are deprecated. + ## Disclosures ### Private Disclosure Processes From 9d0b5f7409596e0518e7c96c88cab6253d7a2c01 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Sun, 29 Jan 2017 11:38:15 -0800 Subject: [PATCH 4/6] security-release-process: cleanup the overall process Make the language much easier to read from beginning to end. And make everyone's role easier to understand by giving people explicit role names. --- .../devel/security-release-process.md | 97 ++++++++++++------- 1 file changed, 63 insertions(+), 34 deletions(-) diff --git a/contributors/devel/security-release-process.md b/contributors/devel/security-release-process.md index 6d62873f1..f1c54fa97 100644 --- a/contributors/devel/security-release-process.md +++ b/contributors/devel/security-release-process.md @@ -4,9 +4,11 @@ Kubernetes is a large growing community of volunteers, users, and vendors. The K ## Product Security Team (PST) -By their nature security vulnerabilities should be handled quickly and sometimes privately. The Product Security Team is responsible for running the communication, disclosure, and CVE/patch processes. They are not solely responsible for fixing issues and can loop in necessary engineers to test and verify the fixes. +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 initial Product Security Team will consist of five volunteers who are all subscribed to the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list. These are the people who have been involved in the initial discussion and volunteered: +The Product Security Team (PST) is responsible for organizing the entire response including internal communication and external disclosure but will need help from relevant developers and release managers to successfully run this process. + +The initial Product Security Team will consist of four volunteers subscribed to the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list. These are the people who have been involved in the initial discussion and volunteered: - Brandon Philips [4096R/154343260542DF34] - Jess Frazelle @@ -19,51 +21,78 @@ The initial Product Security Team will consist of five volunteers who are all su ## Release Manager Role -ALso included on the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list are all [Release Managers](https://github.com/kubernetes/community/wiki). +Also included on the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list are all [Release Managers](https://github.com/kubernetes/community/wiki). -It is the responsbility of the Product Security Team to add new Release Managers and remove Release Managers as Kubernetes minor releases are deprecated. +It is the responsibility of the PST to add and remove Release Managers as Kubernetes minor releases created and deprecated. ## Disclosures ### Private Disclosure Processes -We ask that suspected vulnerabilities should be responsibility disclosed via our disclosure process. Please visit [http://kubernetes.io/security](http://kubernetes.io/security] to learn more. +The Kubernetes Community asks that all suspected vulnerabilities be privately and responsibly disclosed via the Private Disclosure process available at [http://kubernetes.io/security](http://kubernetes.io/security]. ### Public Disclosure Processes -If a security issue has been publicly disclosed please IMMEDIATELY email [kubernetes-security@googlegroups.com](mailto:kubernetes-security@googlegroups.com) to inform the Product Security Team about the vulnerability and start the patch, release, and communication process. +If you know of a publicly disclosed security vulnerability please IMMEDIATELY email [kubernetes-security@googlegroups.com](mailto:kubernetes-security@googlegroups.com) to inform the Product Security Team (PST) about the vulnerability so they may start the patch, release, and communication process. -Next, ask the reporter if the issue can be handled via the private disclosure process. If the reporter denies it is best to proceed publicly and swiftly with the fix and release process. In extreme cases you can ask GitHub to delete the issue but this generally shouldn’t be necessary and is unlikely to make a public disclosure less damaging. +If possible the PST will ask the person making the public report if the issue can be handled via a private disclosure process. If the reporter denies the PST will move swiftly with the fix and release process. In extreme cases you can ask GitHub to delete the issue but this generally isn't necessary and is unlikely to make a public disclosure less damaging. ## Patch, Release, and Public Communication -- Request CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) (for embargoed issues) or [oss-security](http://www.openwall.com/lists/oss-security/) (for public issues) -- Set the issue priority based on rough criteria - - P0 - **Critical impact**, flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact. - - P1 - **Important impact**, flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service. - - P2 - **Moderate impact**, flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a Critical impact or Important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations. - - P3 - **Low Impact**, other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences. -- Invite relevant developers to have access to the private security fix repo. -- Work on a fix in a private repo, you can keep track of the issues on this repo as well. Put CVE number in commit and changelog. Please note although CVE is nice, code patch is nicer, better to move ahead without a CVE then to delay in waiting for a CVE. -- Make sure the CVE is mentioned in the commit log and changelog. Changelog for sure, commit log is a “nice to have”, also note situations where security have been fixed and not recognized as such until after the fact -- Apply the fixes to the release branch and any other release branches you will backport to - - Get LGTM on patches on the private repo - - **User disclosure** (1-5 days) - - Email kubernetes-announce@googlegroups.com informing users that a security vulnerability has been disclosed and that a fix will be made available at YYYY-MM-DD HH:MM in the future via this list. - - Communicate any mitigating steps they can take until a fix is available - - **Private distributors announce** (1-5 days): - - If the issue is Important or Critical email a patch to kubernetes-distributors-announce@googlegroups.com so distributors can prepare builds to be available to users on the day of the issue's announcement. Distributors can ask to be added to this list by emailing kubernetes-security@googlegroups.com and it is up to the Product Security Team's discretion to manage the list. - - **What if a vendor breaks embargo?** Sometimes could be small or big, just assess the damage and if you need to release earlier because of it, do that, otherwise continue with the plan. Generally speaking when that happens you just push forward and go public ASAP - - **On release day** - - Rebase the branch[es] with the fixes, including any other additional branches you applied or backported patches on, with the specific branch on the public repo you will eventually have this in, nothing should have changed upstream unless there were any public cherrypicks. - - Run the release on these branches (release branch, any additional backported release branches). - - Make sure all the binaries are up, publicly available, and functional. - - Open the patches in a PR on the public repo for each release branch you applied the patches to (1 PR per branch). - - Merge immediately (you cannot accept changes at this time, even for a typo in the CHANGELOG since it would change the git sha of the already built and published release[s]). - - Cherry-pick the same patches onto the master branch from the release branch. LGTM and merge. - - At this point everything is public. - - Email kubernetes-{dev,users,announce,etc}@googlegroups.com to get wide distribution and user action. - - Remove developers who developed the fix from the private security repo +For each vulnerability a member of the PST will volunteer to lead coordination with the Fix Team, Release Managers and is responsible for sending disclosure emails to the rest of the community. This lead will be referred to as the Fix Lead. + +The role of Fix Lead should rotate round-robin across the PST. + +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, development time, and release manager feedback. If the Fix Lead is dealing with a Public Disclosure all timelines become ASAP. + +### Fix Team Organization + +These steps should be completed within the first 24 hours of Disclosure. + +- The Fix Lead will work quickly to identify relevant engineers from the affected projects and packages and CC those engineers into the disclosure thread. This selected developers are the Fix Team. A best guess is to invite all assignees in the OWNERS file from the affected packages. +- The Fix Lead will request a CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) (for embargoed issues) or [oss-security](http://www.openwall.com/lists/oss-security/) (for public issues) +- The Fix Lead will get the Fix Team access to private security repos to develop the fix. + +### Fix Development Process + +These steps should be completed within the 1-7 days of Disclosure. + +- The Fix Team will work on in the private security repo to develop the fix. The fix branch should include the CVE number in relevant commits (optional) and changelog. +- The Fix Lead and the Fix Team will create a [CVSS](https://www.first.org/cvss/specification-document) using the [CVSS Calculator](https://www.first.org/cvss/calculator/3.0https://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 make the CVSS prefect. +- The Fix Team will notify the Fix Lead that work on the fix branch is complete once there are LGTMs on all commits in the private repo from one or more relevant assignees in the relevant OWNERS file. + +### 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 Team 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 kubernetes-announce@googlegroups.com 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. + +**Optional Fix Disclosure to Private Distributors List** (Completed within 1-14 days of Disclosure): + +- The Fix Lead will make a determination with the help of the Fix Team if an issue is critical enough to require early disclosure to distributors. Generally this Private Distributor Disclosure process should be reserved for remotely exploitable or privilege escalation issues. Otherwise, this process can be skipped. +- The Fix Lead will email the patches to kubernetes-distributors-announce@googlegroups.com so distributors can prepare builds to be available to users on the day of the issue's announcement. Distributors can ask to be added to this list by emailing kubernetes-security@googlegroups.com and it is up to the Product Security Team's discretion to manage the list. +- **What if a vendor breaks embargo?** The PST will assess the damage. The Fix Lead will make the call to release earlier or continue with the plan. When in doubt push forward and go public ASAP. + +**Fix Release Day** (Completed within 1-21 days of Disclosure) + +- The Release Managers will ensure all the binaries are built, publicly available, and functional before the Release Date. +- The Release Managers will open PRs on the public repo against each release branch that applied the fix. +- The Release Managers will merge these PRs immediately (you cannot accept changes at this time, even for a typo in the CHANGELOG since it would change the git sha of the already built and published release[s]). +- The Fix Lead will cherry-pick the patches onto the master branch from the release branch. The Fix Team will LGTM and merge. +- The Fix Lead will email kubernetes-{dev,users,announce,etc}@googlegroups.com now that everything is public announcing the new releases, the location of the binaries, and the relevant merged PRs to get wide distribution and user action. As much as possible this email should be actionable and include links how to apply the fix to users environments; this can include links to external distributor documentation. +- The Fix Lead will remove the Fix Team from the private security repo. + +### Retrospective + +These steps should be completed within the 21-28 days of Disclosure. + +- The Fix Lead will send a retrospective of the process to kubernetes-dev@googlegroups.com including details on everyone involved, links to relevant PRs that introduced the issue, if relevant, and any critiques of the response and release process. +- The Release Managers and Fix Team are also encouraged to send their own feedback on the process to kubernetes-dev@googlegroups.com. Honest critique is the only way we are going to get good at this as a community. [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/devel/security-release-process.md?pixel)]() From c488726cfc58985fd785941ee52909a59d44ebe2 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Fri, 3 Mar 2017 17:20:39 -0500 Subject: [PATCH 5/6] contributors: devel: more security-release-process feedback Address all outstanding feedback. --- .../devel/security-release-process.md | 34 +++++++++++-------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/contributors/devel/security-release-process.md b/contributors/devel/security-release-process.md index f1c54fa97..ea7b4fee3 100644 --- a/contributors/devel/security-release-process.md +++ b/contributors/devel/security-release-process.md @@ -10,10 +10,11 @@ The Product Security Team (PST) is responsible for organizing the entire respons The initial Product Security Team will consist of four volunteers subscribed to the private [Kubernetes Security](https://groups.google.com/forum/#!forum/kubernetes-security) list. These are the people who have been involved in the initial discussion and volunteered: -- Brandon Philips [4096R/154343260542DF34] -- Jess Frazelle -- Eric Tune -- Jordan Liggitt +- Brandon Philips `` [4096R/154343260542DF34] +- Jess Frazelle `` +- CJ Cullen `` +- Tim St. Clair `` [4096R/0x5E6F2E2DA760AF51] +- Jordan Liggitt `` **Known issues** @@ -29,7 +30,7 @@ It is the responsibility of the PST to add and remove Release Managers as Kubern ### Private Disclosure Processes -The Kubernetes Community asks that all suspected vulnerabilities be privately and responsibly disclosed via the Private Disclosure process available at [http://kubernetes.io/security](http://kubernetes.io/security]. +The Kubernetes Community asks that all suspected vulnerabilities be privately and responsibly disclosed via the Private Disclosure process available at [https://kubernetes.io/security](https://kubernetes.io/security). ### Public Disclosure Processes @@ -50,24 +51,24 @@ All of the timelines below are suggestions and assume a Private Disclosure. The These steps should be completed within the first 24 hours of Disclosure. - The Fix Lead will work quickly to identify relevant engineers from the affected projects and packages and CC those engineers into the disclosure thread. This selected developers are the Fix Team. A best guess is to invite all assignees in the OWNERS file from the affected packages. -- The Fix Lead will request a CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) (for embargoed issues) or [oss-security](http://www.openwall.com/lists/oss-security/) (for public issues) - The Fix Lead will get the Fix Team access to private security repos to develop the fix. ### Fix Development Process These steps should be completed within the 1-7 days of Disclosure. -- The Fix Team will work on in the private security repo to develop the fix. The fix branch should include the CVE number in relevant commits (optional) and changelog. -- The Fix Lead and the Fix Team will create a [CVSS](https://www.first.org/cvss/specification-document) using the [CVSS Calculator](https://www.first.org/cvss/calculator/3.0https://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 make the CVSS prefect. +- The Fix Lead and the Fix Team 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 make the CVSS prefect. - The Fix Team will notify the Fix Lead that work on the fix branch is complete once there are LGTMs on all commits in the private repo from one or more relevant assignees in the relevant OWNERS file. +If the CVSS score is under 2.0 the Fix Team can decide to slow the release process down in the face of holidays, developer bandwidth, etc. These decisions must be discussed on the kubernetes-security mailing list. + ### 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 Team 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 kubernetes-announce@googlegroups.com 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 email kubernetes-announce@googlegroups.com and kubernetes-security-announce@googlegroups.com 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. @@ -76,22 +77,25 @@ The communication to users should be actionable. They should know when to block - The Fix Lead will make a determination with the help of the Fix Team if an issue is critical enough to require early disclosure to distributors. Generally this Private Distributor Disclosure process should be reserved for remotely exploitable or privilege escalation issues. Otherwise, this process can be skipped. - The Fix Lead will email the patches to kubernetes-distributors-announce@googlegroups.com so distributors can prepare builds to be available to users on the day of the issue's announcement. Distributors can ask to be added to this list by emailing kubernetes-security@googlegroups.com and it is up to the Product Security Team's discretion to manage the list. + - TODO: Figure out process for getting folks onto this list. - **What if a vendor breaks embargo?** The PST will assess the damage. The Fix Lead will make the call to release earlier or continue with the plan. When in doubt push forward and go public ASAP. **Fix Release Day** (Completed within 1-21 days of Disclosure) - The Release Managers will ensure all the binaries are built, publicly available, and functional before the Release Date. -- The Release Managers will open PRs on the public repo against each release branch that applied the fix. -- The Release Managers will merge these PRs immediately (you cannot accept changes at this time, even for a typo in the CHANGELOG since it would change the git sha of the already built and published release[s]). -- The Fix Lead will cherry-pick the patches onto the master branch from the release branch. The Fix Team will LGTM and merge. -- The Fix Lead will email kubernetes-{dev,users,announce,etc}@googlegroups.com now that everything is public announcing the new releases, the location of the binaries, and the relevant merged PRs to get wide distribution and user action. As much as possible this email should be actionable and include links how to apply the fix to users environments; this can include links to external distributor documentation. + - TODO: this will require a private security build process. +- The Release Managers will create a new patch release branch from the latest patch release tag + the fix from the security branch. As a practical example if v1.5.3 is the latest patch release in kubernetes.git a new branch will be created called v1.5.4 which includes only patches required to fix the issue. +- The Fix Lead will cherry-pick the patches onto the master branch and all relevant release branches. The Fix Team will LGTM and merge. +- The Release Managers will merge these PRs as quickly as possible. Changes shouldn't be made to the commits even for a typo in the CHANGELOG as this will change the git sha of the already built and commits leading to confusion and potentially conflicts as the fix is cherry-picked around branches. +- The Fix Lead will request a CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) and include the CVSS and release details. +- The Fix Lead will email kubernetes-{dev,users,announce,security-announce}@googlegroups.com now that everything is public announcing the new releases, the CVE number, the location of the binaries, and the relevant merged PRs to get wide distribution and user action. As much as possible this email should be actionable and include links how to apply the fix to users environments; this can include links to external distributor documentation. - The Fix Lead will remove the Fix Team from the private security repo. ### Retrospective -These steps should be completed within the 21-28 days of Disclosure. +These steps should be completed 1-3 days after the Release Date. The retrospective process [should be blameless](https://landing.google.com/sre/book/chapters/postmortem-culture.html). -- The Fix Lead will send a retrospective of the process to kubernetes-dev@googlegroups.com including details on everyone involved, links to relevant PRs that introduced the issue, if relevant, and any critiques of the response and release process. +- The Fix Lead will send a retrospective of the process to kubernetes-dev@googlegroups.com including details on everyone involved, the timeline of the process, links to relevant PRs that introduced the issue, if relevant, and any critiques of the response and release process. - The Release Managers and Fix Team are also encouraged to send their own feedback on the process to kubernetes-dev@googlegroups.com. Honest critique is the only way we are going to get good at this as a community. From 5c229e6454e3359e8dd29b72fa8f5848b3c5c601 Mon Sep 17 00:00:00 2001 From: Brandon Philips Date: Sun, 5 Mar 2017 21:01:15 -0800 Subject: [PATCH 6/6] contributors: security release process: links and severity - Add links to mailing lists - Make 4.0 CVSS low severity --- contributors/devel/security-release-process.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributors/devel/security-release-process.md b/contributors/devel/security-release-process.md index ea7b4fee3..6a98f55e9 100644 --- a/contributors/devel/security-release-process.md +++ b/contributors/devel/security-release-process.md @@ -60,7 +60,7 @@ These steps should be completed within the 1-7 days of Disclosure. - The Fix Lead and the Fix Team 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 make the CVSS prefect. - The Fix Team will notify the Fix Lead that work on the fix branch is complete once there are LGTMs on all commits in the private repo from one or more relevant assignees in the relevant OWNERS file. -If the CVSS score is under 2.0 the Fix Team can decide to slow the release process down in the face of holidays, developer bandwidth, etc. These decisions must be discussed on the kubernetes-security mailing list. +If the CVSS score is under 4.0 ([a low severity score](https://www.first.org/cvss/specification-document#i5)) the Fix Team can decide to slow the release process down in the face of holidays, developer bandwidth, etc. These decisions must be discussed on the kubernetes-security mailing list. ### Fix Disclosure Process @@ -68,7 +68,7 @@ With the Fix Development underway the Fix Lead needs to come up with an overall **Disclosure of Forthcoming Fix to Users** (Completed within 1-7 days of Disclosure) -- The Fix Lead will email kubernetes-announce@googlegroups.com and kubernetes-security-announce@googlegroups.com 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 email [kubernetes-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-announce) and [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-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. @@ -84,7 +84,7 @@ The communication to users should be actionable. They should know when to block - The Release Managers will ensure all the binaries are built, publicly available, and functional before the Release Date. - TODO: this will require a private security build process. -- The Release Managers will create a new patch release branch from the latest patch release tag + the fix from the security branch. As a practical example if v1.5.3 is the latest patch release in kubernetes.git a new branch will be created called v1.5.4 which includes only patches required to fix the issue. +- The Release Managers will create a new patch release branch from the latest patch release tag + the fix from the security branch. As a practical example if v1.5.3 is the latest patch release in kubernetes.git a new branch will be created called v1.5.4 which includes only patches required to fix the issue. - The Fix Lead will cherry-pick the patches onto the master branch and all relevant release branches. The Fix Team will LGTM and merge. - The Release Managers will merge these PRs as quickly as possible. Changes shouldn't be made to the commits even for a typo in the CHANGELOG as this will change the git sha of the already built and commits leading to confusion and potentially conflicts as the fix is cherry-picked around branches. - The Fix Lead will request a CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) and include the CVSS and release details.