Neura Market Logo

Security Incident Response: Triage, Severity, and Follow-Up

Learn how OpenClaw detects, triages, and responds to security incidents. This guide is for maintainers and security engineers responsible for incident handling.

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 signals come from:

  • GitHub Security Advisories (GHSA) and private vulnerability reports.
  • Public GitHub issues and discussions when reports are not sensitive.
  • Automated signals: Dependabot, CodeQL, npm advisories, secret scanning.

Initial triage:

  1. Identify the affected component, version, and trust boundary impact.
  2. Determine whether it is a security issue or a hardening or no-action case, following SECURITY.md's scope and out-of-scope rules.
  3. An incident owner responds accordingly.

2. Severity

SeverityDefinition
CriticalCompromise of a package, release, or repository, active exploitation, or an unauthenticated trust-boundary bypass that leads to high-impact control or data exposure.
HighA verified trust-boundary bypass that requires limited preconditions (for example, an authenticated but unauthorized high-impact action), or exposure of OpenClaw-owned sensitive credentials.
MediumA significant security weakness with practical impact, but constrained exploitability or substantial prerequisites.
LowDefense-in-depth findings, narrowly scoped denial-of-service, or hardening or parity gaps without a demonstrated trust-boundary bypass.

3. Response

  1. Acknowledge receipt to the reporter (privately when sensitive).
  2. Reproduce the issue on supported releases and the latest main, then implement and validate a patch with regression coverage.
  3. For critical or high severity: prepare patched release(s) as quickly as practical.
  4. For medium or low severity: patch in the normal release flow and document mitigation guidance.

4. Communication and disclosure

Communicate through GitHub Security Advisories in the affected repository, release notes and changelog entries for fixed versions, and direct follow-up with the reporter on status and resolution.

Critical and high incidents get coordinated disclosure, with CVE issuance when appropriate. Low-risk hardening findings may be documented in release notes or advisories without a CVE, depending on impact and user exposure.

5. Recovery and follow-up

After shipping the fix:

  1. Verify remediations in CI and release artifacts.
  2. Run a short post-incident review covering timeline, root cause, detection gap, and prevention plan.
  3. Add follow-up hardening, tests, and documentation tasks and track them to completion.