[ SOC.8 — SIGMA LINTER ]

Will this Sigma rule load?

Paste a Sigma detection rule and get the specification problems back before your pipeline finds them — missing required fields, values outside the permitted sets, a misspelled modifier, or a condition naming a selection that was never defined. Structure only: it checks the rule against the Sigma specification, not whether the detection is any good.

Corrections welcome — see our editorial policy.

Checked against the Sigma specification v2.1.0. Multi-document files (--- separated) are read document by document.
// Everything runs locally in your browser — the rule you paste is never sent, only an anonymous usage count.

What it checks

Every check below comes from the Sigma specification itself, which is public domain. Errors are specification violations; warnings are shapes that load but usually indicate a mistake.

  • Required fields — title, logsource and detection must be present, and detection must carry a condition.
  • Permitted values — status must be one of stable, test, experimental, deprecated, unsupported; level one of informational, low, medium, high, critical.
  • Formats — id must be a version-4 UUID, and date/modified must be ISO 8601 YYYY-MM-DD. Rules written before Sigma 2.0 often use YYYY/MM/DD, which the current specification does not accept.
  • Value modifiers — anything after a | in a field name is checked against the specification’s modifier list, so |containz or |startwith is caught rather than silently matching nothing.
  • Condition wiring — a condition that names a selection which does not exist is an error; a selection the condition never uses is a warning.
  • Unknown top-level keys — flagged as a warning, since a rule with severity: instead of level: loads fine and does nothing you expected.

What it deliberately does not do

Knowing the edges of a tool matters more than the tool. This one is narrow on purpose.

  • It does not convert rules to a SIEM backend. pySigma and sigma-cli do that, and they do it properly.
  • It does not judge the detection. Whether your selection actually catches the technique, or drowns you in false positives, is not a question about syntax.
  • It does not validate field names against any product’s log schema. ImagePath is spelled correctly as far as the specification is concerned, whatever your backend calls that field.
  • It does not parse every YAML construct — see below, because this is the part most likely to surprise you.

When it says it cannot read your rule

This linter reads the narrow slice of YAML that Sigma rules actually use: block mappings, indented sub-maps, - lists, quoted and plain scalars, block scalars, and --- document breaks. Anchors and aliases, flow mappings, complex keys and tab indentation are outside that slice.

When it meets one of those, it stops and tells you which construct and which line — it does not carry on and guess. A linter that hands back a confident, wrong verdict is worse than one that admits the limit, because you would act on it. If you hit this, run the rule through a full YAML parser or sigma-cli; the rule may be perfectly valid.

Sources

Checks are transcribed from the Sigma specification (v2.1.0), which its authors place in the public domain. No Sigma rules from the SigmaHQ repository are used or shipped here — the example on this page is our own, and the rule you check is yours. See our data sources.