Why Sigma exists: one rule format, many SIEMs

Before Sigma, a detection rule written for one SIEM or log platform was effectively locked to that platform's query language — Splunk SPL, an Elastic query, a QRadar rule — with no straightforward way to share it with someone running different tooling. Sigma defines a vendor-neutral YAML format for describing a detection: what log source it applies to, what field/value patterns indicate the thing being detected, and a condition expression combining those patterns. A Sigma rule is then converted to whatever backend query language a specific SIEM needs by a separate converter tool, which is what makes Sigma rules genuinely shareable across the security community regardless of what platform each person actually runs.

Why cross-referencing the condition matters more than checking fields exist

A Sigma rule can have all its required top-level fields present — title, logsource, detection — and still be broken if the `condition` field references a selection name that was never actually defined under `detection`, like a condition of `selection1 and selection2` when only `selection1` exists in the rule. That's a real, common authoring mistake (usually from renaming or removing a selection block without updating the condition to match), and it produces a rule that will fail or behave unexpectedly when actually converted and run against a SIEM — which is exactly why this tool goes beyond checking for required fields and specifically cross-references every identifier in the condition against the selections actually defined, flagging any that don't match up.