contributors: devel: more security-release-process feedback

Address all outstanding feedback.

1 files changed, 19 insertions, 15 deletions

diff --git a/contributors/devel/security-release-process.md b/contributors/devel/security-release-process.md
index f1c54fa9..ea7b4fee 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 <brandon.philips> [4096R/154343260542DF34]
-- Jess Frazelle <jessfraz@google.com>
-- Eric Tune <etune@google.com>
-- Jordan Liggitt <jliggitt@redhat.com>
+- Brandon Philips `<brandon.philips@coreos.com>` [4096R/154343260542DF34]
+- Jess Frazelle `<jessfraz@google.com>`
+- CJ Cullen `<cjcullen@google.com>`
+- Tim St. Clair `<stclair@google.com>` [4096R/0x5E6F2E2DA760AF51]
+- Jordan Liggitt `<jliggitt@redhat.com>`
 
 **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.
 
 <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->