Security Incident Response Playbook
This playbook provides step-by-step procedures for handling security incidents in React Starter Kit projects. Each procedure includes specific actions, tools, and decision criteria.
Quick Reference
- Security Email:
[email protected] - Incident Tracking: GitHub Security Advisories
- Communication Channel: Email (encrypted when possible)
- Escalation: Project maintainers via GitHub
Incident Classification
Determining Severity
Use this decision tree to classify incidents:
Is remote code execution possible?
├─ Yes → CRITICAL (P0)
└─ No → Can authentication be bypassed?
├─ Yes → CRITICAL (P0)
└─ No → Is sensitive data exposed?
├─ Yes (all users) → CRITICAL (P0)
├─ Yes (subset) → HIGH (P1)
└─ No → Is privilege escalation possible?
├─ Yes → HIGH (P1)
└─ No → Is XSS present?
├─ Yes (auth flow) → HIGH (P1)
├─ Yes (other) → MEDIUM (P2)
└─ No → Is CSRF possible?
├─ Yes → MEDIUM (P2)
└─ No → LOW (P3)Phase 1: Initial Response
Step 1.1: Acknowledge Report (0-2 hours)
Actions:
Send acknowledgment email with template:
Subject: [RSK-SEC-YYYY-NNN] Security Report Received Thank you for your security report. We have received your submission and assigned tracking ID: RSK-SEC-YYYY-NNN We will begin our initial assessment and respond within [TIMEFRAME]. Please keep this vulnerability confidential while we investigate.Create private GitHub issue for tracking
Assign initial responder
Tools: Email client, GitHub Issues (private)
Step 1.2: Initial Assessment (2-24 hours)
Actions:
- Review report for completeness
- Attempt to reproduce vulnerability
- Determine affected components
- Classify severity using decision tree
Decision Points:
- If cannot reproduce � Request clarification
- If critical � Immediately notify maintainers
- If valid � Proceed to Phase 2
Step 1.3: Form Response Team
For Critical/High severity:
- Lead: Project maintainer
- Developer: Fix implementation
- Reviewer: Code review and testing
- Communicator: External updates
For Medium/Low severity:
- Lead: Available maintainer
- Developer: Fix implementation
Phase 2: Investigation & Containment
Step 2.1: Deep Dive Analysis (Day 1-2)
Actions:
- Set up isolated test environment
- Reproduce vulnerability with minimal test case
- Identify root cause
- Document attack vectors
- Check for similar vulnerabilities
Checklist:
- [ ] Vulnerability reproduced
- [ ] Root cause identified
- [ ] Attack surface mapped
- [ ] Similar code patterns checked
- [ ] Impact assessment complete
Step 2.2: Temporary Mitigation (If Critical)
Actions:
- Develop temporary workaround
- Test workaround doesn't break functionality
- Document workaround for users
- Publish security bulletin with mitigation
Template for Security Bulletin:
markdown
## Security Bulletin: [TITLE]
**Date**: [DATE]
**Severity**: [CRITICAL/HIGH]
**Status**: Under Investigation
### Summary
We are investigating a security vulnerability in React Starter Kit.
### Temporary Mitigation
Until a patch is available, users should:
1. [Specific mitigation steps]
2. [Additional steps]
### Timeline
- Patch expected: [DATE]
- Full disclosure: After patch
### Contact
Report issues to: `[email protected]`Phase 3: Development & Testing
Step 3.1: Develop Fix (Varies by severity)
Actions:
- Create private branch for fix
- Implement minimal fix (no refactoring)
- Add regression tests
- Document code changes
Code Review Checklist:
- [ ] Fix addresses root cause
- [ ] No new vulnerabilities introduced
- [ ] Tests cover vulnerability scenario
- [ ] Changes are minimal and focused
- [ ] No sensitive info in comments/commits
Step 3.2: Testing Protocol
Test Environments:
- Local development
- Isolated staging
- Integration testing
- Performance impact
Test Cases:
- [ ] Original PoC no longer works
- [ ] Legitimate functionality preserved
- [ ] No performance regression
- [ ] No new error conditions
- [ ] Edge cases handled
Step 3.3: Prepare Release
Actions:
- Update version numbers
- Write release notes
- Prepare security advisory
- Request CVE (if applicable)
CVE Request Template:
[Contact GitHub Security for CVE]
Repository: react-starter-kit
Vulnerability Type: [TYPE]
Affected Versions: < X.Y.Z
Fixed Version: X.Y.Z
Description: [DESCRIPTION]Phase 4: Release & Disclosure
Step 4.1: Coordinated Release
Release Checklist:
- [ ] Code merged to main branch
- [ ] Version tagged and released
- [ ] Security advisory drafted
- [ ] Reporter notified of release date
- [ ] Release notes prepared
Step 4.2: Public Disclosure
Actions:
- Publish GitHub Security Advisory
- Update SECURITY.md if needed
- Send notification to users (if critical)
- Credit reporter
Security Advisory Template:
markdown
## [CVE-YYYY-NNNNN] [Vulnerability Title]
**Severity**: [Critical/High/Medium/Low]
**Affected Versions**: < X.Y.Z
**Patched Version**: X.Y.Z
### Description
[Clear description of vulnerability]
### Impact
[Potential impact on users]
### Patches
Update to version X.Y.Z or later.
### Workarounds
[If any temporary workarounds exist]
### References
- [Links to fixes]
- [Links to documentation]
### Credit
Reported by [Name] ([Organization])Step 4.3: User Communication
For Critical vulnerabilities:
- Email registered users (if applicable)
- Post on project blog/website
- Social media announcement
- Update documentation
Communication Template:
Subject: [ACTION REQUIRED] Security Update for React Starter Kit
A critical security vulnerability has been discovered and patched.
Action Required:
1. Update to version X.Y.Z immediately
2. Review security advisory: [LINK]
3. Apply any additional mitigations
Details: [BRIEF DESCRIPTION]
Questions: `[email protected]`Phase 5: Post-Incident Review
Step 5.1: Incident Retrospective (Within 1 week)
Meeting Agenda:
- Timeline review
- What went well
- What could improve
- Action items
- Policy updates needed
Questions to Answer:
- How was the vulnerability introduced?
- Why wasn't it caught earlier?
- How can we prevent similar issues?
- Was our response adequate?
- What tools/processes need improvement?
Step 5.2: Implement Improvements
Common Improvements:
- Add security linting rules
- Enhance test coverage
- Update coding guidelines
- Improve dependency management
- Add security checkpoints to CI/CD
Step 5.3: Documentation Updates
Update as needed:
- This playbook
- SECURITY.md
- Development guidelines
- CI/CD configurations
- Security checklist
Appendix A: Tools & Resources
Security Tools
- Dependency Scanning:
bun audit, Dependabot - Static Analysis: ESLint security plugins
- Secret Scanning: GitHub secret scanning, truffleHog
- SAST: Semgrep, CodeQL
- Testing: Vitest for security tests
Communication Tools
- Encrypted Email: PGP/GPG
- Secure File Transfer: Age encryption
- Private Issues: GitHub Security Advisories
External Resources
Appendix B: Contact Templates
Reporter Follow-up
Subject: Re: [RSK-SEC-YYYY-NNN] Status Update
Thank you for your patience. Here's an update on your report:
Status: [In Progress/Testing Fix/Ready for Release]
Severity: [Confirmed as X]
Timeline: [Expected resolution date]
[Any questions for reporter]
We'll notify you before public disclosure.Maintainer Escalation
Subject: [URGENT] Critical Security Issue - Immediate Action Required
A critical vulnerability has been reported:
Tracking: RSK-SEC-YYYY-NNN
Type: [Vulnerability type]
Impact: [Brief impact description]
Status: [Confirmed/Under Investigation]
Required Actions:
1. [Immediate actions needed]
2. [Review assignments]
Details in private issue: [Link]Release Notification
Subject: Security Release Scheduled - [DATE]
Security release details:
Version: X.Y.Z
Release Date: [DATE TIME UTC]
Severity: [Level]
CVE: [If assigned]
Pre-release checklist:
- [ ] Code reviewed and tested
- [ ] Advisory prepared
- [ ] Reporter notified
- [ ] Release notes ready
Please confirm readiness by [DATE].Revision History
- v1.0.0 - Initial playbook creation
- Updates logged in commit history
This playbook is a living document. Update it based on lessons learned from each incident.