Omh Security Event Response

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 only from executor, operator, or wrapper observed output; OMH never scans, contacts a registry, or rotates a credential.

Required inputs:

• the event kind: CVE or advisory, leaked secret, license question, or an advisory that forces a major version
• for a CVE: the advisory id, the affected package and version range, and the installed version from the lockfile
• for a leaked secret: the credential type and scope, where it was pushed, whether the repository is public, and when
• for a license: the package, its declared license, and how the product is distributed
• observed evidence for any containment or closure claim