From 5648f5ec6effbf4c497a292cb1ac94836506dab6 Mon Sep 17 00:00:00 2001 From: Sam Roberts Date: Mon, 16 Dec 2019 16:38:27 -0500 Subject: [PATCH] doc: de-duplicate security release processes The security release process is spread across multiple files. Merge these two files to remove duplication and inconsistency. Also, make the format more useful for inserting into the description of the Next Security Release issue description. This seems an obvious candidate for a github issue template, but if it was, the content would not be reviewable by anyone outside of those on the security teams, and the process should be public for purposes of transparency and review. PR-URL: https://github.com/nodejs/node/pull/30996 Reviewed-By: Rich Trott --- doc/guides/security_announcement_process.md | 61 ------------ doc/guides/security_release_process.md | 104 ++++++++++++-------- 2 files changed, 63 insertions(+), 102 deletions(-) delete mode 100644 doc/guides/security_announcement_process.md diff --git a/doc/guides/security_announcement_process.md b/doc/guides/security_announcement_process.md deleted file mode 100644 index 86b3a81bf62889..00000000000000 --- a/doc/guides/security_announcement_process.md +++ /dev/null @@ -1,61 +0,0 @@ -The Node.js community follows a process to create/review and -then publish vulnerability announcements. It is most often a 2 step -process where we: - -* announce that releases will be made to fix an embargoed vulnerability -* announce that the releases with the fixes are available - -The process is as follows: - -* Security vulnerabilties are initially discussed/reviewed in the private - security repository. - -* Once we are ready to release an anouncement of an upcoming fix for the - the vulnerability, on the issue for the security vulnerability in private - security repo, propose candidate text based on past announcements. - -* Once reviewed, agree on timing for the releases with the fix and line up - releasers to make sure they are available to do the release on that date. - -* Post to https://groups.google.com/forum/#!forum/nodejs-sec. - **Note** that you will need to have been given access by one of the - existing managers (Ben Noordhuis, Rod Vagg, Trevor Norris, Michael Dawson). - You will have to manually edit to add formatting and links properly. - -* Mirror post in vulnerabilities section of Nodejs.org blog section - (https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability) - Submit PR and leave 1 hour for review. After one hour even if no reviews, - land anyway so that we don't have too big a gap between post to nodejs-sec - and blog. Text was already reviewed in security repo so is unlikely to - attract much additional comment. **The PR should also update the banner - on the Node.js website to indicate security releases are coming with the - banner linked to the blog** - -* In original PR for the security repository for the issue, post candidate - text for updates that will go out with releases that will indicates - releases are available and include full vulnerability details. - -* Once releases are made, post response to original message in - https://groups.google.com/forum/#!forum/nodejs-sec indicating - releases are available and with the full vulnerability details. - -* Update the blog post in - https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability - with the information that releases are available and the full - vulnerability details. Keep the original blog content at the - bottom of the blog. This is an example: - https://github.com/nodejs/nodejs.org/blob/master/locale/en/blog/vulnerability/june-2016-security-releases.md. - Make sure to update the date in the slug so that it will move to - the top of the blog list. **As part of the PR, update the - banner on Node.js org to indicate the security release are - available.** - - *Note*: If the release blog obviously points to the people having caused the - issue (for example when explicitly mentioning reverting a commit), adding - those people as a CC on the PR for the blog post to give them a heads up - might be appropriate. - -* Tweet out a link to the nodejs-sec announcement. - -* Email foundation contact to tweet out nodejs-sec announcement from - foundation twitter account. diff --git a/doc/guides/security_release_process.md b/doc/guides/security_release_process.md index 3508cc79d862f7..9d1e4f1b33654a 100644 --- a/doc/guides/security_release_process.md +++ b/doc/guides/security_release_process.md @@ -1,61 +1,83 @@ # Security Release Process -The security release process covers the steps required to plan/implement -a security release. +The security release process covers the steps required to plan/implement a +security release. This document is copied into the description of the Next +Security Release, and used to track progess on the release. It contains +***TEXT LIKE THIS*** which will be replaced during the release process with +the information described. ## Planning * [ ] Open an issue in the private security repo titled `Next Security Release` - and add the planning checklist to the description. + and add this planning checklist to the description. -* [ ] Get agreement on the list of vulnerabilities to be addressed. +* [ ] Get agreement on the list of vulnerabilities to be addressed: + * ***LINKS TO VULNS...*** -* [ ] Get agreement on the planned date for the releases. +* [ ] Get agreement on the planned date for the release: ***RELEASE DATE*** -* [ ] Once agreement on the list and date has been agreed, validate that all - vulnerabilities have been assigned a CVE following the - [cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md). +* [ ] Validate that all vulnerabilities have been assigned a CVE. Upstream deps + such as OpenSSL and NPM will have CVEs, issues reported on H1 may have CVEs, + otherwise allocate them by following the + [cve_management_process](https://github.com/nodejs/node/blob/master/doc/guides/cve_management_process.md). * [ ] Co-ordinate with the Release team members to line up one or more releasers - to do the releases on the agreed date. + to do the releases on the agreed date. Releaser: ***NAME of RELEASER(S)*** -* [ ] Prep for the pre-security announcement and final security announcement by - getting agreement on drafts following the - [security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md). +* [ ] Prep for the security announcements by getting agreement on drafts (use + previously announced releases as the template): + * pre-release: ***LINK TO COMMENT ON THIS ISSUE CONTAINING DRAFT*** + * post-release: ***LINK TO COMMENT ON THIS ISSUE CONTAINING DRAFT*** ## Announcement (one week in advance of the planned release) -* [ ] Ensure the pre-announce is sent out as outlined in the - [security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md). +* Send pre-release announcement to + https://groups.google.com/forum/#!forum/nodejs-sec. + One of the existing managers can give access (Ben + Noordhuis, Rod Vagg, Michael Dawson). ***LINK TO EMAIL*** + +* Post pre-release announcement in vulnerabilities section of Nodejs.org blog + (https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability). + Use last pre-release announcement as a template (it includes blog metadata + such as updates to the banner on the Node.js website to indicate security + releases are coming). Submit PR and leave 1 hour for review. After one hour + even if no reviews, land anyway so that we don't have too big a gap between + post to nodejs-sec and blog. Text was already reviewed in security repo so is + unlikely to attract much additional comment. ***LINK TO BLOG PR AND POST*** * [ ] Open an issue in the build working repository with a notification of the date for the security release. Use this issue to co-ordinate with the build team to ensure there will be coverage/availability of build team resources the day of the release. Those who volunteer from the build WG should be available - in node-build during the release in case they are needed by the individual - doing the release. + in node/build during the release in case they are needed by the individual + doing the release. ***LINK TO BUILD ISSUE*** -* [ ] Send an email to the docker official image - [maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS) - with an FYI that security releases will be going out on the agreed date. +## Release day -* [ ] Open an issue in the [docker-node](https://github.com/nodejs/docker-node) - repo and get one or more volunteers to be available to review the PR to update - Node.js versions in the docker-node repo immediately after the release. +* [ ] The releaser(s) run the release process to completion. -* [ ] Call on the sec release volunteer(s) to start integrating the PRs, running - the CI jobs, and generally prepping the release. +* [ ] Send post-release announcement as a reply to the + original message in https://groups.google.com/forum/#!forum/nodejs-sec + ***LINK TO EMAIL*** -## Release day +* [ ] Update the blog post in + https://github.com/nodejs/nodejs.org/tree/master/locale/en/blog/vulnerability + with the information that releases are available and the full + vulnerability details. Keep the original blog content at the + bottom of the blog. Use this as an example: + https://github.com/nodejs/nodejs.org/blob/master/locale/en/blog/vulnerability/june-2016-security-releases.md. + Make sure to update the date in the slug so that it will move to + the top of the blog list, and not that it updates the + banner on Node.js org to indicate the security release(s) are + available. ***LINK TO PR*** -* [ ] Co-ordinate with the Release team members and keep up to date on progress. - Get an guesstimate of when releases may be ready and send an FYI to the docker - official image - [maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS). + *Note*: If the release blog obviously points to the people having caused the + issue (for example when explicitly mentioning reverting a commit), adding + those people as a CC on the PR for the blog post to give them a heads up + might be appropriate. -* [ ] When the releases are promoted, ensure the final announce goes out as per - the - [security_announcement_process](https://github.com/nodejs/security-wg/blob/master/processes/security_annoucement_process.md). +* [ ] Email foundation contact to tweet out nodejs-sec announcement from + foundation twitter account. FIXME - who is this contact? * [ ] Create a PR to update the Node.js version in the official docker images. * Checkout the docker-node repo. @@ -81,19 +103,19 @@ a security release. [maintainers](https://github.com/docker-library/official-images/blob/master/MAINTAINERS) indicating that the PR is open. -* [ ] Ensure that the announced CVEs are reported to Mitre as per the - [cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md). - -* [ ] Ensure that the announced CVEs are updated in the cve-management - repository as per the - [cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md) - so that they are listed under Announced. +* [ ] If we allocated CVES: + * [ ] Ensure that the announced CVEs are reported to Mitre as per the + [cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md). + * [ ] Ensure that the announced CVEs are updated in the cve-management + repository as per the + [cve_management_process](https://github.com/nodejs/security-wg/blob/master/processes/cve_management_process.md) + so that they are listed under Announced. * [ ] PR machine-readable JSON descriptions of the vulnerabilities to the [core](https://github.com/nodejs/security-wg/tree/master/vuln/core) - vulnerability DB. + vulnerability DB. ***LINK TO PR*** * [ ] Make sure the PRs for the vulnerabilities are closed. -* [ ] Ensure the issue in the private security repo for the release is closed +* [ ] Ensure this issue in the private security repo for the release is closed out.