pySigma: parsing Sigma rules without shipping a vendor plugin per target

A slim core, and a plugin ecosystem around it

pySigma is a Python library that parses and converts Sigma rules into queries. It is a replacement for the legacy Sigma toolchain, sigmac, with a much cleaner design, and it is described as almost fully tested.

The architectural decision is stated immediately and it is the one that matters. Backends for support of conversion into query languages, and processing pipelines for transforming rules for log data models, are separated into dedicated projects to keep pySigma itself slim and vendor agnostic.

The README restates the philosophy in the related projects section. pySigma isn't a monolithic library attempting to support everything but the core. Support for target query languages and log data models is provided by additional packages that extend pySigma.

The list of those packages includes sigma-cli, a command line interface for conversion of Sigma rules based on pySigma, which is the equivalent of sigmac for command line work. Then backends for Splunk, NetWitness and Panther, and pipelines for Sysmon and CrowdStrike.

This is a meaningful departure from how sigmac worked, and it explains the number of separate repositories. sigmac had everything in one tool, which meant adding a target meant adding to the monolith. Here, a backend is a separate package with its own release cycle, and the core only has to know how to find and load them.

The project is under active work. The last push was on 2026-10-18, and the recent releases are v1.5.1 on 2026-09-21, v2.0.0 on 2026-10-04 and v2.0.1 on 2026-10-11, so a major version landed two weeks before the most recent release.

Installing, and the Python floor that moved with 2.0

Getting started requires Python 3.11 or later, and the installation is a normal package manager call with three examples given:

pip install pysigma
pipenv install pysigma
poetry add pysigma

The dependency list in pyproject.toml is worth reading because it tells you what the parser is built on. pyparsing at 3.2.5 or newer is the grammar engine, and pyyaml handles the YAML that Sigma rules are written in. Then there is packaging, requests, jinja2 for templating, diskcache with its stubs, jq for JSON processing, and google-re2 for the regular expressions.

That RE2 dependency is a detail with a purpose. A conventional regex engine backtracks and can be made to run for a very long time on a crafted pattern, and a rule parser that runs untrusted or community-supplied Sigma rules is exactly where that matters. RE2 gives linear time matching with no backtracking, so a pathological rule cannot hang the converter.

The diskcache dependency serves a similar purpose in a different place. Converting a large rule set against a back end means repeated lookups, and a disk-backed cache keeps that cheap without holding everything in memory.

The development and quality tooling is current. The dev group pins black at 26.3.1 with a line length of 100, pytest at 9.1 with pytest-cov and pytest-mypy, mypy 2.3, pylint 4.0, pre-commit 4.6, Sphinx 8 and defusedxml. The pytest configuration sets filterwarnings to ignore DeprecationWarning and defines a marker named online, which is a useful convention, since it lets the test suite mark the tests that reach out to the network so they can be deselected.

The build backend is poetry-core 2.1.0 or newer, and the classifiers list Development Status :: 4 - Beta along with Python 3.11 through 3.14.

Backends, pipelines and how the conversion is put together

The overview section points at two diagrams, one for the conversion and one for pipelines, and the details are in the documentation.

A backend is the thing that knows how to render a rule into a target query language, and the README shows how to list what is available:

use `sigma plugin list --plugin-type backend`

The modifiers are listed separately:

use `sigma list modifiers`

The split into backends and pipelines is the part that needs a moment. A backend answers the question of how to express a condition in the target's query language. A pipeline answers a different question, namely how to transform the rule so it fits the target's log data model, since a Windows event field and a CloudTrail field do not have the same names or the same taxonomy. A rule targeting a particular data source needs both.

That is why the plugin list distinguishes the plugin type, and why there is a separate family of pySigma-pipeline packages alongside the backends. The Sysmon and CrowdStrike pipelines are examples of the second kind.

Writing your own backend has, in the project's words, become much easier. The recommended route is the Cookie Cutter Template, and the existing backends listed in the related projects section are offered as things to review. The point of the template is that a backend author should not have to work out the plugin interface from scratch, and the existing backends are the reference for what a finished one looks like.

The maintainers are Thomas Patzke and François Hubaut, and the project carries a SECURITY.md, which is a reasonable thing for a library that parses content from a community rule repository.

The command line front end, and what the project asks of plugins

The README is explicit that sigma-cli is the equivalent of sigmac for command-line conversion, and the two commands it shows for inspecting what is installed are worth knowing about.

The first lists the modifiers:

use `sigma list modifiers`

The second lists the plugins of a given type, in this case the backends:

use `sigma plugin list --plugin-type backend`

Those two commands are the operational answer to the question that the plugin architecture raises, which is what happens when several plugins are installed and two of them claim the same target. Listing what is present is how you check.

The other thing the README asks of contributors is about the project shape rather than the code. Pull requests are welcome, and issues and pull requests are treated as discussion points, which is a softer and more collaborative framing than a contribution policy with a checklist.

Two smaller signals about how the project is run. The repository carries a .git-blame-ignore-revs file, which is the mechanism for excluding a formatting-only commit from the blame history, and it means the maintainers accept large reformatting commits and still want the blame to be readable afterwards. There is also a print-coverage.py script at the root, which is the kind of small piece of tooling that exists because someone needed the coverage number in a particular form for a release note.

The README also notes that all the related packages can be installed from PyPI if not mentioned otherwise by the Python package manager of your choice. That matters in practice, because the common failure mode with a plugin architecture is a backend that is only in a git repository and therefore only installable from source.

Testing, linting and the contribution path

The toolchain is described plainly enough to be useful.

pySigma uses pytest as the testing framework, and running pytest runs all the tests. For a coverage report, run pytest --cov=sigma. The coverage badge in the README points at a JSON endpoint, and the repository has a print-coverage.py script at the root alongside a mypy.ini and a .git-blame-ignore-revs file, which is the mechanism for excluding a formatting-only commit from the blame history.

For building, poetry build produces the package. For linting, poetry run black formats the code and poetry run black --check checks for linting errors. The project also uses pre-commit, installed by poetry as part of the dev dependencies, and to install the git hooks you run poetry run pre-commit install after cloning the repository and installing the dependencies.

The contributing guidance is short. Pull requests are welcome, and issues and pull requests are treated as discussion points. A blog post by Micah Babinski explains the process of creating a Sigma backend from a developer's perspective, which is the kind of thing that is more useful than the official how-to because it shows the friction.

The documentation is published at sigmahq-pysigma.readthedocs.io, with usage examples.

On licensing, the project is under the GNU Lesser General Public License v2.1, and the pyproject records it as LGPL-2.1-only. The distinction between LGPL and GPL matters for a library like this. The LGPL allows you to use pySigma in a proprietary application as long as you do not distribute a modified version of the library itself, which is a different position from a GPL dependency, and the file-level copyleft applies to the library rather than to what links against it. For an internal security tool this is rarely an issue, but it is worth confirming with whoever handles licensing if you plan to redistribute.

Editorial conclusion

pySigma suits a detection engineering team that wants to write Sigma rules once and convert them to several SIEM query languages without maintaining a fork of sigmac, and the split of backends into separate packages is what makes a large target matrix maintainable. It does not suit you if you need one output format and no plugin architecture, since the backend system is real complexity for a single target. Before you adopt it, check the version carefully, because 2.0.0 landed on 2026-10-04 and 2.0.1 on 2026-10-11, so plugins written for 1.x may not carry over, and note the licence is LGPL-2.1-only, which is fine for internal use but worth checking if you plan to redistribute.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-2.1
3. README
4. Releases
5. SigmaHQ/pySigma on GitHub