Sigma Rule Validator

Validate a Sigma detection rule's structure, log source and detection logic locally, with the errors pointing at the line that caused them.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Drop Sigma rules (.yml)

One or many files, or a multi-document file. Checked in your browser.

Or paste a rule

More than a YAML check

A Sigma rule can be perfectly valid YAML and still be useless. A condition might name a selection that does not exist, a modifier might be misspelled, a numeric comparison might be made against a string, or all might be applied to a single value, which the specification forbids because some backends cannot express it. This validator checks rules against the official Sigma 2.0 JSON schema, then against everything the schema cannot express:

the condition grammar, including 1 of selection_*, all of them, not and brackets;
that every identifier the condition uses is defined, and every one defined is used;
every modifier name, and whether its value has the right type;
consistent field spellings;
ATT&CK tags, checked against a real release of ATT&CK.

ATT&CK tags that stay current

Tags such as attack.t1059.001 are checked against the ATT&CK Enterprise release bundled with this page. Unknown techniques are flagged. A revoked technique is shown with its replacement. attack.defense_evasion gets an explanation rather than an error: ATT&CK 19 split Defense Evasion into Stealth and Defense Impairment, so rules written before then need retagging, not rewriting.

Regular expressions are PCRE, not JavaScript

Sigma's re modifier uses a PCRE subset. Expressions are compiled here to catch real syntax errors, but PCRE-only constructs (inline flags such as (?i), \A, atomic groups) are reported as warnings to check in your backend, not errors. Metacharacters outside the Sigma subset, such as \d or lookarounds, are flagged too, because some backends reject them.

Formatting that does not change meaning

The formatter rewrites a rule in the conventional key order with consistent indentation. It then parses its own output and compares it with the original, field by field. The formatted rule is only offered when the two are identical. Comments are not kept, and the page says so.

Tested on real rules

Our test suite validates 80 rules drawn from across the SigmaHQ repository, plus the specification's own schema tests. Every one passes with no errors and formats back to identical data. Each kind of defect above is covered by a deliberately broken rule.

Frequently asked questions

Does it support Sigma 1.x aggregations such as count() by?

No. Sigma 2.0 removed them in favour of correlation rules. A condition containing '|' is reported with that explanation.

Can it convert the rule to my SIEM's query language?

Use the Sigma Rule Converter. It runs the official pySigma library in your browser and validates the rule here first.

Why is YAML with anchors refused?

Anchors and aliases enable entity-expansion attacks, and no Sigma rule needs them. The reader refuses them, along with tags and merge keys.

Is my rule uploaded?

No. Unpublished detections reveal what you can and cannot see; they are validated in your browser.

References

Sigma specification 2.0 (public domain)
MITRE ATT&CK

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.