Diff
1diff --git a/.github/INCIDENT_RESPONSE_PLAN.md b/.github/INCIDENT_RESPONSE_PLAN.md
2new file mode 100644
3index 0000000000000000000000000000000000000000..3f0b493c6dbd91db667ca15482f5b49d3ad715b8
4--- /dev/null
5+++ b/.github/INCIDENT_RESPONSE_PLAN.md
6@@ -0,0 +1,87 @@
7+# Incident Response Plan
8+
9+## Reporting a Vulnerability
10+
11+Please see [the latest guidelines](https://github.com/ohmyzsh/ohmyzsh/blob/master/SECURITY.md) for instructions.
12+
13+## Phases
14+
15+### Triage
16+
17+1. Is this a valid security vulnerability?
18+
19+ - [ ] It affects our CI/CD or any of our repositories.
20+ - [ ] For ohmyzsh/ohmyzsh, it affects the latest commit.
21+ - [ ] For others, it affects the latest commit on the default branch.
22+ - [ ] It affects a third-party dependency:
23+ - [ ] Zsh or git
24+ - [ ] For a plugin, the vulnerability is a result of our usage of the dependency.
25+
26+2. What's the scope of the vulnerability?
27+
28+ - [ ] Our codebase.
29+ - [ ] A direct third-party dependency (Zsh, git, other plugins).
30+ - [ ] An indirect third-party dependency.
31+ - [ ] Out of scope, a third-party dependency that is the responsibility of the user.
32+ - [ ] Out of scope, any other case (edit this plan and add the details).
33+
34+3. Is the vulnerability actionable?
35+
36+ - [ ] Yes, we can submit a fix.
37+ - [ ] Yes, we can disable a feature.
38+ - [ ] Yes, we can mitigate the risk.
39+ - [ ] Yes, we can remove a vulnerable dependency.
40+ - [ ] Yes, we can apply a workaround.
41+ - [ ] Yes, we can apply a patch to a vulnerable dependency ([example for CVE-2021-45444](https://github.com/ohmyzsh/ohmyzsh/blob/cb72d7dcbf08b435c7f8a6470802b207b2aa02c3/lib/vcs_info.zsh)).
42+ - [ ] No, the vulnerability is not actionable.
43+
44+4. What's the impact of the vulnerability?
45+
46+ Assess using the *CIA* triad:
47+
48+ - **Confidentiality**: example: report or sharing of secrets.
49+ - **Integrity**: affects the integrity of the system (deletion, corruption or encryption of data, OS file corruption, etc.).
50+ - **Availability**: denial of login, deletion of required files to boot / login, etc.
51+
52+5. What's the exploitability of the vulnerability?
53+
54+ Consider how easy it is to exploit, and if it affects all users or requires specific configurations.
55+
56+6. What's the severity of the vulnerability?
57+
58+ You can use the [CVSS v3.1](https://www.first.org/cvss/specification-document) to assess the severity of the vulnerability.
59+
60+7. When was the vulnerability introduced?
61+
62+ - Find the responsible code path.
63+ - Find the commit or Pull Request that introduced the vulnerability.
64+
65+8. Who are our security contacts?
66+
67+ Assess upstream or downstream contacts, and their desired channels of security.
68+
69+ > TODO: add a list of contacts.
70+
71+### Mitigation
72+
73+- **Primary focus:** removing possibility of exploitation fast.
74+- **Secondary focus:** addressing the root cause.
75+
76+> [!IMPORTANT]
77+> Make sure to test that the mitigation works as expected, and does not introduce new vulnerabilities.
78+> When deploying a patch, make sure not to disclose the vulnerability in the commit message or PR description.
79+
80+> TODO: introduce a fast-track update process for security patches.
81+
82+### Disclosure
83+
84+Primary goal: inform our users about the vulnerability, and whether they are affected or not affected based on information they should be able to check themselves in a straightforward way.
85+
86+> TODO: add a vulnerability disclosure template.
87+
88+### Learn
89+
90+- Document the vulnerability, steps performed, and lessons learned.
91+- Document the timeline of events.
92+- Document and address improvements on the Security Incident Response Plan.
93+- Depending on the severity of the vulnerability, consider disclosing the root cause or not based on likely impact on users and estimated potential victims still affected.