mirrors/nodejs
mirrors/nodejs
0
0
Fork 0
mirror of https://github.com/nodejs/node.git synced 2024-11-29 23:16:30 +01:00
Code Issues Releases Activity
ae8f20ec5e
nodejs/doc/guides/security_release_process.md
Nick Schonning a1e47d7603 doc: correct typos in security release process 
- Double word "the"
- offical -> official
- annoucement -> announcement

PR-URL: https://github.com/nodejs/node/pull/29822
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
2019-10-10 21:38:42 -07:00

4.7 KiB
Raw Blame History

Security Release Process

The security release process covers the steps required to plan/implement a security release.

Planning

  • Open an issue in the private security repo titled Next Security Release and add the planning checklist to the description.

  • Get agreement on the list of vulnerabilities to be addressed.

  • Get agreement on the planned date for the releases.

  • Once agreement on the list and date has been agreed, validate that all vulnerabilities have been assigned a CVE following the cve_management_process.

  • Co-ordinate with the Release team members to line up one or more releasers to do the releases on the agreed date.

  • Prep for the pre-security announcement and final security announcement by getting agreement on drafts following the security_announcement_process.

Announcement (one week in advance of the planned release)

  • Ensure the pre-announce is sent out as outlined in the security_announcement_process.

  • 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.

  • Send an email to the docker official image maintainers with an FYI that security releases will be going out on the agreed date.

  • Open an issue in the 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.

  • Call on the sec release volunteer(s) to start integrating the PRs, running the CI jobs, and generally prepping the release.

Release day

  • 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.

  • When the releases are promoted, ensure the final announce goes out as per the security_announcement_process.

  • Create a PR to update the Node.js version in the official docker images.

    • Checkout the docker-node repo.
    • Run the update.sh using the -s option so that ONLY the Node.js versions are updated. At the request from docker (and because it is good practice) we limit the changes to those necessary in security updates.
    • Open a PR and get volunteer lined up earlier to approve.
    • Merge the PR with the merge button.
    • Checkout the official-images repository .
    • In the docker-node repository run the generate-stackbrew-library.sh script and replace official-images/library/node with the output generated. 
      $ ./generate-stackbrew-library.sh > .../official-images/library/node
    • Open a PR with the changes to official-images/library/node making sure to @mention the official images. maintainers. In addition, make sure to prefix the PR title with [security].
    • Send an email to the maintainers indicating that the PR is open.

  • Ensure that the announced CVEs are reported to Mitre as per the cve_management_process.

  • Ensure that the announced CVEs are updated in the cve-management repository as per the cve_management_process so that they are listed under Announced.

  • PR machine-readable JSON descriptions of the vulnerabilities to the core vulnerability DB.

  • Make sure the PRs for the vulnerabilities are closed.

  • Ensure the issue in the private security repo for the release is closed out.