From 1461f863bb4ee81ea6fe5b275e52a03c1f43bd7f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 5 Mar 2025 22:36:48 +0100 Subject: [PATCH 01/24] docs: add document to handle security reports --- docs/handle_security_reports.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 docs/handle_security_reports.md diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md new file mode 100644 index 0000000..b0598ec --- /dev/null +++ b/docs/handle_security_reports.md @@ -0,0 +1,11 @@ +# Security Report Handling Process +**Version:** 1.0 +**Last Updated:** March 2025 +**Maintainers:** Security Triage Team + +## Introduction +Security is a top priority for the Express.js project. This document outlines the **formal process** for handling **security reports**, including how to **triage**, **assess**, and **disclose** vulnerabilities responsibly. + +## Scope + +The Security Triage Team will use this document as a process guide when a security vulnerability is reported, from triage to resolution. This process must align with the project's [SECURITY policy](https://github.com/expressjs/.github/blob/master/SECURITY.md) and cannot diverge significantly. From c30511c4a409ae2cb9621e417f4b5564130808e4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 5 Mar 2025 22:37:11 +0100 Subject: [PATCH 02/24] docs: add Security Report Handling Flowchart --- docs/handle_security_reports.md | 45 +++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index b0598ec..2b79130 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -9,3 +9,48 @@ Security is a top priority for the Express.js project. This document outlines th ## Scope The Security Triage Team will use this document as a process guide when a security vulnerability is reported, from triage to resolution. This process must align with the project's [SECURITY policy](https://github.com/expressjs/.github/blob/master/SECURITY.md) and cannot diverge significantly. + + +## Security Report Handling Flowchart +The following diagram details the **decision-making process** for handling security reports: + +```mermaid +flowchart TD + A[Security Report Received] --> B[Assign Security Report Coordinator] + B --> E{Premature Disclosure?} + + E -- No --> J[Proceed with Standard Private Process] + E -- Yes --> F[Privatize Disclosure] + F --> G[Handle Related PRs & Issues] + G --> H[Request GitHub to Remove Public PR/Issues] + H --> I[Create Public Placeholder Issue] + I --> J[Acknowledge within 5 days to the Reporter] + J --> K[Create Issue in Triage Repo for Visibility] + + K --> L[Assess Report] + L --> M{Enough Information?} + + M -- No --> N[Request Additional Info] + N --> L[Assess Report] + + M -- Yes --> O{Valid Vulnerability?} + O -- No --> X[Close Report as Invalid] + X --> Y[Acknowledge within 10 days to the Reporter] + + O -- Yes --> Q[Create Advisory] + Q --> Q1[Calculate CVSS Score] + Q1 --> Q2[Request a CVE] + + Q2 --> R{Patch Required?} + + R -- No --> Z[Public Disclosure] + + R -- Yes --> T[Develop Patch] + T --> U[Test Solution] + U --> V[Add Regression Testing] + V --> W[Create a Security Release with CVE Included] + W --> Z[Public Disclosure] + Z --> Z1[Notify Community] + Z1 --> Z2[Official Blog Post] + Z1 --> Z3[Social Media Announcements] +``` From 1a9042ad3573bff1c058d4214f87a9551ed52296 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Fri, 7 Mar 2025 14:31:39 +0100 Subject: [PATCH 03/24] docs: add roles --- docs/handle_security_reports.md | 52 +++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 2b79130..1789a3d 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -54,3 +54,55 @@ flowchart TD Z1 --> Z2[Official Blog Post] Z1 --> Z3[Social Media Announcements] ``` + +## Roles & Responsibilities + +### Reporter + +This person submits a security report to the Security Triage Team and provides detailed information about the suspected vulnerability. It is expected that the reporter will cooperate with the Security Triage Team during this process and follows responsible disclosure guidelines. + +**Responsibilities** +- Submit a security report to the Security Triage Team. + +**Expectations** +- Provide detailed information about the suspected vulnerability. +- Follow responsible disclosure guidelines (report privately before public disclosure). +- Cooperate with the security team by providing additional details when needed. +- Test and verify patches (when applicable). +- Respect security timelines and avoid premature public disclosure. + +### Security Report Coordinator + + +This person acts the focal point for an specific security report and ensures the report follows all responsible disclosure guidelines, also coordinates the remediation process if a vulnerability is confirmed. + +**Responsibilities** +- Acknowledge receipt of security reports within the required timeframe. +- Assign an Analyst to assess and validate the report. +- Ensure communication with the reporter throughout the process. +- Coordinate the remediation process if a vulnerability is confirmed. +- Oversee the advisory & CVE request process if applicable. +- Escalate critical vulnerabilities when necessary. +- Track all security reports for visibility and reporting. + +**Requirements** +- Must be a member of the Security Triage Team. + + +### Security Analyst + +**Responsibilities** +- Assess the security report and determine its severity. +- Validate the reported vulnerability against best practices. +- Identify potential mitigation strategies. +- Prepare a report for the Security Report Coordinator. + + +### Remediation Developer + +**Responsibilities** +- Develop a patch or solution based on the reported vulnerability. +- Ensure the patch follows best practices and is testable. +- Test the patch to ensure it works as expected. +- Create a pull request to merge the patch into the project. + From 7aac07b5080bfc1a286f2be17f77f45714f41681 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Fri, 7 Mar 2025 15:39:12 +0100 Subject: [PATCH 04/24] docs: add runbook --- docs/handle_security_reports.md | 61 ++++++++++++++++++++++++++++++--- 1 file changed, 57 insertions(+), 4 deletions(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 1789a3d..15953f2 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -71,10 +71,10 @@ This person submits a security report to the Security Triage Team and provides d - Test and verify patches (when applicable). - Respect security timelines and avoid premature public disclosure. -### Security Report Coordinator +### Security Report Coordinator (SRC) -This person acts the focal point for an specific security report and ensures the report follows all responsible disclosure guidelines, also coordinates the remediation process if a vulnerability is confirmed. +This person acts the focal point for an specific security report and ensures the report follows all responsible disclosure guidelines, also coordinates the remediation process if a vulnerability is confirmed. The SRC ensures that the security report follows the process and coordinates necessary actions, but does not perform analysis, remediation, or patching themselves. **Responsibilities** - Acknowledge receipt of security reports within the required timeframe. @@ -92,12 +92,12 @@ This person acts the focal point for an specific security report and ensures the ### Security Analyst **Responsibilities** -- Assess the security report and determine its severity. +- Validating proof-of-concept exploits +- Assess the security report and determine its severity (assist in CVSS). - Validate the reported vulnerability against best practices. - Identify potential mitigation strategies. - Prepare a report for the Security Report Coordinator. - ### Remediation Developer **Responsibilities** @@ -106,3 +106,56 @@ This person acts the focal point for an specific security report and ensures the - Test the patch to ensure it works as expected. - Create a pull request to merge the patch into the project. +## Runbook + +The following sections outline the **step-by-step process**, explaining each decision, scenario, and possible actions. In this guide we also include links that are private (limited to the security triage team), a general overview of the process in flowchart format can be found [here](#security-report-handling-flowchart). + +### Step 0: Security Report Received + +A security vulnerability report is received via [official channels](https://github.com/expressjs/.github/blob/master/SECURITY.md#reporting-a-bug) or otherwise (i.e. via third-party advisory services, blog post, social media, etc.). + +Ideally, the report must contain **clear and detailed information** like (Affected versions, steps to reproduce, expected vs. actual behavior, potential impact...) but this might not be the case depending on the communication channel used. Later on we will try to collect this information and refine the report. + +### Step 1: Assign Security Report Coordinator (SRC) and consolidate the report + +1.1 One person from the Security Triage Team will volunteer and self-assign to oversee the case. It is expected that the person will remain assigned until the end of the process, so they effectively take the rol of [the Security Report Coordinator (SRC)](#security-report-coordinator-src). + +1.2 If the report was created accidentally or intentionally in a public channel (e.g. GitHub issues), it is important to share this information asap in the private slack channel `#express-security-triage` so the Security triage team is aware of it. At this stage, our priority is to remove the report from public view as soon as possible and let the reporter know what happened next. + +1.2.1 In the case of a report made public in a Pull request or issue under the Express organizations ownership the following process will be followed (by a Express TC member - due permissions level): + + * Move the issue to the private repository called [expressjs/security-triage](https://github.com/expressjs/security-triage). + * For any related pull requests, create an associated issue in [expressjs/security-triage](https://github.com/expressjs/security-triage) repository. Add a copy of the patch for the pull request to the issue. Add screenshots of discussion from the pull request to the issue. + * [Open a ticket with GitHub](https://support.github.com/contact) to delete the pull request using Expressjs (team) as the account organization. + * Open a new issue in the public repository with the title `FYI - pull request deleted #YYYY`. Include an explanation for the user: + > FYI @xxxx we asked GitHub to delete your pull request while we work on releases in private. + * Update the the team in the slack channel #express-security-triage`. + +1.2.2 In the case that the report is made public in a different channel that we don't own/control is expected from the TC to find ways (when possible) to mitigate this by treying to remove the report from public view (reporting to support, asking the reporter to remove the report, etc...). + + +1.3 At this stage the Security Report Coordinator (SRC) will create a (private) issue in [expressjs/security-triage](https://github.com/expressjs/security-triage) repository with the existing information from the security report (example: [expressjs/security-triage#14](https://github.com/expressjs/security-triage/issues/14)) unless it already exists (step 1.2.1). This issue will serve as the central discussion point for this particular report. At this stage is expected from the Security Report Coordinator (SRC) to acknowledge receipt of the security report to the reporter. + +Note: It is expected that the issue will be assigned to the Security Report Coordinator (SRC) and will remain open until the end of the process. + +### Step 2: Review the Report and determine its severity + +2.1 It is expected from the security triage team to review the report and determine its severity, also evaluating the impact on the project(s). In some cases the report might be too vague to properly determine its severity. In this case the Security Report Coordinator (SRC) will need to reach out to the reporter for more information and refine the report. + +2.2 At this stage we are capable of determining the severity of the report based on the information provided and also if the report is still relevant. In case that the team has considered the report to be irrelevant or not valid, the Security Report Coordinator (SRC) will need to close the issue and inform the reporter that the report has been dismissed, ideally we can provide a reason for dismissal to prevent the report from being resubmitted within the project(s) in the future. + +2.3 If the report is considered relevant and valid, the Security Report Coordinator (SRC) will create an advisory and request a CVE number. The Security Report Coordinator (SRC) will also include the remediation developer(s), analyst(s) and potentially the reporter in the advisory, so they can start to work on private fork to fix the security issue (example: [GHSA-qw6h-vgh9-j6wx](https://github.com/expressjs/express/security/advisories/GHSA-qw6h-vgh9-j6wx)). + +### Step 3: Patch and release + +3.1 The security triage team will determine if this vulnerability will be patched and work on it. In case that the vulnerability won't be patched jump to step 4. +3.2 The mitigation team (remediation developer(s), analyst(s), reporter(s)) will work on the patch(es), re-evaluate the report once the patch is ready and include regression tests (when possible). +3.3 The Express TC will announce publicly (social media and public issues) that there is security path available and the plan to do a release with an specific date (ideally) and the versions affected without providing additional information to prevent early disclosure. +3.4 The security triage, repo captain(s) and TC team will create the releases and publish them to npm. In some cases one vulnerability can affect multiple packages requiring several coordinated releases. + + +### Step 4: Public disclosure + +4.1 At this stage the Security Report Coordinator (SRC) will make the advisory public and close the coordination issue (opened in step 1). +4.2 The Security Report Coordinator (SRC) will also help to publish a blog post about the vulnerability and the patch (if applicable, example [September 2024 Security Releases](https://expressjs.com/2024/09/29/security-releases.html)). +4.3 The TC team will do social media announcements about the vulnerability and the patch (if applicable, example [Tweet post](https://x.com/UseExpressJS/status/1772300472730198037)). From 03d7b60d5acea55af0faaf59f2ea1813dd8e485f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Sat, 8 Mar 2025 12:31:42 +0100 Subject: [PATCH 05/24] Update docs/handle_security_reports.md Co-authored-by: Sebastian Beltran --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 15953f2..dcdc580 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -129,7 +129,7 @@ Ideally, the report must contain **clear and detailed information** like (Affect * [Open a ticket with GitHub](https://support.github.com/contact) to delete the pull request using Expressjs (team) as the account organization. * Open a new issue in the public repository with the title `FYI - pull request deleted #YYYY`. Include an explanation for the user: > FYI @xxxx we asked GitHub to delete your pull request while we work on releases in private. - * Update the the team in the slack channel #express-security-triage`. + * Update the team in the slack channel #express-security-triage`. 1.2.2 In the case that the report is made public in a different channel that we don't own/control is expected from the TC to find ways (when possible) to mitigate this by treying to remove the report from public view (reporting to support, asking the reporter to remove the report, etc...). From dba71a6d075179fe1985c2529a993688eecfdac4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Sat, 8 Mar 2025 12:32:22 +0100 Subject: [PATCH 06/24] Update docs/handle_security_reports.md Co-authored-by: Sebastian Beltran --- docs/handle_security_reports.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index dcdc580..d53544d 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -136,7 +136,8 @@ Ideally, the report must contain **clear and detailed information** like (Affect 1.3 At this stage the Security Report Coordinator (SRC) will create a (private) issue in [expressjs/security-triage](https://github.com/expressjs/security-triage) repository with the existing information from the security report (example: [expressjs/security-triage#14](https://github.com/expressjs/security-triage/issues/14)) unless it already exists (step 1.2.1). This issue will serve as the central discussion point for this particular report. At this stage is expected from the Security Report Coordinator (SRC) to acknowledge receipt of the security report to the reporter. -Note: It is expected that the issue will be assigned to the Security Report Coordinator (SRC) and will remain open until the end of the process. +> [!Note] +> It is expected that the issue will be assigned to the Security Report Coordinator (SRC) and will remain open until the end of the process. ### Step 2: Review the Report and determine its severity From 99b410244a075b454f2d14d27f7c805e23a8d4c3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Sat, 8 Mar 2025 12:32:33 +0100 Subject: [PATCH 07/24] Update docs/handle_security_reports.md Co-authored-by: Sebastian Beltran --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index d53544d..b01afd8 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -152,7 +152,7 @@ Ideally, the report must contain **clear and detailed information** like (Affect 3.1 The security triage team will determine if this vulnerability will be patched and work on it. In case that the vulnerability won't be patched jump to step 4. 3.2 The mitigation team (remediation developer(s), analyst(s), reporter(s)) will work on the patch(es), re-evaluate the report once the patch is ready and include regression tests (when possible). 3.3 The Express TC will announce publicly (social media and public issues) that there is security path available and the plan to do a release with an specific date (ideally) and the versions affected without providing additional information to prevent early disclosure. -3.4 The security triage, repo captain(s) and TC team will create the releases and publish them to npm. In some cases one vulnerability can affect multiple packages requiring several coordinated releases. +3.4 The security triage, along with the repo captain(s) and the TC team, will create the releases and publish them to npm. In some cases one vulnerability can affect multiple packages requiring several coordinated releases. ### Step 4: Public disclosure From 054ab8a04a129f45fed98000cc8e93db7d51b1ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Sat, 8 Mar 2025 12:35:27 +0100 Subject: [PATCH 08/24] fix: format issues --- docs/handle_security_reports.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index b01afd8..bfb3ee4 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -150,13 +150,18 @@ Ideally, the report must contain **clear and detailed information** like (Affect ### Step 3: Patch and release 3.1 The security triage team will determine if this vulnerability will be patched and work on it. In case that the vulnerability won't be patched jump to step 4. + 3.2 The mitigation team (remediation developer(s), analyst(s), reporter(s)) will work on the patch(es), re-evaluate the report once the patch is ready and include regression tests (when possible). + 3.3 The Express TC will announce publicly (social media and public issues) that there is security path available and the plan to do a release with an specific date (ideally) and the versions affected without providing additional information to prevent early disclosure. + 3.4 The security triage, along with the repo captain(s) and the TC team, will create the releases and publish them to npm. In some cases one vulnerability can affect multiple packages requiring several coordinated releases. ### Step 4: Public disclosure 4.1 At this stage the Security Report Coordinator (SRC) will make the advisory public and close the coordination issue (opened in step 1). + 4.2 The Security Report Coordinator (SRC) will also help to publish a blog post about the vulnerability and the patch (if applicable, example [September 2024 Security Releases](https://expressjs.com/2024/09/29/security-releases.html)). + 4.3 The TC team will do social media announcements about the vulnerability and the patch (if applicable, example [Tweet post](https://x.com/UseExpressJS/status/1772300472730198037)). From 707c04de299203e2e1f36b439275c104d6e47303 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:33:19 +0200 Subject: [PATCH 09/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index bfb3ee4..e3e20c4 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -4,7 +4,7 @@ **Maintainers:** Security Triage Team ## Introduction -Security is a top priority for the Express.js project. This document outlines the **formal process** for handling **security reports**, including how to **triage**, **assess**, and **disclose** vulnerabilities responsibly. +Security is a top priority for the Express project. This document outlines the **formal process** for handling **security reports**, including how to **triage**, **assess**, and **disclose** vulnerabilities responsibly. ## Scope From eec7b045f10e992fffcc8eaa8bab29fcc3706eeb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:34:08 +0200 Subject: [PATCH 10/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index e3e20c4..ef99fbb 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -71,7 +71,7 @@ This person submits a security report to the Security Triage Team and provides d - Test and verify patches (when applicable). - Respect security timelines and avoid premature public disclosure. -### Security Report Coordinator (SRC) +### Coordinator This person acts the focal point for an specific security report and ensures the report follows all responsible disclosure guidelines, also coordinates the remediation process if a vulnerability is confirmed. The SRC ensures that the security report follows the process and coordinates necessary actions, but does not perform analysis, remediation, or patching themselves. From de83da81df8275f6c4ca048ed69038929c9774f0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:36:47 +0200 Subject: [PATCH 11/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index ef99fbb..92adeea 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -89,7 +89,7 @@ This person acts the focal point for an specific security report and ensures the - Must be a member of the Security Triage Team. -### Security Analyst +### Analyst **Responsibilities** - Validating proof-of-concept exploits From e88d94db64de681b38fd170764900b52caf04250 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:37:12 +0200 Subject: [PATCH 12/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 92adeea..7e49a4a 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -92,7 +92,8 @@ This person acts the focal point for an specific security report and ensures the ### Analyst **Responsibilities** -- Validating proof-of-concept exploits +- Determine if the reported issue is a real vulnerability, and is in within the scope of our [threat model](https://github.com/expressjs/security-wg/blob/main/docs/ThreatModel.md) +- Validate proof-of-concept exploits - Assess the security report and determine its severity (assist in CVSS). - Validate the reported vulnerability against best practices. - Identify potential mitigation strategies. From ee83fa1f1d6741878220039d657c58730370c0f0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:37:22 +0200 Subject: [PATCH 13/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 7e49a4a..6d6527b 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -96,7 +96,7 @@ This person acts the focal point for an specific security report and ensures the - Validate proof-of-concept exploits - Assess the security report and determine its severity (assist in CVSS). - Validate the reported vulnerability against best practices. -- Identify potential mitigation strategies. +- Identify potential mitigation strategies and workarounds. - Prepare a report for the Security Report Coordinator. ### Remediation Developer From 799e8889249da8992ada1e37b549256d364a686e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:38:35 +0200 Subject: [PATCH 14/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 6d6527b..d99647c 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -104,6 +104,7 @@ This person acts the focal point for an specific security report and ensures the **Responsibilities** - Develop a patch or solution based on the reported vulnerability. - Ensure the patch follows best practices and is testable. +- Add test(s) to the existing test suite to confirm the vulnerability (pre-patch) and confirm the fix (post-patch). - Test the patch to ensure it works as expected. - Create a pull request to merge the patch into the project. From 315b02c38103a892f7f51cf1c32d398a5172fd91 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:38:54 +0200 Subject: [PATCH 15/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index d99647c..b3313a3 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -133,7 +133,7 @@ Ideally, the report must contain **clear and detailed information** like (Affect > FYI @xxxx we asked GitHub to delete your pull request while we work on releases in private. * Update the team in the slack channel #express-security-triage`. -1.2.2 In the case that the report is made public in a different channel that we don't own/control is expected from the TC to find ways (when possible) to mitigate this by treying to remove the report from public view (reporting to support, asking the reporter to remove the report, etc...). +1.2.2 In the case that the report is made public in a different channel that we don't own/control, the TC will attempt to mitigate this by trying to remove the report from public view (reporting to support, asking the reporter to remove the report, etc...). 1.3 At this stage the Security Report Coordinator (SRC) will create a (private) issue in [expressjs/security-triage](https://github.com/expressjs/security-triage) repository with the existing information from the security report (example: [expressjs/security-triage#14](https://github.com/expressjs/security-triage/issues/14)) unless it already exists (step 1.2.1). This issue will serve as the central discussion point for this particular report. At this stage is expected from the Security Report Coordinator (SRC) to acknowledge receipt of the security report to the reporter. From 183adc6dfe62be735f92261cd96b7e34ca9ba202 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:39:25 +0200 Subject: [PATCH 16/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index b3313a3..8b7631d 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -124,7 +124,7 @@ Ideally, the report must contain **clear and detailed information** like (Affect 1.2 If the report was created accidentally or intentionally in a public channel (e.g. GitHub issues), it is important to share this information asap in the private slack channel `#express-security-triage` so the Security triage team is aware of it. At this stage, our priority is to remove the report from public view as soon as possible and let the reporter know what happened next. -1.2.1 In the case of a report made public in a Pull request or issue under the Express organizations ownership the following process will be followed (by a Express TC member - due permissions level): +1.2.1 In the case of a report made public in a Pull request or issue under the Express organizations ownership the following process will be followed (by an Express TC member): * Move the issue to the private repository called [expressjs/security-triage](https://github.com/expressjs/security-triage). * For any related pull requests, create an associated issue in [expressjs/security-triage](https://github.com/expressjs/security-triage) repository. Add a copy of the patch for the pull request to the issue. Add screenshots of discussion from the pull request to the issue. From 014a4b1a07c3b0deb8b8326472e4c08efe35f5c4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:39:35 +0200 Subject: [PATCH 17/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 8b7631d..f798ef2 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -122,7 +122,7 @@ Ideally, the report must contain **clear and detailed information** like (Affect 1.1 One person from the Security Triage Team will volunteer and self-assign to oversee the case. It is expected that the person will remain assigned until the end of the process, so they effectively take the rol of [the Security Report Coordinator (SRC)](#security-report-coordinator-src). -1.2 If the report was created accidentally or intentionally in a public channel (e.g. GitHub issues), it is important to share this information asap in the private slack channel `#express-security-triage` so the Security triage team is aware of it. At this stage, our priority is to remove the report from public view as soon as possible and let the reporter know what happened next. +1.2 If the report was created accidentally or intentionally in a public channel (e.g. GitHub issues), it is important to share this information ASAP in the private slack channel `#express-security-triage` so the Security triage team is aware of it. At this stage, our priority is to remove the report from public view as soon as possible and let the reporter know what happened next. 1.2.1 In the case of a report made public in a Pull request or issue under the Express organizations ownership the following process will be followed (by an Express TC member): From fbc2d2c0541315522ed9b23f8cdd6bc8642a1593 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:40:06 +0200 Subject: [PATCH 18/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index f798ef2..047bb27 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -120,7 +120,7 @@ Ideally, the report must contain **clear and detailed information** like (Affect ### Step 1: Assign Security Report Coordinator (SRC) and consolidate the report -1.1 One person from the Security Triage Team will volunteer and self-assign to oversee the case. It is expected that the person will remain assigned until the end of the process, so they effectively take the rol of [the Security Report Coordinator (SRC)](#security-report-coordinator-src). +1.1 One person from the Security Triage Team will volunteer and self-assign to oversee the case. It is expected that the person will remain assigned until the end of the process, so they effectively take the role of [the Security Report Coordinator (SRC)](#security-report-coordinator-src). 1.2 If the report was created accidentally or intentionally in a public channel (e.g. GitHub issues), it is important to share this information ASAP in the private slack channel `#express-security-triage` so the Security triage team is aware of it. At this stage, our priority is to remove the report from public view as soon as possible and let the reporter know what happened next. From fa6bf1be371f6ddcfc5548a786767ab857207404 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:40:17 +0200 Subject: [PATCH 19/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 047bb27..4076fcf 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -116,7 +116,7 @@ The following sections outline the **step-by-step process**, explaining each dec A security vulnerability report is received via [official channels](https://github.com/expressjs/.github/blob/master/SECURITY.md#reporting-a-bug) or otherwise (i.e. via third-party advisory services, blog post, social media, etc.). -Ideally, the report must contain **clear and detailed information** like (Affected versions, steps to reproduce, expected vs. actual behavior, potential impact...) but this might not be the case depending on the communication channel used. Later on we will try to collect this information and refine the report. +Ideally, the report must contain **clear and detailed information** like (Affected versions, a small PoC/sample project demonstrating the issue, steps to reproduce, expected vs. actual behavior, potential impact...) but this might not be the case depending on the communication channel used. Later on we will try to collect this information and refine the report. ### Step 1: Assign Security Report Coordinator (SRC) and consolidate the report From 6bb67004b9250df1ddcdd1fa60012b7c666f5ae4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Wed, 2 Apr 2025 20:40:48 +0200 Subject: [PATCH 20/24] Update docs/handle_security_reports.md Co-authored-by: Chris de Almeida --- docs/handle_security_reports.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 4076fcf..9c07e12 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -78,6 +78,8 @@ This person acts the focal point for an specific security report and ensures the **Responsibilities** - Acknowledge receipt of security reports within the required timeframe. +- Orchestrate the embargo and identify the minimum set of individuals involved. + - Remind everyone involved that they must not notify/involve any other individuals. If someone else needs to be involved, that must go through the Coordinator. - Assign an Analyst to assess and validate the report. - Ensure communication with the reporter throughout the process. - Coordinate the remediation process if a vulnerability is confirmed. From 0241b7ce4f831d814343e51e67a36eefe433c4ac Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 22 Apr 2025 09:42:16 +0200 Subject: [PATCH 21/24] Update docs/handle_security_reports.md --- docs/handle_security_reports.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 9c07e12..431df19 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -129,8 +129,11 @@ Ideally, the report must contain **clear and detailed information** like (Affect 1.2.1 In the case of a report made public in a Pull request or issue under the Express organizations ownership the following process will be followed (by an Express TC member): * Move the issue to the private repository called [expressjs/security-triage](https://github.com/expressjs/security-triage). - * For any related pull requests, create an associated issue in [expressjs/security-triage](https://github.com/expressjs/security-triage) repository. Add a copy of the patch for the pull request to the issue. Add screenshots of discussion from the pull request to the issue. + * For any related pull requests, create an associated issue in [expressjs/security-triage](https://github.com/expressjs/security-triage) repository. Add a copy of the patch for the pull request to the issue. Add screenshots of discussion from the pull request to the issue. * [Open a ticket with GitHub](https://support.github.com/contact) to delete the pull request using Expressjs (team) as the account organization. + * Force-push to the PR branch to overwrite the code with a placeholder commit (if "allow edits by maintainers" is enabled). This ensures sensitive information is removed immediately. + * In the PR comments, notify the author about the force-push and explain the reason: + > FYI @xxxx, we force-pushed to your branch to remove sensitive information while we work on releases in private. * Open a new issue in the public repository with the title `FYI - pull request deleted #YYYY`. Include an explanation for the user: > FYI @xxxx we asked GitHub to delete your pull request while we work on releases in private. * Update the team in the slack channel #express-security-triage`. From 2544711d100fd6b7457873ff68c8e3ebb5f6ebc5 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 22 Apr 2025 09:44:57 +0200 Subject: [PATCH 22/24] Update docs/handle_security_reports.md --- docs/handle_security_reports.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 431df19..1355046 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -122,7 +122,10 @@ Ideally, the report must contain **clear and detailed information** like (Affect ### Step 1: Assign Security Report Coordinator (SRC) and consolidate the report -1.1 One person from the Security Triage Team will volunteer and self-assign to oversee the case. It is expected that the person will remain assigned until the end of the process, so they effectively take the role of [the Security Report Coordinator (SRC)](#security-report-coordinator-src). +1.1 One person from the Security Triage Team will volunteer and self-assign to oversee the case. It is expected that the person will remain assigned until the end of the process, so they effectively take the role of [the Security Report Coordinator (SRC)](#security-report-coordinator-src). + +> [!Note] +> While this document refers to a single SRC for simplicity, in practice, having two coordinators is acceptable and often beneficial. A second coordinator can assist with tasks such as reviewing the advisory content before it is published, ensuring accuracy and completeness. 1.2 If the report was created accidentally or intentionally in a public channel (e.g. GitHub issues), it is important to share this information ASAP in the private slack channel `#express-security-triage` so the Security triage team is aware of it. At this stage, our priority is to remove the report from public view as soon as possible and let the reporter know what happened next. From 38b6532f0ce54615991273974ed2d01471a7e1ca Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 22 Apr 2025 09:47:42 +0200 Subject: [PATCH 23/24] Update docs/handle_security_reports.md --- docs/handle_security_reports.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 1355046..38f7159 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -73,8 +73,7 @@ This person submits a security report to the Security Triage Team and provides d ### Coordinator - -This person acts the focal point for an specific security report and ensures the report follows all responsible disclosure guidelines, also coordinates the remediation process if a vulnerability is confirmed. The SRC ensures that the security report follows the process and coordinates necessary actions, but does not perform analysis, remediation, or patching themselves. +This person acts as the focal point for a specific security report and ensures the report follows all responsible disclosure guidelines. The SRC coordinates the remediation process if a vulnerability is confirmed and ensures that the security report follows the process and necessary actions are taken. While the SRC is not necessarily responsible for performing analysis, remediation, or patching, they may take on these tasks if they also hold the role of Analyst or Remediation Developer. **Responsibilities** - Acknowledge receipt of security reports within the required timeframe. From 8c09fbb7eaec927b367c9957feb580e8fa6b8d19 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 22 Apr 2025 09:50:21 +0200 Subject: [PATCH 24/24] Update docs/handle_security_reports.md --- docs/handle_security_reports.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/docs/handle_security_reports.md b/docs/handle_security_reports.md index 38f7159..28ec67d 100644 --- a/docs/handle_security_reports.md +++ b/docs/handle_security_reports.md @@ -57,9 +57,21 @@ flowchart TD ## Roles & Responsibilities +### Finder + +This person identifies a potential security vulnerability in the project. The Finder may or may not be the same person as the Reporter. If the Finder is not the Reporter, they may share the details with someone else who submits the report to the Security Triage Team. + +**Responsibilities** +- Identify potential security vulnerabilities in the project. +- Share sufficient details about the vulnerability with the Reporter or directly with the Security Triage Team. + +**Expectations** +- Follow responsible disclosure guidelines by ensuring the vulnerability is reported privately before public disclosure. +- Provide clear and accurate information about the vulnerability to facilitate the reporting process. + ### Reporter -This person submits a security report to the Security Triage Team and provides detailed information about the suspected vulnerability. It is expected that the reporter will cooperate with the Security Triage Team during this process and follows responsible disclosure guidelines. +This person submits a security report to the Security Triage Team and provides detailed information about the suspected vulnerability. It is expected that the Reporter will cooperate with the Security Triage Team during this process and follow responsible disclosure guidelines. **Responsibilities** - Submit a security report to the Security Triage Team.