Incident Response Plan
1. Overview¶
This plan defines how FirstTry responds to security incidents, vulnerabilities, and operational events.
2. Incident Severity Classification¶
| Severity | CVSS | Example | Notify SLA | Ack SLA |
|---|---|---|---|---|
| Critical | ≥9.0 | Active exploit, data breach, scope escalation detected, unpatched critical CVE | 24 hours | 4 hours |
| High | 7.0–8.9 | Privilege escalation vulnerability, POST/PUT/DELETE discovered in code, dependency with high CVE | 48 hours | 8 hours |
| Medium | 4.0–6.9 | Minor vulnerability, missing input validation, low-impact cryptography issue | 5 days | 24 hours |
| Low | <4.0 | Informational findings, documentation gaps, development practices note | 14 days | 5 days |
IMPORTANT CAVEAT:
Notification timelines are best-effort and subject to Atlassian Forge platform availability and customer contact availability. FirstTry will make reasonable efforts to notify reported contacts within stated SLAs, but external factors may impact delivery.
3. Incident Response Workflow¶
Phase 1: Detection & Initial Response¶
Timeline: Immediate (0–1 hour)
Detection source:
- Vulnerability report (security.contact@firsttry.run)
- Internal scanning (CI/CD gate, dependency checks)
- User report (support channels)
- Forge platform notification (if Forge incident affects FirstTry)
Initial assessment:
- Reproduce issue (if applicable)
- Assign severity level
- Determine if code patch needed or mitigation sufficient
Notification rules:
- Critical: Contact security.firsttry.run within 4 hours
- High: Contact security.firsttry.run within 8 hours
- Medium/Low: Email to registered contacts within timeframe
Phase 2: Investigation & Development¶
Timeline: 1–30 days (depends on severity)
Investigation:
- Root cause analysis
- Impact assessment (affected versions, customers, data)
- Determine if issue is FirstTry-owned or platform-owned
Development:
- Create fix or mitigation
- Develop test cases
- Code review by another team member
Release planning:
- Determine rollout strategy (immediate, next release, staged)
- Prepare customer notification (email, CHANGELOG.md)
- Consider backward compatibility
Phase 3: Patch Release & Communication¶
Timeline: As soon as patch is ready (typically 7–30 days)
Release:
- Tag release with version (e.g., v0.4.2-patch1)
- Publish to Atlassian Marketplace (if applicable)
- Push to production via forge deploy
Communication:
- Update CHANGELOG.md with security notice
- Email registered security contacts
- Post advisory (if public repo used)
Verification:
- Confirm patch deployed in production
- Monitor for deployment issues
Phase 4: Post-Incident Review¶
Timeline: 1 week after resolution
Conduct retrospective:
- What was the root cause?
- Could this have been prevented?
- What process improvements apply?
Update documentation:
- Update threat model if new threat discovered
- Update security policies if process gaps identified
- Regenerate evidence artifacts
Lessons learned:
- Share findings with team
- Update CI/CD gates if applicable
- Retrain on secure coding practices if needed
4. Incident Response Roles¶
| Role | Responsible For | Contact |
|---|---|---|
| Security Contact | Primary incident coordinator | security.contact@firsttry.run |
| Emergency Response | Critical/P0 incidents requiring immediate action | emergency@firsttry.run |
| Lead Developer | Code investigation & patch | (internal team) |
| Release Manager | Deployment & communication | (internal team) |
| Product Owner | Customer communication & impact assessment | (internal team) |
5. Escalation Paths¶
Level 1: FirstTry Team¶
- Assess severity
- Develop initial mitigation plan
- Notify customers if needed
Level 2: Atlassian Escalation (if applicable)¶
- If issue is in Forge platform or Jira API
- Contact Atlassian support with details
- Reference incident tracking system
Level 3: Customer Escalation¶
- If incident affects specific customer data
- Contact customer's nominated security officer
- Provide incident details and remediation steps
6. Communication Templates¶
Critical/High Severity Notification¶
Subject: [SECURITY INCIDENT] FirstTry –
Body:
We are aware of a security issue in FirstTry (# CVE-XXXX-XXXXX or Issue #XXX).
SEVERITY: <High | Critical>
IMPACT: <Who is affected and how>
TIMELINE: <When patch will be available>
ACTION: <What customers should do: update, reconfigure, monitor logs, etc.>
We appreciate your patience and will provide updates every 24 hours.
Contact: security.contact@firsttry.run
Patch Release Notification¶
Subject: [SECURITY PATCH] FirstTry v0.4.2 – Update Available
Body:
A security patch is now available for FirstTry v0.4.2.
ISSUE: <Description>
SEVERITY: <Level>
PATCH NOTES: See CHANGELOG.md for details
Please update at your earliest convenience.
Update procedure:
1. Jira Settings → Apps
2. FirstTry → Update
3. Confirm installation
If you have questions, contact: support@firsttry.run
7. Incident Tracking¶
All incidents logged in:
- GitHub Issues (private repo) with severity label
- CHANGELOG.md (after resolution)
- Annual security report (if applicable)
Retention: Posts-incident records retained for 2 years (per legal/compliance requirements).
8. Third-Party Incident Dependencies¶
If incident is in Atlassian Forge or Jira Cloud:
- FirstTry cannot independently patch platform issues
- Will coordinate with Atlassian on remediation timeline
- Will notify customers of Atlassian's guidance and ETA
9. Testing and Exercises¶
Annual incident response drill:
- Simulate security incident
- Walk through workflow
- Validate contact information
- Test notification systems
References¶
- SECURITY_CONTACT.md: Contact information
- VULNERABILITY_DISCLOSURE_POLICY.md: Reporting process
- THREAT_MODEL.md: Known threat scenarios