If you discover a security vulnerability in CUDly, do not open a public GitHub issue.
Contact the maintainers directly via email (see repository settings for contact). Provide:
- A description of the vulnerability and its potential impact
- Steps to reproduce
- Any suggested mitigations
We commit to acknowledging reports within 48 hours and providing an initial assessment within 7 days.
| Level | Criteria | Example |
|---|---|---|
| P1 – Critical | Active exploitation, data breach in progress, or credential compromise | Leaked API keys found in logs; active data exfiltration |
| P2 – High | Vulnerability exploitable without authentication, or significant data exposure | Unauthenticated endpoint bypassed; PII query result in error log |
| P3 – Medium | Exploitable with authentication, or limited impact | Authenticated user can access another user's read-only data |
| P4 – Low | Theoretical risk, no active exploitation | Verbose error message reveals stack trace |
| Severity | Detection → Triage | Triage → Containment | Resolution |
|---|---|---|---|
| P1 | 15 min | 1 hour | 4 hours |
| P2 | 1 hour | 4 hours | 24 hours |
| P3 | 4 hours | 24 hours | 7 days |
| P4 | 24 hours | 7 days | 30 days |
- Confirm the incident is real (not a false alarm)
- Determine severity using the table above
- Assign an Incident Commander (IC)
- Open a private incident channel (Slack/Discord/email thread)
- Isolate affected systems (disable credentials, block IPs, take service offline if necessary)
- Preserve logs and evidence before making changes
- Notify stakeholders per the communication plan below
- Remove the root cause (patch code, rotate credentials, fix misconfiguration)
- Verify the fix does not introduce new issues
- Deploy to staging and validate
- Deploy fix to production
- Gradually restore service (canary if possible)
- Monitor closely for 24 hours post-recovery
- Within 5 business days of resolution
- Document: timeline, root cause, impact, fix, action items
- Update runbooks and monitoring based on learnings
- Share a sanitised summary with affected customers if applicable
| Resource | Contact / URL |
|---|---|
| AWS Support | https://console.aws.amazon.com/support (create case) |
| Azure Support | https://portal.azure.com → Support + troubleshooting |
| GCP Support | https://console.cloud.google.com/support |
| GitHub Security Advisories | https://github.com/advisories |
| Domain Registrar | (update with your registrar's emergency contact) |
- Notify all engineers with production access immediately for P1/P2
- Use a dedicated private channel; do not discuss in public channels
- For personal data breaches: notify the relevant Data Protection Authority within 72 hours of becoming aware
- Notify affected data subjects without undue delay if the breach is likely to result in high risk to their rights
- For P1/P2 incidents affecting customer data: notify affected customers within 24 hours of confirmed impact
- Include: what happened, what data was affected, what actions customers should take
- Incident timeline documented
- Root cause identified and fixed
- All affected credentials rotated
- All affected sessions invalidated
- Monitoring/alerting updated to detect recurrence
- Post-mortem written and shared
- GDPR notification filed (if applicable)
- Runbooks updated
- Action items tracked in issue tracker
See .github/runbooks/ for step-by-step procedures: