chore(security): upgrade reporting policy (#8083)

* chore(security): upgrade reporting policy

Signed-off-by: Aviv Keller <me@aviv.sh>

* Update apps/site/pages/en/about/security-reporting.mdx

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Signed-off-by: Aviv Keller <me@aviv.sh>

---------

Signed-off-by: Aviv Keller <me@aviv.sh>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Author: avivkeller

apps/site/pages/en/about/security-reporting.mdx

@@ -11,9 +11,11 @@ For more details on active Security Policies, checkout [this page](https://githu
 
 Report security bugs in Node.js via [HackerOne](https://hackerone.com/nodejs).
 
-Your report will be acknowledged within 5 days, and you'll receive a more
-detailed response to your report within 10 days indicating the next steps in
-handling your submission.
+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
+next steps in handling your submission. These timelines may extend when
+our triage volunteers are away on holiday, particularly at the end of the
+year.
 
 After the initial reply to your report, the security team will endeavor to keep
 you informed of the progress being made towards a fix and full announcement,
@@ -36,29 +38,29 @@ maintainers.
 Here is the security disclosure policy for Node.js
 
 - The security report is received and is assigned a primary handler. This
-  person will coordinate the fix and release process. The problem is confirmed
-  and a list of all affected versions is determined. Code is audited to find
-  any potential similar problems. Fixes are prepared for all releases which are
-  still under maintenance. These fixes are not committed to the public
-  repository but rather held locally pending the announcement.
+  person will coordinate the fix and release process. The problem is validated
+  against all supported Node.js versions. Once confirmed, a list of all affected
+  versions is determined. Code is audited to find any potential similar
+  problems. Fixes are prepared for all supported releases.
+  These fixes are not committed to the public repository but rather held locally
+  pending the announcement.
 
 - A suggested embargo date for this vulnerability is chosen and a CVE (Common
   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
-  announcement. The changes are pushed to the public repository and new builds
-  are deployed to nodejs.org. Within 6 hours of the mailing list being
+- On the embargo date, a copy of the announcement is sent to the Node.js
+  security mailing list. The changes are pushed to the public repository and new
+  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.
 
-- 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
   difficulty in applying a fix.
 
-- This process can take some time, especially when coordination is required
-  with maintainers of other projects. Every effort will be made to handle the
-  bug in as timely a manner as possible; however, it's important that we follow
-  the release process above to ensure that the disclosure is handled in a
-  consistent manner.
+- This process can take some time, especially when we need to coordinate with
+  maintainers of other projects. We will try to handle the bug as quickly as
+  possible; however, we must follow the release process above to ensure that we
+  handle disclosure consistently.
 
 ## Receiving security updates
 
@@ -69,9 +71,9 @@ Security notifications will be distributed via the following methods.
 
 ## Comments on this policy
 
-If you have suggestions on how this process could be improved please submit a
-[pull request](https://github.com/nodejs/nodejs.org) or
-[file an issue](https://github.com/nodejs/security-wg/issues/new) to discuss.
+If you have suggestions on how this process could be improved, please visit
+the [nodejs/security-wg](https://github.com/nodejs/security-wg)
+repository.
 
 ## OpenSSF Best Practices