3.4 KiB
Incident Response Plan
Reporting a Vulnerability
Please see the latest guidelines for instructions.
Phases
Triage
- Is this a valid security vulnerability?
- It affects our CI/CD or any of our repositories.
- For ohmyzsh/ohmyzsh, it affects the latest commit.
- For others, it affects the latest commit on the default branch.
- It affects a third-party dependency:
- Zsh or git
- For a plugin, the vulnerability is a result of our usage of the dependency.
- What's the scope of the vulnerability?
- Our codebase.
- A direct third-party dependency (Zsh, git, other plugins).
- An indirect third-party dependency.
- Out of scope, a third-party dependency that is the responsibility of the user.
- Out of scope, any other case (edit this plan and add the details).
- Is the vulnerability actionable?
- Yes, we can submit a fix.
- Yes, we can disable a feature.
- Yes, we can mitigate the risk.
- Yes, we can remove a vulnerable dependency.
- Yes, we can apply a workaround.
- Yes, we can apply a patch to a vulnerable dependency (example for CVE-2021-45444).
- No, the vulnerability is not actionable.
- What's the impact of the vulnerability?
Assess using the CIA triad:
- Confidentiality: example: report or sharing of secrets.
- Integrity: affects the integrity of the system (deletion, corruption or encryption of data, OS file corruption, etc.).
- Availability: denial of login, deletion of required files to boot / login, etc.
- What's the exploitability of the vulnerability?
Consider how easy it is to exploit, and if it affects all users or requires specific configurations.
- What's the severity of the vulnerability?
You can use the CVSS v3.1 to assess the severity of the vulnerability.
- When was the vulnerability introduced?
- Find the responsible code path.
- Find the commit or Pull Request that introduced the vulnerability.
- Who are our security contacts?
Assess upstream or downstream contacts, and their desired channels of security.
TODO: add a list of contacts.
Mitigation
- Primary focus: removing possibility of exploitation fast.
- Secondary focus: addressing the root cause.
Important
Make sure to test that the mitigation works as expected, and does not introduce new vulnerabilities. When deploying a patch, make sure not to disclose the vulnerability in the commit message or PR description.
TODO: introduce a fast-track update process for security patches.
Disclosure
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.
TODO: add a vulnerability disclosure template.
Learn
- Document the vulnerability, steps performed, and lessons learned.
- Document the timeline of events.
- Document and address improvements on the Security Incident Response Plan.
- 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.