Converting Sigma with pySigma and what breaks

Sigma is a rule format. It is not a detection platform. It has no runtime, no scheduler and no alert queue. That is the point: you write a rule once and convert it for whichever SIEM you run. The conversion is where the trouble lives, so this guide covers the tools and then the failures.

Sigma gives you a format and a converter, nothing else

The pieces are the Sigma rule specification, the pySigma library and the sigma-cli command line. pySigma documents converting rules into queries, and sigma-cli runs the conversion, for example sigma convert -t splunk (pySigma docs, read 2026-11-03). sigma-cli also lists backends and installs plugins. pySigma documents a validation step for rules.

What the pages read do not describe is deployment. Sigma has no step that puts the converted query into a SIEM as a scheduled rule. You or your platform supply that step.

The Sigma repository runs its own GitHub Actions workflow named Sigma Rule Tests, which includes yamllint and logsource tests (Sigma test workflow, read 2026-11-03). Copy that pattern for your own rules. It checks the rule files, not your SIEM.

Backends decide where a rule can go and how well

A backend turns Sigma into one query language. The Sigma docs list backends with a status. The Kusto backend produces KQL and is listed as Stable. The Splunk backend produces SPL. The Elasticsearch backend produces Lucene, ES|QL with correlations, and EQL queries. The Google SecOps backend produces UDM searches and YARA-L 2.0 detection rules and is listed with status Development (Sigma backends, read 2026-11-03).

Read the status column before you commit a whole estate to a path. Stable and Development are different promises. If you run Google Security Operations, expect to review converted output by hand.

No backend count is published on the README or the pySigma page, so any vendor number for "Sigma targets" is its own claim. SOC Prime's Uncoder pages claim 48 targets for Sigma conversion on one page and 65 translation languages on another, and name none of them (SOC Prime Prime Architect, read 2026-11-03). Ask for the list before you rely on the number.

Some platforms take Sigma without a converter

Panther documents a Converting Sigma Rules page: sigma-cli converts Sigma rules into Panther Simple or Python detections (Panther Sigma conversion, read 2026-11-03). The output is a Panther detection, so it joins your Panther CI and tests.

Sekoia documents native Sigma YAML, including event_count, value_count and temporal correlation (Sekoia Sigma rules, read 2026-11-03), and an API call to create a Sigma rule (Sekoia create a Sigma rule, read 2026-11-03). Native support removes the translation step and with it one failure class. It also ties your rules to one vendor's interpretation of the spec.

Six places a conversion quietly breaks

Conversion errors are rarely loud. The query compiles, runs and returns nothing. These are the six to check. They come from practice, not from any vendor page.

1. Field mapping. Sigma rules use generic field names. Your data uses another set. Without a mapping step, the converted query references fields that do not exist in your index. pySigma handles this with processing pipelines that you configure per backend and per log source. Keep the pipeline in the repo and test it.
2. Logsource mapping. A rule's logsource says category, product and service. The backend has to turn that into an index, table or data model. A wrong mapping searches the wrong place, or everything.
3. Correlation. Sigma has a correlations section in its specification (Sigma correlations, read 2026-11-03). Backend support differs. The Elasticsearch backend lists ES|QL with correlations. Do not assume your target does. Check whether a correlation rule converted to one query or silently dropped the aggregation.
4. Modifiers. Regular expressions, CIDR matching, base64 and wide-character modifiers translate differently or not at all. Case sensitivity differs between engines, so a match in one is a miss in another.
5. Metadata. A converted query has no severity, no schedule, no ATT&CK tags and no alert title unless your deployment step adds them. A query without a schedule never runs. Carry the tags and level from the Sigma file into the SIEM rule object.
6. Rule status. Sigma rules carry a status of stable, test, experimental, deprecated or unsupported (Sigma specification, read 2026-11-03). Convert only stable and test rules to production, and route experimental rules to a staging workspace.

Test the converted rule, not the Sigma rule

A Sigma rule passing yamllint proves the file is valid. It proves nothing about the converted query on your data. Run the conversion in CI, then run the output against the same positive and negative events you use elsewhere. Panther's test command, Splunk's contentctl test and a replay window all work for this, depending on target.

Diff the converted query between runs. When pySigma or a pipeline changes, the output changes, and a quiet change in a regex translation is the kind of bug a diff catches in code review.

Where Sigma fits in your estate

Sigma suits a team that runs more than one SIEM, or expects to change. It suits a team that wants rules portable and reviewable. It suits a team that accepts writing the field mapping once. It does not suit a team that wants health, coverage and testing from the format: the pages read document none of those for Sigma itself, which is a rule format with no runtime.

Checklist

• Pin the pySigma version and backend plugin versions in the repo.
• Keep the processing pipeline file in git and test it.
• Run conversion in CI and fail on any rule that does not convert.
• Diff converted output on every pull request.
• Check backend status before choosing a target.
• Carry severity, schedule and ATT&CK tags into the deployed rule.
• Convert only rules with status stable or test to production.
• Run converted rules against positive and negative events before enabling.