version: 0.1.0
security-incident-responseOverview
Has occurred / Suspected to have occurredStandard response process for security incidents. This is security-and-hardening(while writing code) and security-devsecops(before deployment), both arenotcovered—they are preventive, whereas this skill is reactive.
Important premise: Even as a non-professional individual developer, you must assume you will encounter security incidents (credential leaks / dependencies with implanted backdoors / data exfiltration caused by misconfiguration / being phished).Having a response process vs. not having onedecides whether an incident is a "minor accident" or a "disaster".
Boundaries with sibling skills：
| Stage | Skill | Focus |
|---|---|---|
| While writing code | security-and-hardening |
input / auth / OWASP / secrets-in-code |
| After finishing → before going live | security-devsecops |
deps / SBOM / rotation / CI/CD / IaC / pre-deploy gate |
| Under attack / Suspected of being attacked | security-incident-response(this skill) |
detect → triage → contain → eradicate → recover → postmortem |
OMO integration：
security-researchmode runs post-incident root cause analysis (3 hunters + 2 PoC re-examine code + configuration)oracleagent decision chain (impact assessment / when to notify users / whether to disclose publicly)websearchMCP checks CVE advisories / attack IOCs (indicator of compromise)context7MCP checks incident response tool documentationreview-workskill runs post-incident code review
When to Use
Use when:
- Monitoring alerts trigger (abnormal logins / abnormal traffic / abnormal API calls)
- User reports anomalies ("My account was stolen" / "I saw data I shouldn't have seen")
- Third party discloses a CVE affecting your dependencies (known exploited CVE in dependencies)
- Credential leak (API key committed to a public repo / secret manager dumped)
- Receiving extortion / threat messages
- Discovering unknown accounts / unknown processes / unknown outbound connections in the system
- Suspected supply chain attack (suspicious dependency packages / abnormal pull counts)
NOT for:(scenario description—which skill to use specifically is decided by description matching)
- Prevention while writing code →
security-and-hardening - Supply chain before deployment →
security-devsecops - Normal operation monitoring after deployment (no incident triggered) →
observability-and-instrumentation - Bug debugging (not security-related) →
debugging-and-error-recovery
Process
Simplified to 6 stages according to NIST CSF.Skipping steps at any stage = risk—for example, Eradicate without doing Triage may miss a second attack entry point.
1. Detect — identify the incident
Trigger source：
- Monitoring alerts (Sentry / Datadog / SIEM)
- User reports ("My account was stolen")
- Third-party advisories (CVE / vendor notifications)
- Self-discovery (abnormal commits / abnormal outbound traffic)
First action (regardless of trigger source)：
- Record timestamp: incident start = the earliest suspicious time you know (not the discovery time)
- Freeze evidence: Do not immediately modify the affected system, to avoid destroying forensic evidence
- Pull an independent note：
docs/incidents/<incident-id>/incident.md(git tracked incident archive; do not write to the victim system's logs, because the logs may already be compromised; incident notes are independent of.omo/notepads/<plan>/'s per-plan namespace, because incidents span plans)
Do not：
- ❌ Do not issue a public statement first (incomplete information will be distorted)
- ❌ Do not reset the affected accounts first (this may destroy the chain of evidence / prevent the attacker from continuing operations that help you locate them)
- ❌ Do not restart the server (this loses in-memory evidence)
2. Triage — Severity + Scope of Impact
Severity(classified by consequence, not by "how big it looks"):
| Level | Criteria | Examples |
|---|---|---|
| Critical | Data loss / large-scale leakage of user credentials / service outage / financial impact | Full DB table dump / admin token made public / ongoing ransomware |
| Major | Limited-scope data / credential leakage / service degradation | Single user token leakage / single endpoint data exfiltration / short-lived DDoS |
| Minor | Potential risk but no confirmed actual impact / known CVE but no observed exploitation | CVE announced but not yet affecting / suspicious login but not confirmed successful |
Scope of Impact Assessment(use oracle agent to decide):
- Which users are affected? (user count / user type / whether PII is included / whether payment information is included)
- Which data is affected? (type / volume / whether encrypted)
- Which systems are affected? (isolated or did lateral movement occur)
- Can the attacker still access? (active or historical)
Output: add a severity + scope of impact section to the incident notes
3. Contain — Stop the Bleeding
Act with least privilege first— take only the minimal action to cut off the attacker's access:
| Scenario | Action |
|---|---|
| Credential leakage (API key / DB password) | revoke + rotate (no need to stop the service, but all callers must update immediately) |
| Single account compromised | Freeze the account + revoke all session tokens + force password reset |
| Entire service compromised | Switch traffic to a maintenance page (do not take it offline directly; observe the attacker's behavior first) |
| Ransomware | Isolate the infected host(disconnect network but do not cut power), do not restart |
| Data exfiltration in progress | Cut off outbound network (firewall rules / WAF), preserve logs |
Do not do：
- ❌ Do not directly patch the vulnerability (this is the Eradicate phase)
- ❌ Do not notify users (decide after Triage is complete)
- ❌ Do not restore data (this is the Recover phase)
4. Eradicate — Root Out
Clean up all traces left by the attacker:
| Trace | Handling |
|---|---|
| Backdoors / newly added accounts / modified config | Delete + revert to a known clean commit |
| Credentials (even if already rotated) | Reset all, including those of the backup system |
| Persistence mechanisms (cron / systemd / SSH key) | Full audit and removal |
| The vulnerability itself | patch / upgrade / replace dependencies |
| Infected binary / container image | rebuild from clean source + verify checksum |
OMO enhancement: use security-research mode to run post-incident root cause analysis:
/security-research --scope "post-incident on <incident-id>"
3 hunters each review one attack surface; 2 PoC engineers write working exploits to verify the vulnerability has been thoroughly patched.
5. Recover
Restore from a clean backup / redeploy:
- Restore from a known clean backup / commit, not from a compromised snapshot
- Replace all credentials(not just rotate,all replaced with new ones)
- Redeploy the service (with a clean image + clean config)
- Strengthen monitoring(add a specific alert for this attack vector)
- Verify the service has returned to normal + there is no residue
Communicate(as required by law / user contracts):
- User notification: within the time limits of GDPR / CCPA / industry regulations (e.g., GDPR 72 hours)
- Regulatory reporting: according to the compliance framework
- Public statement: usually required for critical / major; not necessarily for minor
6. Postmortem
blameless postmortem: the purpose is learning, not assigning blame.
Template(write to docs/incidents/<incident-id>/postmortem.md):
# Postmortem — <incident-id>
## Summary
- 触发: <一句话>
- 严重度: Critical / Major / Minor
- 影响范围: <users / data / systems>
- 检测时间 / 止血时间 / 根除时间 / 恢复时间
- 总时长: <duration>
## Timeline
- <t0>: <可疑起点>
- <t1>: <detect>
- <t2>: <triage done>
- <t3>: <contain done>
- <t4>: <eradicate done>
- <t5>: <recover done>
## Root cause (5 whys)
1. Why 1:...
2. Why 2:...
3. Why 3:...
4. Why 4:...
5. Why 5: <根本原因>
## Action items
- [ ] 改 spec / 加 checklist
- [ ] 加监控 / alert
- [ ] 加测试
- [ ] 改流程
- [ ] **Re-run `security-threat-model` on the affected boundary** — if the postmortem 5-whys surfaced a missing trust boundary, missing control, or a new attacker profile, re-model and re-issue the mitigations table (closes the incident→design feedback loop)
## Lessons
- <一句话核心学习>
5 whys is the core: don't stop at the surface. For example, "credential leak" is not the root cause; keep asking "why was it committed to a public repo" → "because .env wasn't added to .gitignore" → "because dev didn't know to add it" → "because the onboarding doc didn't say so" → "because the spec didn't require it".
7. Close incident and publish cleanup state
Only after Recover and Postmortem verification, close the incident with the real slug and UTC timestamp substituted:
printf '%s\n' '{"status":"closed","closed_at":"<iso8601>"}' > docs/incidents/<incident-id>/closed.json
Then append this row to .omo/notepads/<plan>/decisions.md:
[incident:closed] ts=<iso8601> incident=<incident-id> closed=docs/incidents/<incident-id>/closed.json
Writing docs/incidents/<incident-id>/closed.json marks the incident closed. Do not emit either record before all close checks pass, and do not delete the incident evidence directory.
Common Rationalizations
| Excuse | Reality |
|---|---|
| "It's a minor incident, no need to go through the full process" | Severity determination is the job of the Triage phase, not a reason to skip phases. The process is for incidents of all severities |
| "Patch first, then triage, to save time" | Without Triage you don't know where the second attack entry point is. Skipping Triage = opening a back door for attackers |
| "Don't tell users, to avoid panic" | GDPR / CCPA / user contracts have mandatory time limits. Not notifying = legal risk |
| "Evidence isn't important, restore the service first" | Forensic evidence is key to assigning blame / preventing recurrence / legal proceedings. Evidence must be preserved before recovery |
| "We don't have a security team, incident response doesn't apply" | Individuals / small teams need the process even more—they don't have dedicated security staff as a safety net. The process is insurance for "still doing the right thing when something goes wrong" |
| "Just reset the affected accounts, no need to replace all credentials" | It is the norm that attackers have already performed lateral movement.All reset |
| "A public statement will make users run away" | A public statement is a legal obligation + long-term trust. Not disclosing = trust collapse once users find out |
| "Writing the postmortem is enough, no follow-up action needed" | No action item = the same cause happens again next time. Action is the output of incident response |
Red Flags
- Resetting affected accounts during the Triage phase (destroys the chain of evidence)
- Recovering immediately after Contain (skipping Eradicate = the attacker is still there)
- Eradicate without verifying the vulnerability is thoroughly patched (use security-research to run a PoC)
- Recover using a compromised backup (must restore from a known clean source)
- Postmortem skipping the 5 whys (stopping at the surface)
- Postmortem finding no action item (the process was wasted)
- Critical / major does not notify users (violates law + trust)
- After an incident is handled, the runbook is not updated (next time it's still a scramble)
- Sibling skill triggers: write code to prevent (go through security-and-hardening) / pre-deployment supply chain (go through security-devsecops)
Verification
After completing this skill, confirm:
- incident notes have been written to
docs/incidents/<incident-id>/incident.md(including timeline + evidence preservation section) - severity + impact scope have been recorded (Triage section)
- Contain actions have been completed + recorded
- Eradicate verification: OMO
security-researchrun the post-incident PoC, confirm the vulnerability has been thoroughly patched - Recover uses a clean source + all credentials have been reset
- User notification has been sent within the legal time limit (critical / major mandatory)
- Postmortem has been written: 5 whys + action items + lessons
- Runbook has been updated (next incident will no longer be a scramble)
-
docs/incidents/<incident-id>/closed.jsonhas been written, and.omo/notepads/<plan>/decisions.mdhas been appended[incident:closed]row - incident evidence directory is still retained
- This skill has not made anyunauthorizedcode changes (only minimal isolation + patching)
omo Integration
Use task tools/Boulder for incident phases, oracle for impact decisions, notepad/evidence ledger for the timeline, and review-work for the postmortem gate.
Related Skills
- When writing code：
security-and-hardening— app-layer prevention - Before deployment：
security-devsecops— supply chain + deployment prevention - Runtime monitoring：
observability-and-instrumentation— detecting anomalous alerts is the input source for this skill's Detect phase - Fix implementation: incident-triggered fixes go through
incremental-implementationKanban ticket - Bug debugging：
debugging-and-error-recovery— non-security bugs - OMO tools：
security-researchmode — post-incident root cause + PoC verificationoracleagent — impact assessment + decision chainwebsearchMCP — CVE advisories + attack IOCscontext7MCP — incident response tool documentationreview-workskill — post-incident code review