feat(sigma): ship the fifteen sequence detections as Sigma rules

[blitzcrieg1]

The Sigma pack covered the recorder's own health — heartbeat silence, degraded coverage, MCP schema drift, denial bursts, untriaged criticals. All useful, none of it the product.

The fifteen sequence detections, which are what a SOC actually routes on, had no Sigma representation at all. A Splunk or Sentinel team wanting to alert on credential-exfil had to write the search themselves from a schema document.

That is a strange gap for a project whose pitch is "your SIEM stays the console." If the console is theirs, the content has to be portable.

Generated, not written

Hand-writing fifteen would put rule ids, severities and MITRE ids in a second place that drifts from the first — the failure this repo keeps finding in its own documents. tools/generate_sigma_pack.py replays the benchmark corpus through the real engine and reads the Detection objects it emits, so a severity that changes in rules.py changes here on the next run.

detection:
  selection:
    action.type: detection
    detection.rule_id: credential-exfil
  condition: selection
level: critical
tags: [attack.ta0006, attack.ta0011, attack.t1071.001, attack.t1552.004]

Sixteen files for fifteen rules, and the extra one is a real finding

encoded-command-download emits two severities on purpose: critical for remote code fetched and executed, low for local content piped into an interpreter, with a comment in rules.py saying the low one exists "so it stops drowning the criticals".

Keying the pack on rule_id alone produced a single rule at whichever severity the corpus yielded first — it claimed critical while some firings are low. A test caught it:

AssertionError: encoded-command-download: engine says low, Sigma says critical

Each severity now gets its own rule with the selection pinned on action.outcome. One static level would either page on the quiet variant or stay silent on the loud one.

Five tests

Every built-in rule has a Sigma rule; no Sigma rule outlives a deleted one; severities match what the engine emits; the documents are valid Sigma; and the UUIDs do not churn on regeneration (they are derived from the rule id, so a consumer who pinned one keeps working).

The two with no corpus case

host-subagent-swarm-burst needs several sessions on one host. off-hours-activity is opt-in behind an env var and a window. Both carry an explicit entry in the generator with the reason, and that table is checked against BUILTIN_RULE_IDS rather than trusted — a sixteenth rule with neither a corpus case nor an entry fails the script instead of silently shipping a pack that claims more than it has. Tracked in #36.

Also

CI now lints tools/, since the generator lives there and emits rules a SOC routes on. That surfaced one pre-existing S101 in mcp_audit_proxy.py — a type-narrowing assert after create_subprocess_exec — annotated rather than rewritten.

• 1125 tests, ruff clean
• Ruleset fingerprint unchanged at 56ad3de1, so the dogfood clock is untouched (the generator reads rules.py, never writes it)

🤖 Generated with Claude Code