Detection as code means managing detection rules the way you manage software: in version control, reviewed by a second person, tested automatically and rolled out in stages. For Sigma rules, which are YAML files, this is straightforward and cuts the number of broken or forgotten rules.
Why bother
Rules edited in a web console leave no history. Nobody knows who changed a threshold, why, or whether it still works. A rule that silently stops matching because a log field was renamed looks the same as a quiet week. Putting rules in a repository gives you history, review and tests.
The repository
Keep one folder per log source or technique. Each rule file carries a title and a description of what it catches and why. Keep a test file next to it.
Sigma suits this well. The project describes a generic open format, with Sigma CLI as the official converter and pySigma as a library for building conversion into your own tools.
The pipeline, in order
- Pull request. Every change comes through one, with a second reviewer.
- Lint. Check the YAML is valid and required fields are present.
- Convert. Run the converter for your log platform. If conversion fails, the build fails.
- Test with sample events. Feed known matching events and known benign ones. The rule must match the first and not the second.
- Replay. Run against a sample of recent real logs. Record how many hits. A big jump needs an explanation.
- Stage. Deploy first in a mode that alerts to a test queue only.
- Promote. After a trial period with acceptable noise, switch to the live queue.
- Review later. Each rule gets a review date.
What a test looks like
For a rule about a suspicious parent and child process pair, the test set has one event that should match, one with the same child under a normal parent, and one with an unrelated event. Plain text files are enough.
Metrics that help
Track per rule: alerts per week, share closed as false positive, time to close, last test date and owner. Retire rules that never fire and also have no test, because you cannot tell whether they work.
Pitfalls
- Field mapping drift when a log source changes format.
- Tests that only check the rule matches, not that it avoids benign events.
- Copying community rules without adapting them to your environment.
- No owner. Every rule needs a name next to it.
Starting small
Do not migrate everything. Put ten rules in a repository, add tests to three, and run the staged rollout once. Learn from that.
Quick check
Do I need special tooling?
No. A Git repository, a CI job and the converter are enough to begin.
How do I test a rule for a rare attack?
Create synthetic events that match the described behavior and keep them with the rule. For live testing, use a lab system you control, never production.
Sources
Last reviewed: 19 October 2026.
