Incident Response: Detection, Triage, Severity, and Follow-Up
This page explains how OpenClaw detects, triages, and responds to security incidents. It is intended for incident responders and security engineers who need to understand the classification and handling process.
Read this when
- Responding to a security report or suspected security incident
- Preparing a coordinated disclosure or patched security release
- Reviewing post-incident follow-up expectations
1. Detection and triage
Security events originate from these sources:
- GitHub Security Advisories (GHSA) along with private vulnerability reports.
- Public GitHub issues or discussions when reports do not require confidentiality.
- Automated detection: Dependabot, CodeQL, npm advisories, and secret scanning.
Initial response steps:
- Identify the affected component, its version, and the trust boundary impact.
- Determine whether the finding is a genuine security issue or qualifies as hardening or no action, guided by
SECURITY.md's scope and out-of-scope definitions. - The incident owner takes appropriate action based on the classification.
2. Severity
| Severity | Definition |
|---|---|
| Critical | Compromise of a package, release, or repository; active exploitation; or an unauthenticated trust-boundary bypass that leads to high-impact control or data exposure. |
| High | A confirmed trust-boundary bypass that requires limited preconditions (for example, an authenticated but unauthorized high-impact action), or disclosure of OpenClaw-owned sensitive credentials. |
| Medium | A notable security weakness that has practical impact but is constrained by exploitability or requires significant prerequisites. |
| Low | Defense-in-depth observations, narrowly scoped denial-of-service issues, or hardening or parity gaps that do not demonstrate a trust-boundary bypass. |
3. Response
- Send an acknowledgment to the reporter, privately if the report is sensitive.
- Reproduce the issue on supported releases and the latest
main, then develop and validate a fix with regression tests. - For critical and high severity issues, prepare patched releases as quickly as feasible.
- For medium and low severity issues, include the fix in the normal release cycle and provide mitigation guidance.
4. Communication and disclosure
Communication happens through GitHub Security Advisories in the affected repository, release notes or changelog entries for fixed versions, and direct updates to the reporter on status and resolution.
Coordinated disclosure is used for critical and high incidents, with a CVE issued when appropriate. Low-risk hardening findings may appear in release notes or advisories without a CVE, based on impact and user exposure.
5. Recovery and follow-up
After the fix is shipped:
- Confirm the remediation in CI and release artifacts.
- Conduct a brief post-incident review covering timeline, root cause, detection gaps, and a prevention plan.
- Create follow-up tasks for hardening, tests, or documentation and track them until complete.
Related
- Security policy, defines report scope and the trust model.
- Threat model