doc: fix minor grammar and style issues in SECURITY.md

PR-URL: https://github.com/nodejs/node/pull/53168
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
This commit is contained in:
Rich Trott 2024-05-28 10:40:22 -07:00 committed by GitHub
parent 8c6d43cc4f
commit a2446de50f
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -4,7 +4,7 @@
Report security bugs in Node.js via [HackerOne](https://hackerone.com/nodejs). Report security bugs in Node.js via [HackerOne](https://hackerone.com/nodejs).
Normally your report will be acknowledged within 5 days, and you'll receive Normally, your report will be acknowledged within 5 days, and you'll receive
a more detailed response to your report within 10 days indicating the a more detailed response to your report within 10 days indicating the
next steps in handling your submission. These timelines may extend when next steps in handling your submission. These timelines may extend when
our triage volunteers are away on holiday, particularly at the end of the our triage volunteers are away on holiday, particularly at the end of the
@ -21,9 +21,9 @@ The Node.js project engages in an official bug bounty program for security
researchers and responsible public disclosures. The program is managed through researchers and responsible public disclosures. The program is managed through
the HackerOne platform. See <https://hackerone.com/nodejs> for further details. the HackerOne platform. See <https://hackerone.com/nodejs> for further details.
## Reporting a bug in a third party module ## Reporting a bug in a third-party module
Security bugs in third party modules should be reported to their respective Security bugs in third-party modules should be reported to their respective
maintainers. maintainers.
## Disclosure policy ## Disclosure policy
@ -41,20 +41,19 @@ Here is the security disclosure policy for Node.js
* A suggested embargo date for this vulnerability is chosen and a CVE (Common * A suggested embargo date for this vulnerability is chosen and a CVE (Common
Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability. Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability.
* On the embargo date, the Node.js security mailing list is sent a copy of the * On the embargo date, a copy of the announcement is sent to the Node.js
announcement. The changes are pushed to the public repository and new builds security mailing list. The changes are pushed to the public repository and new
are deployed to nodejs.org. Within 6 hours of the mailing list being builds are deployed to nodejs.org. Within 6 hours of the mailing list being
notified, a copy of the advisory will be published on the Node.js blog. notified, a copy of the advisory will be published on the Node.js blog.
* Typically the embargo date will be set 72 hours from the time the CVE is * Typically, the embargo date will be set 72 hours from the time the CVE is
issued. However, this may vary depending on the severity of the bug or issued. However, this may vary depending on the severity of the bug or
difficulty in applying a fix. difficulty in applying a fix.
* This process can take some time, especially when coordination is required * This process can take some time, especially when we need to coordinate with
with maintainers of other projects. Every effort will be made to handle the maintainers of other projects. We will try to handle the bug as quickly as
bug in as timely a manner as possible; however, it's important that we follow possible; however, we must follow the release process above to ensure that we
the release process above to ensure that the disclosure is handled in a handle disclosure consistently.
consistent manner.
## The Node.js threat model ## The Node.js threat model
@ -91,12 +90,12 @@ Vulnerabilities related to this case may be fixed by a documentation update.
2. The data received from the remote end of outbound network connections 2. The data received from the remote end of outbound network connections
that are created through the use of Node.js APIs and that are created through the use of Node.js APIs and
which is transformed/validated by Node.js before being passed which is transformed/validated by Node.js before being passed
to the application EXCEPT in respect to payload length. Node.js trusts to the application EXCEPT with respect to payload length. Node.js trusts
that applications make connections/requests which will avoid payload that applications make connections/requests which will avoid payload
sizes that will result in a Denial of Service. sizes that will result in a Denial of Service.
* HTTP APIs (all flavors) client APIs. * HTTP APIs (all flavors) client APIs.
* DNS APIs. * DNS APIs.
3. Consumers of data protected through the use of Node.js APIs (for example 3. Consumers of data protected through the use of Node.js APIs (for example,
people who have access to data encrypted through the Node.js crypto APIs). people who have access to data encrypted through the Node.js crypto APIs).
4. The file content or other I/O that is opened for reading or writing by the 4. The file content or other I/O that is opened for reading or writing by the
use of Node.js APIs (ex: stdin, stdout, stderr). use of Node.js APIs (ex: stdin, stdout, stderr).
@ -107,13 +106,13 @@ a security vulnerability. Examples of unwanted actions are polluting globals,
causing an unrecoverable crash, or any other unexpected side effects that can causing an unrecoverable crash, or any other unexpected side effects that can
lead to a loss of confidentiality, integrity, or availability. lead to a loss of confidentiality, integrity, or availability.
**Node.js trusts everything else**. As some examples this includes: **Node.js trusts everything else**. Examples include:
1. The developers and infrastructure that runs it. 1. The developers and infrastructure that runs it.
2. The operating system that Node.js is running under and its configuration, 2. The operating system that Node.js is running under and its configuration,
along with anything under control of the operating system. along with anything under control of the operating system.
3. The code it is asked to run including JavaScript and native code, even if 3. The code it is asked to run, including JavaScript and native code, even if
said code is dynamically loaded, e.g. all dependencies installed from the said code is dynamically loaded, e.g., all dependencies installed from the
npm registry. npm registry.
The code run inherits all the privileges of the execution user. The code run inherits all the privileges of the execution user.
4. Inputs provided to it by the code it is asked to run, as it is the 4. Inputs provided to it by the code it is asked to run, as it is the
@ -135,7 +134,7 @@ In addition to addressing vulnerabilities based on the above, the project works
to avoid APIs and internal implementations that make it "easy" for application to avoid APIs and internal implementations that make it "easy" for application
code to use the APIs incorrectly in a way that results in vulnerabilities within code to use the APIs incorrectly in a way that results in vulnerabilities within
the application code itself. While we dont consider those vulnerabilities in the application code itself. While we dont consider those vulnerabilities in
Node.js itself and will not necessarily issue a CVE we do want them to be Node.js itself and will not necessarily issue a CVE, we do want them to be
reported privately to Node.js first. reported privately to Node.js first.
We often choose to work to improve our APIs based on those reports and issue We often choose to work to improve our APIs based on those reports and issue
fixes either in regular or security releases depending on how much of a risk to fixes either in regular or security releases depending on how much of a risk to
@ -173,13 +172,13 @@ the community they pose.
#### Malicious Third-Party Modules (CWE-1357) #### Malicious Third-Party Modules (CWE-1357)
* Code is trusted by Node.js, therefore any scenario that requires a malicious * Code is trusted by Node.js. Therefore any scenario that requires a malicious
third-party module cannot result in a vulnerability in Node.js. third-party module cannot result in a vulnerability in Node.js.
#### Prototype Pollution Attacks (CWE-1321) #### Prototype Pollution Attacks (CWE-1321)
* Node.js trusts the inputs provided to it by application code. * Node.js trusts the inputs provided to it by application code.
It is up to the application to sanitize appropriately, therefore any scenario It is up to the application to sanitize appropriately. Therefore any scenario
that requires control over user input is not considered a vulnerability. that requires control over user input is not considered a vulnerability.
#### Uncontrolled Search Path Element (CWE-427) #### Uncontrolled Search Path Element (CWE-427)
@ -205,8 +204,8 @@ the community they pose.
* Corepack defaults to downloading the latest version of the software requested * Corepack defaults to downloading the latest version of the software requested
by the user, or a specific version requested by the user. For this reason, by the user, or a specific version requested by the user. For this reason,
Node.js releases won't be affected by such vulnerabilities, users are Node.js releases won't be affected by such vulnerabilities. Users are
responsible to keep the software they use through Corepack up-to-date. responsible for keeping the software they use through Corepack up-to-date.
## Assessing experimental features reports ## Assessing experimental features reports