Detection-rule generation Turn an IR finding into a portable Sigma rule that any SIEM can consume. Closes the gap between "we noticed something here" and "every host runs a detection for it."

Why this exists

Findings answer "what happened on this host?" Detection rules answer "what should fire on any host when this happens again?" The hand-off between investigation and detection engineering is, in most orgs, a human Slack message. digger automates it: a finding's evidence carries enough structure to write the corresponding Sigma rule mechanically, with a stable UUID, ATT&CK tags, and a reference back to the original case for provenance.

Two paths: per-finding vs per-detector

digger emits Sigma in two distinct flows:

• Per-finding rules (--case-dir DIR) — walks every finding in the case and emits a rule scoped to that specific observation. Stable UUIDs (SHA-256 of finding content), so re-running on the same case overwrites the same file.
• Per-detector templates (--from-detectors) — emits one generic, class-level rule per detector that implements to_sigma_template(). No case required. Useful when you want SIEM-deployable detection logic without running a case first.

Run it

# Per-finding mode
digger generate sigma --case-dir ./case-1
# generated 4 Sigma rules from 7 findings
# out: ./case-1/sigma-out

# Just one finding by UUID
digger generate sigma --case-dir ./case-1 --finding ae6b2cac-b996-4a29-bc2e-15e86d4f5412

# Custom output directory
digger generate sigma --case-dir ./case-1 --out-dir ./sigma-rules/

# Per-detector templates (no case needed)
digger generate sigma --from-detectors --out-dir out/sigma/
# generated 13 per-detector Sigma templates
# out: out/sigma

# Verbose: print every written filename
digger generate sigma --case-dir ./case-1 -v

Each rule lands in its own .yml file named <uuid>_<title>.yml. The UUIDs are deterministic (SHA-256 of the finding content), so re-running on the same case overwrites the same files rather than producing duplicates.

What gets mapped

Findings whose evidence doesn't map cleanly to a Sigma log source (memory_anomaly, unsigned_binary, browser extension permissions, etc.) are silently skipped — the generator returns None and the CLI reports the count delta.

Per-detector templates (to_sigma_template())

The base Detector class exposes a to_sigma_template() classmethod. A detector that implements it declares a generic SIEM rule for the class of behavior it watches — independent of any specific case finding. The --from-detectors CLI flag iterates every registered detector and writes one rule per implementer.

Every Decepticon-countermeasure detector ships a template; the test tests/test_genrule_detector_templates.py round-trips each generated rule through SigmaLoader to enforce validity.

Sample output

title: 'Shai-Hulud compromised npm package: chalk@5.6.1'
description: 'package on the worm list.
  Auto-generated from digger finding ae6b2cac-b996-4a29-bc2e-15e86d4f5412.'
id: 42ca0822-82c9-4ed2-a356-a8b4c051d4fa
status: experimental
author: digger
date: 2026/05/21
modified: 2026/05/21
references:
- digger-case://sigma-demo/ae6b2cac-b996-4a29-bc2e-15e86d4f5412
level: critical
tags:
- attack.t1195.002
- attack.initial_access
- attack.supply_chain_compromise
falsepositives:
- Investigate context before alerting on this rule.
logsource:
  category: file_event
detection:
  selection:
    TargetFilename|endswith: /node_modules/chalk/package.json
    TargetFilename|contains: /node_modules/
  filter_version:
    TargetFilename|contains: '"version": "5.6.1"'
  condition: selection AND filter_version

From digger to your SIEM

The generated rules are standard SigmaHQ format. Feed them through sigma-cli / pySigma to compile to your SIEM's query language:

# Splunk
sigma convert -t splunk -p sysmon ./case-1/sigma-out/*.yml

# Elastic
sigma convert -t lucene -p ecs_windows ./case-1/sigma-out/*.yml

# Microsoft Sentinel (KQL)
sigma convert -t microsoft_sentinel ./case-1/sigma-out/*.yml

# Chronicle (YARA-L)
sigma convert -t chronicle ./case-1/sigma-out/*.yml

The Sigma references field carries digger-case://<case_id>/<finding_uuid> so the provenance survives every back-end conversion — if a deployed rule fires in production, an analyst can trace it back to the original investigation.

Detection-engineering workflow

# 1. Investigation produces findings on host-of-interest
digger investigate --case-dir ./case-2026-05-21

# 2. Auto-generate Sigma from the findings
digger generate sigma --case-dir ./case-2026-05-21

# 3. Review (pruning over-broad rules, tightening selectors)
# 4. Commit to your detection-rules repo
# 5. CI compiles for your SIEM and deploys
# 6. The same kind of activity now fires on every host in scope

Limits

• Sigma can express log-pattern matching, not arbitrary correlation. Findings that derive their signal from multi-artifact relationships (timeline, persistence outlier with multiple paths) produce simpler one-condition rules — review before deploying.
• Selectors generated from CLI patterns may be over-specific (catches this exact malware, misses tomorrow's variant). The auto-generated rule is a starting point, not a finished detection.
• Sigma's log-source vocabulary is finite. Memory-region anomalies, signature mismatches, and browser-extension permission findings have no canonical log source — these are explicitly not faked.