/omh-security-event-response

name: "omh-security-event-response"
description: "[omh] Security event on the code already shipped -- a CVE in a dependency, a secret committed to the repo, a license question, an advisory: triage reachability and severity, contain in order, and never close a leaked secret before its rotation is observed. Use when the user says: security-event-response, security event response, cve, triage this cve, cve in our dependency, cve in a dependency, security advisory, dependabot alert."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, review]
    category: review
    phase: security-event-response
    role: reviewer
    quality_tier: event-closure-gated

Security Event Response

This is a Hermes-native `security-event-response` workflow skill.

Why This Exists

`security-event-response` exists because an event had no owner: `security-safety-review` and `application-threat-model` review a design before it ships, and a CVE, a committed secret, or a license question was answered by onboarding, review, or an achievements lane with no containment order at all.

First Steps

• Classify the event and state its exposure window before proposing any step.
• For a leaked secret, order the rotation and its observed rejection before any history rewrite.

Do Not Use When

• Nothing has happened yet and the ask is a review of prompts, tools, or permissions before execution; use `security-safety-review`, which also owns a planned rotation with no exposure.
• The subject is a design's assets, trust boundaries, and attack scenarios; use `application-threat-model`.
• A dependency moves to a new version as routine maintenance with no advisory or leak attached, such as a dependabot bump; use `refactor-plan`.
• The question is a contract, a privacy obligation, or legal advice beyond a dependency's declared terms; use `legal-compliance-review`.
• Production is down or degraded right now and the ask is command of the incident; use `live-incident-response`.

Examples

Good example:

• Prompt: we committed a secret, what now
• Expected behavior: Record the credential type, scope, and exposure window, then prepare containment_plan/v1: revoke and replace, observe the old credential rejected, audit its use in the window, and only then rewrite history; the closure verdict stays open until the rotation is observed.
• Why: A rewritten history does not revoke a secret that was already cloned or scraped.

Bad example:

• Prompt: just force-push the history without the key and we are done
• Expected behavior: Refuse to close: rotate first, observe the old key rejected, then rewrite, and name what is still unobserved.
• Why: Rewriting history first leaves a live credential in every clone and cache made before the push.

Completion Checklist

• The event kind, source, and exposure window are stated.
• Every severity call cites the reachable path or its observed absence.
• A leaked secret's rotation precedes any history rewrite in the plan.
• The closure verdict is closed only when the rotation or fixed version is observed.
• No secret value appears anywhere, and OMH scanned, contacted, or rotated nothing.

Recovery Notes

• If the exposure window is unknown, treat the secret as exposed from its first push and say so.
• If no reachability evidence is available, keep the advisory's own severity and mark the adjustment unverified.

Workflow Lane

• Current lane: **Coding handoff** (`idea-to-deploy`, `llm-app-dev`, `cto-loop`, `deploy-and-monitor`, `code-review`, `build-failure-triage`, `verification-gate`, `security-safety-review`, `+28 more`) - coding owners, handoffs, review, CI, and merge evidence.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Use When

Use when a security event has already happened to code that exists: a CVE or advisory in a dependency, a secret or credential committed or pushed, a dependency whose license may not fit the product, or an advisory that forces a major version. The output is reachability, a severity call, containment steps in order, and what must be observed before the event closes; OMH never scans, never contacts a registry, and rotates nothing.

Strong routing signals: `security-event-response`, `security event response`, `cve`, `triage this cve`, `cve in our dependency`, `cve in a dependency`, `security advisory`, `dependabot alert`, `dependabot security`, `vulnerable dependency`, `vulnerability in our dependency`, `reachability analysis`, `npm audit`, `committed a secret`, `committed an api key`, `leaked secret`, `leaked a secret`, `leaked credential`, `leaked api key`, `leaked an api key`, `leaked aws key`, `leaked an aws key`, `secret in git history`, `secret in the history`, `dependency license`, `dependency's license`, `license ok`, `license compatibility`, `license compatible`, `gpl dependency`, `agpl dependency`

Catalog Metadata

Category: `review` Phase: `security-event-response` Hermes role: `reviewer` Quality tier: `event-closure-gated` Reasoning demand: `standard`

Quality bar:

• Classify the event first; each kind has its own containment order.
• Load `references/event-containment-order.md` for the per-event containment order, the severity adjustment, and the license obligation table instead of recalling them.
• Adjust severity by reachability: a critical advisory on a function nothing calls is not the same event as one on the request path.
• Keep prepared, observed, and closed as separate states for every containment step.
• Hand a fix that needs a planned version jump to its own upgrade plan, and keep this event open until that fix is observed.

Handoff policy:

Keep the event record, the reachability call, the ordered containment plan, and the closure verdict in Hermes. Scanner output, advisory text, registry metadata, rotations, revocations, and history rewrites are recorded o