Cloud Parts

RSigma

A Rust toolkit that parses Sigma rules, compiles them into matchers and evaluates them against log events in real time, correlations included, as one self-contained binary.

What it is
Threat detection (SIEM)
Type
Open source
Made by
Tiger Data (formerly Timescale)
License
MIT
Facts checked
12 October 2026
Website Source code

What it is

Most Sigma tooling converts rules into some other system’s query language. RSigma runs them itself. It parses Sigma YAML into a strongly typed syntax tree, so a structural mistake is a parse error rather than a rule that silently never matches, then compiles each rule into an optimized matcher and checks events against it as they arrive. Correlation rules are evaluated in the same process: it keeps sliding, tumbling or session windows per group-by key, with matched events stored compressed and the state capped, and can persist that state to SQLite so it survives restarts.

Events come in as JSON, syslog (RFC 3164 and 5424), logfmt, CEF, Windows EVTX files, plain text or OTLP, with the format detected automatically by default. Any OpenTelemetry agent (Grafana Alloy, Vector, Fluent Bit, the OTel Collector) can send logs over OTLP by HTTP or gRPC, and the daemon also reads stdin, HTTP posts, NATS JetStream and Unix sockets. Before rules are compiled, pySigma-compatible processing pipelines rename fields, so a rule written for CommandLine matches process.command_line in ECS-shaped data. rsigma engine eval does one-shot runs for hunting or CI; rsigma engine daemon is the long-running service with hot reload, Prometheus metrics and outputs to files, NATS, OTLP or webhooks.

Around the engine sits detection-engineering tooling: a linter with 91 checks from the Sigma 2.1.0 specification (14 with safe auto-fixes), a language server for editors, an MCP server so AI agents can parse, lint, evaluate and convert rules, rule backtest for replaying event corpora against expected matches in CI, and a GitHub Action that wraps them. It can also convert rules into PostgreSQL/TimescaleDB SQL, LynxDB and Fibratus natively, handing other targets to sigma-cli. The project lives in Tiger Data’s timescale GitHub organization.

Why teams pick it

  • Fast for a single process: on an Apple M4 Pro the project measures 1.12 million events per second through the JSON pipeline with 100 rules, and 501,000 per second for temporal and event-count correlations
  • Covers the Sigma specification broadly: all 7 correlation types and all 26 pySigma pipeline transformation types since its first feature-complete release
  • Treats rules as code: linting, auto-fix, editor diagnostics, engine explain for why a rule did or didn’t match, and backtests that emit JSON or JUnit XML for CI
  • Plugs into existing log pipelines over OTLP, NATS JetStream or HTTP, and ships as prebuilt binaries and signed multi-arch Docker images

Watch out for

  • Not a SIEM: in its author’s words, it does not store logs, build search indices or provide a query interface; you keep a log store next to it
  • Young and moving fast: first released in February 2026, at version 0.24.0 by October 2026, and only the latest release gets security fixes
  • Several features are behind Cargo feature flags: a default cargo install reads only JSON, syslog and plain text; logfmt, CEF, EVTX, OTLP and the MCP server need the prebuilt binaries, the Docker image or extra features
  • Native conversion covers only PostgreSQL/TimescaleDB, LynxDB and Fibratus; other targets such as Splunk go through sigma-cli, which must be installed separately

Alternatives

What all threat detection (siem) have in common →
SigmaOpen sourceAn open YAML format for detection rules over log events, with a community repository of more than 3,000 rules and tools that convert them into each SIEM’s query language.

How it fits with other technologies

Evaluate rules once, run them as a daemon, or hunt in PostgreSQL · bash

cargo install --locked rsigma

# evaluate one event against a folder of Sigma rules
rsigma engine eval -r rules/ -e '{"CommandLine": "cmd /c whoami"}'

# stream NDJSON through the rules, mapping fields to ECS first
cat events.ndjson | rsigma engine eval -r rules/ -p ecs_windows

# long-running daemon: events over HTTP, hot reload, Prometheus metrics
rsigma engine daemon -r rules/ --input http --api-addr 127.0.0.1:9090

# lint rules, then convert them to SQL for a historical hunt
rsigma rule lint rules/ --fail-level warning
rsigma backend convert rules/ -t postgres

One parser, several ways to run#

Every command starts from the same parsed rule, shared through an intermediate representation in the rsigma-ir crate.

engine eval

one-shot

Reads inline JSON, an NDJSON or EVTX file, or stdin, prints one JSON result per match and exits; exit codes make it usable as a CI gate.

engine daemon

streaming

Keeps the compiled engine in memory, reads from stdin, HTTP, NATS, a Unix socket or OTLP, writes detections to one or more sinks, and reloads rules on file changes, SIGHUP or an API call.

backend convert, hunt run

historical

Turns rules into SQL for PostgreSQL/TimescaleDB (or LynxDB and Fibratus formats) and runs them read-only against an archive.

LSP and MCP servers

authoring

Give editors diagnostics, completions and quick fixes, and give AI agents typed tools such as parse_rule, lint_rules and evaluate_events that return JSON.

See it in a real stack

No architecture uses RSigma yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2026

Sigma rules were mostly used by converting them into another product’s query language. Commercial platforms evaluated rules in real time, but only inside their own systems and rule languages. Mostafa Moradian started RSigma in Tiger Data’s timescale GitHub organization in February 2026 to do both in the open: evaluate Sigma rules directly on a stream, correlations included, and convert them when the data already sits in a database.

Version 0.2.0, the first feature-complete release, shipped on February 17, 2026 with a parser, evaluation engine, a 65-rule linter, an LSP server, pySigma-compatible pipelines and a correlation engine. A daemon with hot reload and SQLite state followed nine days later. Moradian wrote a series of articles walking through it, and in March 2026 Zack Allen’s Detection Engineering Weekly called it “essentially a SIEM.” Moradian drew a narrower line: a streaming detection engine that plugs into the pipeline a team already has.

Later releases added an MCP server for AI agents (0.16.0, June 2026), backtesting, coverage reports, risk-based alerting and an alert pipeline modeled on Alertmanager. Building it surfaced gaps in Sigma itself, and Moradian sent proposals to SigmaHQ for array matching and a rule-level version field, while withdrawing a third, dynamic correlation windows, after a maintainer argued the windowing choice belongs to whoever converts a rule for a specific backend.

Why it’s built this way

Parse into a typed tree and compile before evaluating
Structural mistakes surface as parse or compile errors, such as a condition naming a detection that doesn’t exist, instead of a rule that silently never fires; compiled matchers keep per-event work small.
Correlation state in-process, compressed and capped
Keeping windows in the engine means no SIEM is needed to join events, and compressed, bounded storage keeps memory from growing with traffic.
A detection engine, not a collector or log store
Shippers such as Alloy, Vector and Fluent Bit already collect and route logs well, so RSigma supports a few receiver protocols and spends its complexity on detection.
Pipelines compatible with pySigma
Anything written for pySigma works in RSigma, and most pipelines from the SigmaHQ backends do too, so field mappings don’t have to be rewritten.

Timeline

  1. 2026

    First commits in February; 0.2.0, the first feature-complete release, on February 17

  2. 2026

    0.5.0 adds daemon mode with hot reload and SQLite state persistence on February 26

  3. 2026

    Detection Engineering Weekly #149 covers it in March

  4. 2026

    0.16.0 adds the MCP server on June 15

  5. 2026

    0.24.0 released on October 5

Sources13 · facts checked 12 October 2026

Improve this page on GitHub