Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: update security-release process to automated one #53877

Merged
merged 4 commits into from
Jul 29, 2024
Merged

doc: update security-release process to automated one #53877

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
9d4ff73
doc: update security-release process to automated one
RafaelGSS Jul 16, 2024
dc1e049
fixup! Apply suggestions from code review
RafaelGSS Jul 16, 2024
5f84757
fixup! apply cr suggestions
RafaelGSS Jul 24, 2024
d082ea9
Update doc/contributing/security-release-process.md
RafaelGSS Jul 26, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
291 changes: 107 additions & 184 deletions doc/contributing/security-release-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,191 +43,118 @@ The current security stewards are documented in the main Node.js

## Planning

* [ ] Open an [issue](https://github.com/nodejs-private/node-private) titled
`Next Security Release`, and put this checklist in the description.

* [ ] Get agreement on the list of vulnerabilities to be addressed:
* _**H1 REPORT LINK**_: _**DESCRIPTION**_ (_**CVE or H1 CVE request link**_)
* v10.x, v12.x: _**LINK to PR URL**_
* ...

* [ ] PR release announcements in [private](https://github.com/nodejs-private/nodejs.org-private):
* (Use previous PRs as templates. Don't forget to update the site banner and
the date in the slug so that it will move to the top of the blog list.)
* (Consider using a [Vulnerability Score System](https://www.first.org/cvss/calculator/3.1)
to identify severity of each report)
* Share the patch with the reporter when applicable.
It will increase the fix accuracy.
* [ ] pre-release: _**LINK TO PR**_
* [ ] post-release: _**LINK TO PR**_
* List vulnerabilities in order of descending severity
* Use the "summary" feature in HackerOne to sync post-release content
and CVE requests. Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
* Ask the HackerOne reporter if they would like to be credited on the
security release blog page:
```text
Thank you to <name> for reporting this vulnerability.
```

* [ ] Get agreement on the planned date for the release: _**RELEASE DATE**_

* [ ] Get release team volunteers for all affected lines:
* v12.x: _**NAME of RELEASER(S)**_
* ... other lines, if multiple releasers
1. **Generating Next Security Release PR**
RafaelGSS marked this conversation as resolved.
Show resolved Hide resolved
* Run `git node security --start` inside [security-release][] repository.
* This command generates a new `vulnerabilities.json` file with HackerOne
reports chosen to be released in the `security-release/next-security-release`
folder.
* It also creates the pull request used to manage the security release.

2. **Review of Reports:**
* Reports can be added or removed using the following commands:
* Use the "summary" feature in HackerOne. Example [2038134](https://hackerone.com/reports/2038134)
* `git node security --add-report=report_id`
* `git node security --remove-report=report_id`

3. **Assigning Severity and Writing Team Summary:**
* Assign a severity and write a team summary on HackerOne for the reports
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to link to the place in the UI where you do this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a URL, it's a JavaScript button. However, it's very easy to find (right below the H1 title).

chosen in the `vulnerabilities.json`.
* Run `git node security --sync` to update severity and summary in
`vulnerabilities.json`.

4. **Requesting CVEs:**
* Request CVEs for the reports with `git node security --request-cve`.
* Make sure to have a green CI before requesting a CVE.

5. **Choosing or Updating Release Date:**
RafaelGSS marked this conversation as resolved.
Show resolved Hide resolved
* Use `git node security --update-date=YYYY/MM/DD` to choose or update the
release date.
* This allows flexibility in postponing the release if needed.

6. **Get release volunteers:**
* Get volunteers for the upcoming security release on the affected release
lines.
RafaelGSS marked this conversation as resolved.
Show resolved Hide resolved

7. **Preparing Pre and Post Release Blog Posts:**
* Create a pre-release blog post using `git node security --pre-release`.
* Create a post-release blog post using `git node security --post-release`.

## Announcement (one week in advance of the planned release)

* [ ] Check that all vulnerabilities are ready for release integration:
* PRs against all affected release lines or cherry-pick clean
* PRs with breaking changes have a
[--security-revert](#Adding-a-security-revert-option) option if possible.
* Approved
* (optional) Approved by the reporter
* Build and send the binary to the reporter according to its architecture
and ask for a review. This step is important to avoid insufficient fixes
between Security Releases.
* Pass `make test`
* Have CVEs
* Use the "summary" feature in HackerOne to create a description for the
CVE and the post release announcement.
Example [2038134](https://hackerone.com/bugs?subject=nodejs\&report_id=2038134)
* Make sure that dependent libraries have CVEs for their issues. We should
only create CVEs for vulnerabilities in Node.js itself. This is to avoid
having duplicate CVEs for the same vulnerability.
* Described in the pre/post announcements

* [ ] Pre-release announcement to nodejs.org blog: _**LINK TO BLOG**_
(Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
nodejs/nodejs.org)

If the security release will only contain an OpenSSL update consider
adding the following to the pre-release announcement:

```text
Since this security release will only include updates for OpenSSL, if you're using
a Node.js version which is part of a distribution which uses a system
installed OpenSSL, this Node.js security update might not concern you. You may
instead need to update your system OpenSSL libraries, please check the
security announcements for the distribution.
```

* [ ] Pre-release announcement [email][]: _**LINK TO EMAIL**_
* Subject: `Node.js security updates for all active release lines, Month Year`
* Body:
```text
The Node.js project will release new versions of all supported release lines on or shortly after Day of week, Month Day of Month, Year
For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
```
(Get access from existing manager: Matteo Collina, Rodd Vagg, Michael Dawson,
Bryan English)

* [ ] CC `oss-security@lists.openwall.com` on pre-release

The google groups UI does not support adding a CC, until we figure
out a better way, forward the email you receive to
`oss-security@lists.openwall.com` as a CC.

* [ ] Post in the [nodejs-social channel][]
in the OpenJS slack asking for amplification of the blog post.

```text
Security release pre-alert:

We will release new versions of <add versions> release lines on or shortly
after Day Month Date, Year in order to address:

- # high severity issues
- # moderate severity issues

https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
```

We specifically ask that collaborators other than the releasers and security
steward working on the security release do not tweet or publicise the release
until the tweet from the Node.js twitter handle goes out. We have often
seen tweets sent out before the release and associated announcements are
complete which may confuse those waiting for the release and also takes
away from the work the releasers have put into shipping the releases.

* [ ] Request releaser(s) to start integrating the PRs to be released.

* [ ] Notify [docker-node][] of upcoming security release date: _**LINK**_
```text
Heads up of Node.js security releases Day Month Year

As per the Node.js security release process this is the FYI that there is going to be a security release Day Month Year
```

* [ ] Notify build-wg of upcoming security release date by opening an issue
in [nodejs/build][] to request WG members are available to fix any CI issues.
```text
Heads up of Node.js security releases Day Month Year

As per security release process this is a heads up that there will be security releases Day Month Year and we'll need people from build to lock/unlock ci and to support and build issues we see.
```
1. **Publish Pre-Release Blog Post:**
* Publish the pre-release blog post on the `nodejs/nodejs.org` repository.

2. **Send Pre-Release Accouncement:**
* Notify the community about the upcoming security release:
* `git node security --notify-pre-release`
RafaelGSS marked this conversation as resolved.
Show resolved Hide resolved
* (Not yet supported) [Google Groups](https://groups.google.com/g/nodejs-sec)
RafaelGSS marked this conversation as resolved.
Show resolved Hide resolved
* Email: notify <oss-security@lists.openwall.com>
* (Not yet supported) [Twitter / X](https://x.com/nodejs)
RafaelGSS marked this conversation as resolved.
Show resolved Hide resolved
* [docker-node](https://github.com/nodejs/docker-node/issues)
* [build-wg](https://github.com/nodejs/build/issues)
We specifically ask that collaborators other than the releasers and security
steward working on the security release do not tweet or publicize the release
until the tweet from Node.js goes out. We have often
seen tweets sent out before the release is
complete, which may confuse those waiting for the release and take
away from the work the releasers have put into shipping the release.

If the security release will only contain an OpenSSL update, consider
adding the following to the pre-release announcement:

```text
Since this security release will only include updates for OpenSSL, if you're using
a Node.js version which is part of a distribution that uses a system
installed OpenSSL, this Node.js security update may not concern you, instead,
you may need to update your system OpenSSL libraries. Please check the
security announcements for more information.
```

## Release day

* [ ] [Lock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#before-the-release)

* [ ] The releaser(s) run the release process to completion.

* [ ] [Unlock CI](https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#after-the-release)

* [ ] Post-release announcement to Nodejs.org blog: _**LINK TO BLOG POST**_
* (Re-PR the pre-approved branch from nodejs-private/nodejs.org-private to
nodejs/nodejs.org)

* [ ] Post-release announcement in reply [email][]: _**LINK TO EMAIL**_
* CC: `oss-security@lists.openwall.com`
* Subject: `Node.js security updates for all active release lines, Month Year`
* Body:
```text
The Node.js project has now released new versions of all supported release lines.
For more information see: https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
```

* [ ] Post in the [nodejs-social channel][]
in the OpenJS slack asking for amplification of the blog post.
```text
Security release:

New security releases are now available for versions <add versions> of Node.js.

https://nodejs.org/en/blog/vulnerability/month-year-security-releases/
```

* [ ] Comment in [docker-node][] issue that release is ready for integration.
The docker-node team will build and release docker image updates.

* [ ] For every H1 report resolved:
* Close as Resolved
* Request Disclosure
* Request publication of [H1 CVE requests][]
* (Check that the "Version Fixed" field in the CVE is correct, and provide
links to the release blogs in the "Public Reference" section)
* In case the reporter doesn't accept the disclosure follow this process:
* Remove the original report reference within the reference text box and
insert the public URL you would like to be attached to this CVE.
* Then uncheck the Public Disclosure on HackerOne box at the bottom of the
page.
![screenshot of HackerOne CVE form](https://github.com/nodejs/node/assets/26234614/e22e4f33-7948-4dd2-952e-2f9166f5568d)

* [ ] PR machine-readable JSON descriptions of the vulnerabilities to the
[core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
vulnerability DB. _**LINK TO PR**_
* For each vulnerability add a `#.json` file, one can copy an existing
[json](https://github.com/nodejs/security-wg/blob/0d82062d917cb9ddab88f910559469b2b13812bf/vuln/core/78.json)
file, and increment the latest created file number and use that as the name
of the new file to be added. For example, `79.json`.

* [ ] Close this issue

* [ ] Make sure the PRs for the vulnerabilities are closed.

* [ ] PR in that you stewarded the release in
[Security release stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards).
If necessary add the next rotation of the steward rotation.
1. **Lock down the CI:**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There used to be checkboxes and the steward could copy the security-release-process.md doc into the issue for the release and use the checkboxes to track progress. The checkboxes are not in this doc, but are they in the issue created for the release (if there still is one?)

Copy link
Member Author

@RafaelGSS RafaelGSS Jul 24, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no issue anymore. We use the Next Security Release PR instead. I didn't add checkboxes as they will all be automated, but I'll include checkboxes for manual steps.

* Lock down the CI to prevent public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.

2. **Release:**
* Verify the CI is green on all release proposals (test-V8, CITGM, etc).
* Follow the [release process](https://github.com/nodejs/node/blob/main/doc/contributing/releases.md).

3. **Unlock the CI:**
* Unlock the CI to allow public access to the CI machines, ping a member of `@nodejs/jenkins-admins`.

4. **Publish Post-Release Blog Post:**
* Publish the post-release blog post on the `nodejs/nodejs.org` repository.

5. **Notify the community:**
* Notify the community about the upcoming security release:
RafaelGSS marked this conversation as resolved.
Show resolved Hide resolved
* Slack: `#nodejs-social`
* [docker-node](https://github.com/nodejs/docker-node/issues)
* [build-wg](https://github.com/nodejs/build/issues)
* Email: notify <oss-security@lists.openwall.com>
RafaelGSS marked this conversation as resolved.
Show resolved Hide resolved

## Post-Release

1. **Merge the Next Security Release PR:**
* This involves moving the `vulnerabilities.json` file from
`security-release/next-security-release` to the `security-release/YYYY-MM-DD`
folder and merging the PR.

2. **Cleanup:**
* Close PRs and backports.
* Close any pending PRs related to the security release.
* Close HackerOne reports:
* Close Resolved
* Request Disclosure
* Request publication of H1 CVE requests
* In case the reporter doesn't accept the disclosure follow this process:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* In case the reporter doesn't accept the disclosure follow this process:
as mentioned, it may just be easier to include the link to the post on Node.js org where the security release details are shared.

Remove the original report reference within the reference text box and
insert the public URL you would like to be attached to this CVE.
Then uncheck the Public Disclosure on HackerOne box at the bottom of the
page.
![screenshot of HackerOne CVE form](https://github.com/nodejs/node/assets/26234614/e22e4f33-7948-4dd2-952e-2f9166f5568d)
* PR machine-readable JSON descriptions of the vulnerabilities to the [core](https://github.com/nodejs/security-wg/tree/HEAD/vuln/core)
vulnerability DB.
* Add yourself as a steward in the [Security Release Stewards](https://github.com/nodejs/node/blob/HEAD/doc/contributing/security-release-process.md#security-release-stewards)

## Adding a security revert option

Expand Down Expand Up @@ -298,8 +225,4 @@ The steps to correct CVE information are:
* Include all the details that need updating within the form
* Submit the request

[H1 CVE requests]: https://hackerone.com/nodejs/cve_requests
[docker-node]: https://github.com/nodejs/docker-node/issues
[email]: https://groups.google.com/forum/#!forum/nodejs-sec
[nodejs-social channel]: https://openjs-foundation.slack.com/archives/C0142A39BNE
[nodejs/build]: https://github.com/nodejs/build/issues
[security-release]: https://github.com/nodejs-private/security-release
Loading