|
| 1 | +# Incident Response Plan (IRP) |
| 2 | + |
| 3 | +This document outlines how we handle security vulnerabilities. It is a living document. Reporters and stakeholders can use the phases below to understand where we are during an active incident. |
| 4 | + |
| 5 | +We support two disclosure strategies: |
| 6 | + |
| 7 | +- **Advisory With Patch** _(default)_: A fix is prepared privately and released alongside a public advisory. |
| 8 | +- **Advisory Early** _(rare)_: An advisory is published before a fix is available — used when the vulnerability is already public or actively exploited. |
| 9 | + |
| 10 | +--- |
| 11 | + |
| 12 | +## Phase 1 — Triage |
| 13 | +_"We're investigating."_ |
| 14 | +**Target: within 36 hours of report** |
| 15 | + |
| 16 | +- Acknowledge receipt to the reporter. |
| 17 | +- Reproduce and validate the vulnerability. |
| 18 | +- Assess severity: |
| 19 | + - **Critical** — Active exploitation or data exposure. Drop everything. |
| 20 | + - **High** — Exploitable, no known active exploitation. |
| 21 | + - **Medium/Low** — Limited impact or requires unlikely conditions. |
| 22 | +- Create a draft [GitHub Security Advisory (GHSA)](https://docs.github.com/en/code-security/security-advisories). |
| 23 | +- Decide disclosure strategy (Advisory With Patch or Advisory Early). |
| 24 | + |
| 25 | +## Phase 2 — Containment |
| 26 | +_"We've identified the issue and are limiting its impact."_ |
| 27 | +**Target: 1–7 days after triage** |
| 28 | + |
| 29 | +- Isolate affected systems or services (revoke keys, disable endpoints, pull images). |
| 30 | +- Preserve evidence (logs, snapshots) before making changes. |
| 31 | +- Scope impact: identify affected components, versions, and platforms. |
| 32 | +- Request a CVE via the GitHub advisory interface. |
| 33 | +- Communicate status to the reporter. |
| 34 | + |
| 35 | +## Phase 3 — Fix & Release |
| 36 | +_"We're working on a fix."_ |
| 37 | +**Target: within 90 days of initial report** |
| 38 | + |
| 39 | +- Develop and test a patch. |
| 40 | +- At least 2 team members review and sign off. |
| 41 | +- Publish the GHSA and deploy the fix simultaneously. |
| 42 | +- _Advisory Early: update the existing public advisory with fix details._ |
| 43 | + |
| 44 | +## Phase 4 — Disclosure |
| 45 | +_"The fix is live. Here's what happened."_ |
| 46 | +**Target: same day as fix release** |
| 47 | + |
| 48 | +- Notify the reporter that the issue is resolved. |
| 49 | +- Credit the reporter (unless they prefer anonymity). |
| 50 | +- Verify the published advisory is accurate and complete. |
| 51 | +- We follow the industry-standard **90-day coordinated disclosure window**. If a fix cannot ship in 90 days, we coordinate with the reporter on a revised timeline. |
| 52 | + |
| 53 | +## Phase 5 — Post-Incident Review |
| 54 | +_"We're making sure this doesn't happen again."_ |
| 55 | +**Target: within 2 weeks of resolution** |
| 56 | + |
| 57 | +- Document root cause, timeline, and actions taken. |
| 58 | +- Identify process or code improvements to prevent recurrence. |
| 59 | +- Update this plan if gaps were found. |
| 60 | + |
| 61 | +--- |
| 62 | + |
| 63 | +## Contact |
| 64 | + |
| 65 | +Email: [hello@instavm.io](mailto:hello@instavm.io) |
| 66 | + |
| 67 | +## Reporting a Vulnerability |
| 68 | + |
| 69 | +See [SECURITY.md](SECURITY.md). **Do not open public issues.** |
0 commit comments