Skip to content

Commit 670eddc

Browse files
committed
chore: re-arrange content and remove redundancies
Ref: #289 (comment)
1 parent 7767e65 commit 670eddc

File tree

1 file changed

+86
-98
lines changed

1 file changed

+86
-98
lines changed

incident-response-plan.md

Lines changed: 86 additions & 98 deletions
Original file line numberDiff line numberDiff line change
@@ -1,140 +1,118 @@
11
# Incident Response Plan
22

3-
## Purpose
4-
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.
3+
## Purpose & Role
54

6-
The Foundation’s role is to:
7-
1. **Receive and triage the Incident Reports**
8-
2. **Connect incident reporters with experts who can help**
9-
3. **Facilitate coordinated response** across multiple projects when needed
10-
4. **Act as the contact point** while respecting confidentiality and responsible disclosure principles
5+
This plan outlines how the OpenJS Foundation facilitates and coordinates responses to security incidents affecting supported projects.
116

12-
---
13-
14-
## Scope
7+
The Foundation acts as a **facilitator and coordinator**, not as the primary incident responder. Our focus is to unblock projects and reduce risk by:
158

16-
This plan covers incidents such as:
17-
- **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.
18-
- **Account or registry access issues** (e.g., npm lockdown, compromised maintainer account).
19-
- **Supply chain attacks** (e.g. XZ, phishing campaign, etc.. )
20-
- **Legal-related operational threats**, including:
21-
- License disputes (e.g., GPL/MIT compliance challenges)
22-
- Patent-related threats impacting project distribution
23-
- DMCA takedown requests
24-
- Trademark misuse or brand impersonation
9+
- Connecting the right people and resources
10+
- Coordinating communication between affected parties
11+
- Providing guidance on best practices and mitigation strategies
12+
- Facilitating access to subject matter experts
13+
- Ensuring incidents follow responsible disclosure timelines
2514

15+
**We do not:**
16+
- Directly fix code vulnerabilities
17+
- Manage individual project security
18+
- Serve as the first responder for project-level technical issues
2619

27-
Incidents that are not in scope:
28-
- **Code-level security vulnerabilities** in projects maintained within the Foundation (handled by the project or the OpenJS CNA Team)
29-
- **Non-Foundation projects** — see the [list of supported projects](https://openjsf.org/projects)
20+
This approach respects project autonomy while leveraging the Foundation’s position in the ecosystem to resolve incidents efficiently.
3021

3122
---
3223

33-
### Incident Categories
24+
## Scope & Incident Categories
25+
26+
This plan applies to incidents such as:
27+
- **Platform or provider security issues** (e.g., authentication compromise, unexpected data exposure, outages affecting security controls)
28+
- **Account or registry access issues** (e.g., npm lockdown, GitHub MFA lockout, compromised maintainer account)
29+
- **Supply chain attacks** (e.g., malicious package versions, phishing campaigns, dependency compromises)
30+
- **Legal or operational threats** (e.g., license disputes, patent challenges, DMCA takedowns, trademark misuse)
3431

35-
- 🍿 @Discussion: Probably we can think on more scenarios together
32+
**Out of Scope:**
33+
- Code-level vulnerabilities in Foundation projects (handled by the project or OpenJS CNA Team)
34+
- Non-Foundation projects — see [supported projects list](https://openjsf.org/projects)
3635

36+
🍿 @Discussion: Probably we can think on more scenarios together
3737

3838
| Category | Examples | Primary Response Role |
3939
|----------|----------|-----------------------|
40-
| **Vulnerability Report** | Code exploit, CVE disputes, escalations... | Redirect to the project or delegate to the CNA Team |
41-
| **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 |
42-
| **Account Access Issue** | npm account lockout, GitHub MFA issues | Triage → Help restore access via platform → Provide temporary mitigation |
43-
| **Supply Chain Attack** | Malicious dependency version | Coordinate with affected projects → Security advisories |
44-
| **External Incident Impact** | Cloud provider compromise, service outage | Facilitate communication between impacted maintainers and providers |
40+
| **Vulnerability Report** | Code exploit, CVE disputes, escalations | Redirect to project / CNA Team |
41+
| **Platform Security Issue** | Authentication compromise, data exposure, outages | Triage → Escalate to platform → Mitigation guidance |
42+
| **Account Access Issue** | npm account lockout, GitHub MFA | Triage → Work with provider → Temporary mitigation |
43+
| **Supply Chain Attack** | Malicious dependency release | Coordinate with affected projects → Security advisories |
44+
| **External Provider Incident** | Cloud/service compromise | Facilitate communication between maintainers & provider |
4545

4646
---
4747

48+
## Roles & Responsibilities
4849

49-
## Action plan
50-
51-
We may not directly solve incidents, but we help **unblock situations** and **support projects at risk**.
52-
53-
### Roles & Responsibilities
54-
55-
56-
#### RACI Diagram
57-
58-
_You can find more information about RACI in this [link](https://www.atlassian.com/work-management/project-management/raci-chart)_
59-
60-
61-
| Process Step | Reporter | Response Team (Foundation) | Coordinator (SRC) | SME |
62-
|---------------------------------------|----------|-----------------------------|-------------------|-----|
63-
| File Report | R, A | C | I | |
64-
| Assign Coordinator | I | R | A | |
65-
| Assess Impact & Severity | I | C | A | C |
66-
| Identify & assign SMEs | I | C | A | C |
67-
| Make a resolution / recommend mitigation | I | C | A | C |
68-
| Document findings | I | C | A | I, C |
69-
| Publish and share (if approved) | I | R, A | C | C |
70-
71-
- 🍿 @Discussion: who should be in the team?
72-
- 🍿 @Discussion: Should we publish the learning/findings when possible publickly to help the community?
50+
### RACI Overview
7351

74-
#### Reporter
52+
[More on RACI](https://www.atlassian.com/work-management/project-management/raci-chart)
7553

76-
This person submits an Incident Report to the Foundation Security Team and provides detailed information about the incident.
77-
78-
**Responsibilities**
79-
80-
- Submit an Incident Report to the Foundation Security Team.
81-
82-
**Expectations**
83-
84-
- Provide detailed information about the suspected vulnerability.
85-
- Follow responsible disclosure guidelines (adapted to this context).
86-
- Cooperate with the Foundation Security Team by providing additional details when needed.
87-
- Respect security timelines and avoid premature public disclosure.
54+
| Process Step | Reporter | Foundation Response Team | Coordinator (SRC) | SME |
55+
|--------------|----------|--------------------------|-------------------|-----|
56+
| File Report | R, A | C | I | |
57+
| Assign Coordinator | I | R | A | |
58+
| Assess Impact & Severity | I | C | A | C |
59+
| Identify SMEs | I | C | A | C |
60+
| Recommend Mitigation | I | C | A | C |
61+
| Document Findings | I | C | A | I, C |
62+
| Publish/Share (if approved) | I | R, A | C | C |
8863

64+
🍿 @Discussion: who should be in the team?
65+
🍿 @Discussion: Should we publish learnings publicly to help the community?
8966

67+
---
9068

91-
#### Coordinator (SRC)
69+
### Reporter
70+
Submits an incident report to the Foundation Security Team.
9271

93-
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.
72+
**Responsibilities & Expectations**
73+
- Provide detailed incident information
74+
- Follow responsible disclosure guidelines
75+
- Cooperate by supplying clarifications when needed
76+
- Respect embargo and disclosure timelines
9477

95-
**Responsibilities**
78+
---
9679

97-
- Acknowledge receipt of Incident Reports within the required timeframe.
98-
- Orchestrate the embargo and identify the minimum set of individuals involved.
99-
- 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.
100-
- Assign one or multiple SMEs.
101-
- Ensure communication with the reporter and the affected projects throughout the process.
102-
- Track all the Incident Reports for visibility and reporting.
80+
### Coordinator (SRC)
81+
Focal point for each incident. Ensures process is followed and manages communications.
10382

104-
#### Subject Matter Expert (SME)
105-
Experts brought in for technical insight, platform liaison work, or domain-specific advice.
83+
**Responsibilities**
84+
- Acknowledge reports promptly
85+
- Manage embargo and limit information sharing
86+
- Assign SMEs as needed
87+
- Keep reporter and affected projects updated
88+
- Track all incidents for reporting and visibility
10689

107-
**Responsibilities**:
108-
- Provide expert input to help assess impact and options
109-
- Advise on mitigation strategies
110-
- Help unblock the situations when feasible
90+
---
11191

112-
### Reporting method
92+
### Subject Matter Expert (SME)
93+
Provides technical, legal, or domain-specific expertise.
11394

95+
**Responsibilities**
96+
- Help assess impact and options
97+
- Recommend mitigation strategies
98+
- Assist in unblocking projects when feasible
11499

115-
In [this webform](https://report-incident.openjsf.org/) is possible to create a new security report
100+
---
116101

102+
## Reporting Method
117103

118-
## Runbook
104+
Submit incidents through the [OpenJS Security Incident Webform](https://report-incident.openjsf.org/).
119105

120-
- 🍿 @Discussion: What is the best approach? Some ideas:
121-
1. **Incident Report Received**
122-
2. **Assign Coordinator** and consolidate report details
123-
3. **Review** severity and affected projects
124-
4. **Identify SMEs** and brief them
125-
5. **Coordinate** with projects, platforms, or third parties
126-
6. **Document** findings and lessons learned
127-
7. **Publish** partial or full summary if appropriate
128-
8. **Social Media Team** prepare and posts where needed
106+
---
129107

130-
## General Response Workflow
108+
## Response Workflow
131109

132-
- 🍿 @Discussion: early-stage idea, based on the Runbook:
110+
🍿 @Discussion: early-stage idea, based on the Runbook
133111

134112
```mermaid
135113
flowchart TD
136114
A[Incident Report Received] --> B[Assign Coordinator]
137-
B --> C{Is valid, qualified and can be verified?}
115+
B --> C{Valid and verifiable?}
138116
C -- No --> D[Request Clarification from Reporter]
139117
D --> C
140118
C -- Yes --> E[Assess Impact and Severity]
@@ -145,5 +123,15 @@ flowchart TD
145123
H --> I
146124
I --> J[Update Reporter and Stakeholders]
147125
J --> K[Document and Close Incident]
148-
149-
126+
```
127+
128+
### Runbook (Step Summary)
129+
130+
1. **Incident Report Received**
131+
2. **Assign Coordinator** and consolidate details
132+
3. **Review Severity** and affected projects
133+
4. **Identify SMEs** and brief them
134+
5. **Coordinate** with projects, platforms, or third parties
135+
6. **Document** findings and lessons learned
136+
7. **Publish** summary (if appropriate)
137+
8. **Social Media Team** posts updates if needed

0 commit comments

Comments
 (0)