From 7609ae29e3fdcd2c0f1b27a59874297efd78b248 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 12 Aug 2025 18:46:35 +0200 Subject: [PATCH 01/14] docs: add the incident response plan (IRP) --- incident-response-plan.md | 137 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 incident-response-plan.md diff --git a/incident-response-plan.md b/incident-response-plan.md new file mode 100644 index 0000000..cffedf2 --- /dev/null +++ b/incident-response-plan.md @@ -0,0 +1,137 @@ +# Incident Response Plan + +## Purpose +This document outlines the process for handling security-impacting incidents affecting one or more projects in the Foundation’s ecosystem. Incidents may include platform changes with security implications, account compromise, or other security events that require coordinated response. + +The Foundation’s role is to: +1. **Receive and triage reports** +2. **Connect reporters and affected maintainers with the right experts** +3. **Facilitate coordinated response** across multiple projects when needed +4. **Communicate clearly and act as the contact point** while respecting confidentiality and responsible disclosure principles + +--- + +## Scope + +This plan covers incidents such as: +- **Platform changes or providers outages** (e.g., GitHub UI change) that create security or operational risk. +- **Account or registry access issues** (e.g., npm lockdown, compromised maintainer account). +- **Supply chain attacks** (e.g. XZ, phishing campaign, etc.. ) +- **Third-party service compromises** affecting Foundation projects (e.g., data leaks in external services) +- **Legal-related operational threats**, including: + - License disputes (e.g., GPL/MIT compliance challenges) + - Patent-related threats impacting project distribution + - DMCA takedown requests + - Trademark misuse or brand impersonation + + +Incidents that are not in scope: +- **Code-level security vulnerabilities** in projects maintained within the Foundation (handled by the project or the OpenJS CNA Team) +- **Non-Foundation projects** — see the [list of supported projects](https://openjsf.org/projects) + +--- + +### Incident Categories + +- 🍿 @Discussion: Probably we can think on more scenarios together + + +| Category | Examples | Primary Response Role | +|----------|----------|-----------------------| +| **Vulnerability Report** | Code exploit, CVE disputes, escalations... | Redirect to the project or delegate to the CNA Team | +| **Platform Change Risk** | GitHub UI update causing accidental info exposure | Triage → Escalate to platform contacts → Provide mitigations | +| **Account Access Issue** | npm account lockout, GitHub MFA issues | Triage → Help restore access via platform → Provide temporary mitigation | +| **Supply Chain Attack** | Malicious dependency version | Coordinate with affected projects → Security advisories | +| **External Incident Impact** | Cloud provider compromise, service outage | Facilitate communication between impacted maintainers and providers | + +--- + + +## Action plan + +We may not directly solve incidents, but we help **unblock situations** and **support projects at risk**. + +### Roles & Responsibilities + +- 🍿 @Discussion: who should be in the team? +- 🍿 @Discussion: what is the right name for the team ("THE TEAM")? +- 🍿 @Discussion: what is the right name for the report ("THE REPORT")? +- 🍿 @Discussion: Should we publish the learning/findings when possible publickly to help the community? + +#### Reporter + +This person submits A REPORT to THE TEAM and provides detailed information about the incident. + +**Responsibilities** + +- Submit A REPORT to THE TEAM. + +**Expectations** + +- Provide detailed information about the suspected vulnerability. +- Follow responsible disclosure guidelines (adapted to this context). +- Cooperate with THE TEAM by providing additional details when needed. +- Respect security timelines and avoid premature public disclosure. + + + +#### Coordinator (SRC) + +This person acts as the focal point for a specific REPORT and ensures the report follows all responsible disclosure guidelines. The SRC coordinates the remediation process if the situation is confirmed and ensures that THE REPORT follows the process and necessary actions are taken. While the SRC is not necessarily responsible for performing a detailed analysis or remediation. + +**Responsibilities** + +- Acknowledge receipt of 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 one or multiple SMEs. +- Ensure communication with the reporter and the affected projects throughout the process. +- Track all THE REPORTS for visibility and reporting. + +#### Subject Matter Expert (SME) +Experts brought in for technical insight, platform liaison work, or domain-specific advice. + +**Responsibilities**: +- Provide expert input to help assess impact and options +- Advise on mitigation strategies +- Help unblock the situations when feasible + +### Reporting methods + +- 🍿 @Discussion: what is the best option? + - Dedicated email alias? + - Secure web form? + + +## Runbook + +- 🍿 @Discussion: What is the best approach? Some ideas: + 1. **REPORT Received** + 2. **Assign Coordinator** and consolidate report details + 3. **Review** severity and affected projects + 4. **Identify SMEs** and brief them + 5. **Coordinate** with projects, platforms, or third parties + 6. **Document** findings and lessons learned + 7. **Publish** partial or full summary if appropriate + 8. **Social Media Team** prepare and posts where needed + +## General Response Workflow + +- 🍿 @Discussion: early-stage idea, based on the Runbook: + +```mermaid +flowchart TD + A[REPORT Received] --> B[Assign Coordinator] + B --> C{Is valid, qualified and can be verified?} + C -- No --> D[Request Clarification from Reporter] + D --> C + C -- Yes --> E[Assess Impact and Severity] + E --> F{Single Project or Multi-Project?} + F -- Single --> G[Engage Project Maintainers] + F -- Multi --> H[Engage Multiple Maintainers + Foundation Network] + G --> I[Coordinate Response: Bring SMEs...] + H --> I + I --> J[Update Reporter and Stakeholders] + J --> K[Document and Close Incident] + + From 8cf93093182f45326836f4edf7035f38dd369d1b Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Wed, 20 Aug 2025 15:33:02 +0200 Subject: [PATCH 02/14] docs: update terminology ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2274463993 --- incident-response-plan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index cffedf2..158bdaf 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -4,7 +4,7 @@ This document outlines the process for handling security-impacting incidents affecting one or more projects in the Foundation’s ecosystem. Incidents may include platform changes with security implications, account compromise, or other security events that require coordinated response. The Foundation’s role is to: -1. **Receive and triage reports** +1. **Receive and triage THE REPORTS** 2. **Connect reporters and affected maintainers with the right experts** 3. **Facilitate coordinated response** across multiple projects when needed 4. **Communicate clearly and act as the contact point** while respecting confidentiality and responsible disclosure principles From 344046d084c7ff594dd9101855241270ee5f9080 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Wed, 20 Aug 2025 15:44:12 +0200 Subject: [PATCH 03/14] docs: add initial RACI diagram ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2283321427 --- incident-response-plan.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/incident-response-plan.md b/incident-response-plan.md index 158bdaf..7200470 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -53,6 +53,22 @@ We may not directly solve incidents, but we help **unblock situations** and **su ### Roles & Responsibilities + +#### RACI Diagram + +_You can find more information about RACI in this [link](https://www.atlassian.com/work-management/project-management/raci-chart)_ + + +| Process Step | Reporter | Response Team (Foundation) | Coordinator (SRC) | SME | +|---------------------------------------|----------|-----------------------------|-------------------|-----| +| File Report | R, A | C | I | | +| Assign Coordinator | I | R | A | | +| Assess Impact & Severity | I | C | A | C | +| Identify & assign SMEs | I | C | A | C | +| Make a resolution / recommend mitigation | I | C | A | C | +| Document findings | I | C | A | I, C | +| Publish and share (if approved) | I | R, A | C | C | + - 🍿 @Discussion: who should be in the team? - 🍿 @Discussion: what is the right name for the team ("THE TEAM")? - 🍿 @Discussion: what is the right name for the report ("THE REPORT")? From 5d17d2ae98ae2e4eaeaa94519632b96938d24ab2 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 14:51:02 +0200 Subject: [PATCH 04/14] docs: add reporting method Ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2283349036 --- incident-response-plan.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index 7200470..c779c1d 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -112,11 +112,10 @@ Experts brought in for technical insight, platform liaison work, or domain-speci - Advise on mitigation strategies - Help unblock the situations when feasible -### Reporting methods +### Reporting method -- 🍿 @Discussion: what is the best option? - - Dedicated email alias? - - Secure web form? + +In [this webform](https://report-incident.openjsf.org/) is possible to create a new security report ## Runbook From 5f80e7f78c73b55a0affbd6e80a5ce7f05320478 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 14:57:17 +0200 Subject: [PATCH 05/14] docs: update team name Ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2283356897 --- incident-response-plan.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index c779c1d..f141e1f 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -70,23 +70,22 @@ _You can find more information about RACI in this [link](https://www.atlassian.c | Publish and share (if approved) | I | R, A | C | C | - 🍿 @Discussion: who should be in the team? -- 🍿 @Discussion: what is the right name for the team ("THE TEAM")? - 🍿 @Discussion: what is the right name for the report ("THE REPORT")? - 🍿 @Discussion: Should we publish the learning/findings when possible publickly to help the community? #### Reporter -This person submits A REPORT to THE TEAM and provides detailed information about the incident. +This person submits A REPORT to the Foundation Security Team and provides detailed information about the incident. **Responsibilities** -- Submit A REPORT to THE TEAM. +- Submit A REPORT to the Foundation Security Team. **Expectations** - Provide detailed information about the suspected vulnerability. - Follow responsible disclosure guidelines (adapted to this context). -- Cooperate with THE TEAM by providing additional details when needed. +- Cooperate with the Foundation Security Team by providing additional details when needed. - Respect security timelines and avoid premature public disclosure. From 06a3aca22b65e449af709584ce58cddbf4398553 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 15:01:53 +0200 Subject: [PATCH 06/14] docs: update the report name Ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2283358229 --- incident-response-plan.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index f141e1f..f16f433 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -4,7 +4,7 @@ This document outlines the process for handling security-impacting incidents affecting one or more projects in the Foundation’s ecosystem. Incidents may include platform changes with security implications, account compromise, or other security events that require coordinated response. The Foundation’s role is to: -1. **Receive and triage THE REPORTS** +1. **Receive and triage the Incident Reports** 2. **Connect reporters and affected maintainers with the right experts** 3. **Facilitate coordinated response** across multiple projects when needed 4. **Communicate clearly and act as the contact point** while respecting confidentiality and responsible disclosure principles @@ -70,16 +70,15 @@ _You can find more information about RACI in this [link](https://www.atlassian.c | Publish and share (if approved) | I | R, A | C | C | - 🍿 @Discussion: who should be in the team? -- 🍿 @Discussion: what is the right name for the report ("THE REPORT")? - 🍿 @Discussion: Should we publish the learning/findings when possible publickly to help the community? #### Reporter -This person submits A REPORT to the Foundation Security Team and provides detailed information about the incident. +This person submits an Incident Report to the Foundation Security Team and provides detailed information about the incident. **Responsibilities** -- Submit A REPORT to the Foundation Security Team. +- Submit an Incident Report to the Foundation Security Team. **Expectations** @@ -92,16 +91,16 @@ This person submits A REPORT to the Foundation Security Team and provides detail #### Coordinator (SRC) -This person acts as the focal point for a specific REPORT and ensures the report follows all responsible disclosure guidelines. The SRC coordinates the remediation process if the situation is confirmed and ensures that THE REPORT follows the process and necessary actions are taken. While the SRC is not necessarily responsible for performing a detailed analysis or remediation. +This person acts as the focal point for a specific Incident Report and ensures the report follows all responsible disclosure guidelines. The SRC coordinates the remediation process if the situation is confirmed and ensures that the Incident Report follows the process and necessary actions are taken. While the SRC is not necessarily responsible for performing a detailed analysis or remediation. **Responsibilities** -- Acknowledge receipt of REPORTS within the required timeframe. +- Acknowledge receipt of Incident 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 one or multiple SMEs. - Ensure communication with the reporter and the affected projects throughout the process. -- Track all THE REPORTS for visibility and reporting. +- Track all the Incident Reports for visibility and reporting. #### Subject Matter Expert (SME) Experts brought in for technical insight, platform liaison work, or domain-specific advice. @@ -120,7 +119,7 @@ In [this webform](https://report-incident.openjsf.org/) is possible to create a ## Runbook - 🍿 @Discussion: What is the best approach? Some ideas: - 1. **REPORT Received** + 1. **Incident Report Received** 2. **Assign Coordinator** and consolidate report details 3. **Review** severity and affected projects 4. **Identify SMEs** and brief them @@ -135,7 +134,7 @@ In [this webform](https://report-incident.openjsf.org/) is possible to create a ```mermaid flowchart TD - A[REPORT Received] --> B[Assign Coordinator] + A[Incident Report Received] --> B[Assign Coordinator] B --> C{Is valid, qualified and can be verified?} C -- No --> D[Request Clarification from Reporter] D --> C From b55d31c803ca471bd071fca8ccacf0b1a1da2236 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 15:04:32 +0200 Subject: [PATCH 07/14] chore: rewording ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2289411980 --- incident-response-plan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index f16f433..940a646 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -1,7 +1,7 @@ # Incident Response Plan ## Purpose -This document outlines the process for handling security-impacting incidents affecting one or more projects in the Foundation’s ecosystem. Incidents may include platform changes with security implications, account compromise, or other security events that require coordinated response. +This document outlines the process for handling security incidents affecting any OpenJS project. Incidents may include platform changes with security implications, account compromise, or other security events that require coordinated response. The Foundation’s role is to: 1. **Receive and triage the Incident Reports** From 57bdaceba0ce7b3a95a9630a6334f1ee767f4dac Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 15:06:23 +0200 Subject: [PATCH 08/14] chore: rewording Ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2289414618 --- incident-response-plan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index 940a646..e3a7315 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -5,7 +5,7 @@ This document outlines the process for handling security incidents affecting any The Foundation’s role is to: 1. **Receive and triage the Incident Reports** -2. **Connect reporters and affected maintainers with the right experts** +2. **Connect incident reporters with experts who can help** 3. **Facilitate coordinated response** across multiple projects when needed 4. **Communicate clearly and act as the contact point** while respecting confidentiality and responsible disclosure principles From abf0f678d1d43be5c8ff33ca950d2c6cfb709e1d Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 15:08:24 +0200 Subject: [PATCH 09/14] chore: rewording Ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2289416518 --- incident-response-plan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index e3a7315..c3240e8 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -7,7 +7,7 @@ The Foundation’s role is to: 1. **Receive and triage the Incident Reports** 2. **Connect incident reporters with experts who can help** 3. **Facilitate coordinated response** across multiple projects when needed -4. **Communicate clearly and act as the contact point** while respecting confidentiality and responsible disclosure principles +4. **Act as the contact point** while respecting confidentiality and responsible disclosure principles --- From ab673d06d3146b0479e6e0effb59a763f9b1a8d7 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 15:11:39 +0200 Subject: [PATCH 10/14] chore: rewording Ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2289421938 --- incident-response-plan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index c3240e8..066497c 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -14,7 +14,7 @@ The Foundation’s role is to: ## Scope This plan covers incidents such as: -- **Platform changes or providers outages** (e.g., GitHub UI change) that create security or operational risk. +- **Platform changes or provider outages with security implications** (e.g., compromised authentication systems, unexpected data exposure, service disruptions affecting security controls) that create security or operational risk. - **Account or registry access issues** (e.g., npm lockdown, compromised maintainer account). - **Supply chain attacks** (e.g. XZ, phishing campaign, etc.. ) - **Third-party service compromises** affecting Foundation projects (e.g., data leaks in external services) From 527175f339ca55b4a04191e65b2c1e2d3783bc05 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 15:12:45 +0200 Subject: [PATCH 11/14] chore: rewording Ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2289422553 --- incident-response-plan.md | 1 - 1 file changed, 1 deletion(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index 066497c..49a03ee 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -17,7 +17,6 @@ This plan covers incidents such as: - **Platform changes or provider outages with security implications** (e.g., compromised authentication systems, unexpected data exposure, service disruptions affecting security controls) that create security or operational risk. - **Account or registry access issues** (e.g., npm lockdown, compromised maintainer account). - **Supply chain attacks** (e.g. XZ, phishing campaign, etc.. ) -- **Third-party service compromises** affecting Foundation projects (e.g., data leaks in external services) - **Legal-related operational threats**, including: - License disputes (e.g., GPL/MIT compliance challenges) - Patent-related threats impacting project distribution From 7767e65aa5c13e6bce641cda49c0b3dfa1dec6d6 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 15:15:16 +0200 Subject: [PATCH 12/14] chore: rewording Ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2289423281 --- incident-response-plan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index 49a03ee..5216fa6 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -38,7 +38,7 @@ Incidents that are not in scope: | Category | Examples | Primary Response Role | |----------|----------|-----------------------| | **Vulnerability Report** | Code exploit, CVE disputes, escalations... | Redirect to the project or delegate to the CNA Team | -| **Platform Change Risk** | GitHub UI update causing accidental info exposure | Triage → Escalate to platform contacts → Provide mitigations | +| **Platform changes or provider outages with security implications** | compromised authentication systems, unexpected data exposure, service disruptions affecting security controls... | Triage → Escalate to platform contacts → Provide mitigations | | **Account Access Issue** | npm account lockout, GitHub MFA issues | Triage → Help restore access via platform → Provide temporary mitigation | | **Supply Chain Attack** | Malicious dependency version | Coordinate with affected projects → Security advisories | | **External Incident Impact** | Cloud provider compromise, service outage | Facilitate communication between impacted maintainers and providers | From 670eddc18afebcd727a778800e6c8374ab654e39 Mon Sep 17 00:00:00 2001 From: Ulises Gascon Date: Tue, 2 Sep 2025 16:44:29 +0200 Subject: [PATCH 13/14] chore: re-arrange content and remove redundancies Ref: https://github.com/openjs-foundation/security-collab-space/pull/289#discussion_r2289428598 --- incident-response-plan.md | 184 ++++++++++++++++++-------------------- 1 file changed, 86 insertions(+), 98 deletions(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index 5216fa6..0a3496f 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -1,140 +1,118 @@ # Incident Response Plan -## Purpose -This document outlines the process for handling security incidents affecting any OpenJS project. Incidents may include platform changes with security implications, account compromise, or other security events that require coordinated response. +## Purpose & Role -The Foundation’s role is to: -1. **Receive and triage the Incident Reports** -2. **Connect incident reporters with experts who can help** -3. **Facilitate coordinated response** across multiple projects when needed -4. **Act as the contact point** while respecting confidentiality and responsible disclosure principles +This plan outlines how the OpenJS Foundation facilitates and coordinates responses to security incidents affecting supported projects. ---- - -## Scope +The Foundation acts as a **facilitator and coordinator**, not as the primary incident responder. Our focus is to unblock projects and reduce risk by: -This plan covers incidents such as: -- **Platform changes or provider outages with security implications** (e.g., compromised authentication systems, unexpected data exposure, service disruptions affecting security controls) that create security or operational risk. -- **Account or registry access issues** (e.g., npm lockdown, compromised maintainer account). -- **Supply chain attacks** (e.g. XZ, phishing campaign, etc.. ) -- **Legal-related operational threats**, including: - - License disputes (e.g., GPL/MIT compliance challenges) - - Patent-related threats impacting project distribution - - DMCA takedown requests - - Trademark misuse or brand impersonation +- Connecting the right people and resources +- Coordinating communication between affected parties +- Providing guidance on best practices and mitigation strategies +- Facilitating access to subject matter experts +- Ensuring incidents follow responsible disclosure timelines +**We do not:** +- Directly fix code vulnerabilities +- Manage individual project security +- Serve as the first responder for project-level technical issues -Incidents that are not in scope: -- **Code-level security vulnerabilities** in projects maintained within the Foundation (handled by the project or the OpenJS CNA Team) -- **Non-Foundation projects** — see the [list of supported projects](https://openjsf.org/projects) +This approach respects project autonomy while leveraging the Foundation’s position in the ecosystem to resolve incidents efficiently. --- -### Incident Categories +## Scope & Incident Categories + +This plan applies to incidents such as: +- **Platform or provider security issues** (e.g., authentication compromise, unexpected data exposure, outages affecting security controls) +- **Account or registry access issues** (e.g., npm lockdown, GitHub MFA lockout, compromised maintainer account) +- **Supply chain attacks** (e.g., malicious package versions, phishing campaigns, dependency compromises) +- **Legal or operational threats** (e.g., license disputes, patent challenges, DMCA takedowns, trademark misuse) -- 🍿 @Discussion: Probably we can think on more scenarios together +**Out of Scope:** +- Code-level vulnerabilities in Foundation projects (handled by the project or OpenJS CNA Team) +- Non-Foundation projects — see [supported projects list](https://openjsf.org/projects) +🍿 @Discussion: Probably we can think on more scenarios together | Category | Examples | Primary Response Role | |----------|----------|-----------------------| -| **Vulnerability Report** | Code exploit, CVE disputes, escalations... | Redirect to the project or delegate to the CNA Team | -| **Platform changes or provider outages with security implications** | compromised authentication systems, unexpected data exposure, service disruptions affecting security controls... | Triage → Escalate to platform contacts → Provide mitigations | -| **Account Access Issue** | npm account lockout, GitHub MFA issues | Triage → Help restore access via platform → Provide temporary mitigation | -| **Supply Chain Attack** | Malicious dependency version | Coordinate with affected projects → Security advisories | -| **External Incident Impact** | Cloud provider compromise, service outage | Facilitate communication between impacted maintainers and providers | +| **Vulnerability Report** | Code exploit, CVE disputes, escalations | Redirect to project / CNA Team | +| **Platform Security Issue** | Authentication compromise, data exposure, outages | Triage → Escalate to platform → Mitigation guidance | +| **Account Access Issue** | npm account lockout, GitHub MFA | Triage → Work with provider → Temporary mitigation | +| **Supply Chain Attack** | Malicious dependency release | Coordinate with affected projects → Security advisories | +| **External Provider Incident** | Cloud/service compromise | Facilitate communication between maintainers & provider | --- +## Roles & Responsibilities -## Action plan - -We may not directly solve incidents, but we help **unblock situations** and **support projects at risk**. - -### Roles & Responsibilities - - -#### RACI Diagram - -_You can find more information about RACI in this [link](https://www.atlassian.com/work-management/project-management/raci-chart)_ - - -| Process Step | Reporter | Response Team (Foundation) | Coordinator (SRC) | SME | -|---------------------------------------|----------|-----------------------------|-------------------|-----| -| File Report | R, A | C | I | | -| Assign Coordinator | I | R | A | | -| Assess Impact & Severity | I | C | A | C | -| Identify & assign SMEs | I | C | A | C | -| Make a resolution / recommend mitigation | I | C | A | C | -| Document findings | I | C | A | I, C | -| Publish and share (if approved) | I | R, A | C | C | - -- 🍿 @Discussion: who should be in the team? -- 🍿 @Discussion: Should we publish the learning/findings when possible publickly to help the community? +### RACI Overview -#### Reporter +[More on RACI](https://www.atlassian.com/work-management/project-management/raci-chart) -This person submits an Incident Report to the Foundation Security Team and provides detailed information about the incident. - -**Responsibilities** - -- Submit an Incident Report to the Foundation Security Team. - -**Expectations** - -- Provide detailed information about the suspected vulnerability. -- Follow responsible disclosure guidelines (adapted to this context). -- Cooperate with the Foundation Security Team by providing additional details when needed. -- Respect security timelines and avoid premature public disclosure. +| Process Step | Reporter | Foundation Response Team | Coordinator (SRC) | SME | +|--------------|----------|--------------------------|-------------------|-----| +| File Report | R, A | C | I | | +| Assign Coordinator | I | R | A | | +| Assess Impact & Severity | I | C | A | C | +| Identify SMEs | I | C | A | C | +| Recommend Mitigation | I | C | A | C | +| Document Findings | I | C | A | I, C | +| Publish/Share (if approved) | I | R, A | C | C | +🍿 @Discussion: who should be in the team? +🍿 @Discussion: Should we publish learnings publicly to help the community? +--- -#### Coordinator (SRC) +### Reporter +Submits an incident report to the Foundation Security Team. -This person acts as the focal point for a specific Incident Report and ensures the report follows all responsible disclosure guidelines. The SRC coordinates the remediation process if the situation is confirmed and ensures that the Incident Report follows the process and necessary actions are taken. While the SRC is not necessarily responsible for performing a detailed analysis or remediation. +**Responsibilities & Expectations** +- Provide detailed incident information +- Follow responsible disclosure guidelines +- Cooperate by supplying clarifications when needed +- Respect embargo and disclosure timelines -**Responsibilities** +--- -- Acknowledge receipt of Incident 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 one or multiple SMEs. -- Ensure communication with the reporter and the affected projects throughout the process. -- Track all the Incident Reports for visibility and reporting. +### Coordinator (SRC) +Focal point for each incident. Ensures process is followed and manages communications. -#### Subject Matter Expert (SME) -Experts brought in for technical insight, platform liaison work, or domain-specific advice. +**Responsibilities** +- Acknowledge reports promptly +- Manage embargo and limit information sharing +- Assign SMEs as needed +- Keep reporter and affected projects updated +- Track all incidents for reporting and visibility -**Responsibilities**: -- Provide expert input to help assess impact and options -- Advise on mitigation strategies -- Help unblock the situations when feasible +--- -### Reporting method +### Subject Matter Expert (SME) +Provides technical, legal, or domain-specific expertise. +**Responsibilities** +- Help assess impact and options +- Recommend mitigation strategies +- Assist in unblocking projects when feasible -In [this webform](https://report-incident.openjsf.org/) is possible to create a new security report +--- +## Reporting Method -## Runbook +Submit incidents through the [OpenJS Security Incident Webform](https://report-incident.openjsf.org/). -- 🍿 @Discussion: What is the best approach? Some ideas: - 1. **Incident Report Received** - 2. **Assign Coordinator** and consolidate report details - 3. **Review** severity and affected projects - 4. **Identify SMEs** and brief them - 5. **Coordinate** with projects, platforms, or third parties - 6. **Document** findings and lessons learned - 7. **Publish** partial or full summary if appropriate - 8. **Social Media Team** prepare and posts where needed +--- -## General Response Workflow +## Response Workflow -- 🍿 @Discussion: early-stage idea, based on the Runbook: +🍿 @Discussion: early-stage idea, based on the Runbook ```mermaid flowchart TD A[Incident Report Received] --> B[Assign Coordinator] - B --> C{Is valid, qualified and can be verified?} + B --> C{Valid and verifiable?} C -- No --> D[Request Clarification from Reporter] D --> C C -- Yes --> E[Assess Impact and Severity] @@ -145,5 +123,15 @@ flowchart TD H --> I I --> J[Update Reporter and Stakeholders] J --> K[Document and Close Incident] - - +``` + +### Runbook (Step Summary) + +1. **Incident Report Received** +2. **Assign Coordinator** and consolidate details +3. **Review Severity** and affected projects +4. **Identify SMEs** and brief them +5. **Coordinate** with projects, platforms, or third parties +6. **Document** findings and lessons learned +7. **Publish** summary (if appropriate) +8. **Social Media Team** posts updates if needed From f33192fb7b79e73a3ae3dce7ea23cad15bd40b9f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ulises=20Gasc=C3=B3n?= Date: Mon, 10 Nov 2025 20:44:51 +0100 Subject: [PATCH 14/14] docs: add alternative communication channel --- incident-response-plan.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/incident-response-plan.md b/incident-response-plan.md index 0a3496f..822ed5b 100644 --- a/incident-response-plan.md +++ b/incident-response-plan.md @@ -101,7 +101,9 @@ Provides technical, legal, or domain-specific expertise. ## Reporting Method -Submit incidents through the [OpenJS Security Incident Webform](https://report-incident.openjsf.org/). +A direct reporting solution is not yet available. In the meantime, please request support in the #security channel on Slack. + +⚠️ Important: The #security channel is public. Do not share sensitive details there. Wait until you are added to a private channel before providing specific information. ---