-
Notifications
You must be signed in to change notification settings - Fork 10
Discussion Draft: Foundation Incident Response Plan #289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we could merge nodejs/security-wg#1511 here.
incident-response-plan.md
Outdated
|
||
**Expectations** | ||
|
||
- Provide detailed information about the suspected vulnerability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we have to be specific on the details that are provided in order to have a "quality" report that avoids a lot of clarifications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that big part of it can be "shaped" in the web form (required fields, validation...)
incident-response-plan.md
Outdated
|
||
## Scope | ||
|
||
This plan covers incidents such as: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be in order of most often occurring to least likely to occur
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with the idea, but not sure what is the best order... feel free to open a suggestion 👍
- 🍿 @Discussion: early-stage idea, based on the Runbook: | ||
|
||
```mermaid | ||
flowchart TD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should decide how communication and work here is co-ordinated. For example a common practice is that when an incident occurs, the incident commander creates a dedicated slack channel to facilitate communication.
incident-response-plan.md
Outdated
## Runbook | ||
|
||
- 🍿 @Discussion: What is the best approach? Some ideas: | ||
1. **REPORT Received** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have a more straightforward workflow in the event of a severe report.
For instance, if the report is from a Low ~ High vulnerability score, we follow the current runbook. However, we should have a direct line if the vulnerability is a potential Critical/Severe score.
For our next meeting... pending items:
|
This is a draft version of the Foundation’s Incident Response Plan.
Please feel free to comment per line or add general feedback directly in this PR.
The main goal is to kick off the discussion so we can refine and agree on the process in our next meeting on Monday and keep iterating this PR between meetings...
Nothing here is final at all... placeholders (
🍿 @Discussion
) are meant to capture open questions for the group.