Security Operations
6 Detection-as-Code Tools for Versioned Security Rules in 2026
Write the rule as a file, test it on a fixture you own, then ship it to the console. A detection nobody can diff is a detection the next shift cannot hand off.
Expertise: Security Operations · Level: Intermediate · 6 min read
A detection nobody can diff is a detection the next shift cannot hand off. The rule in the SIEM GUI the team already has is 1 silent edit away from a miss, and it is green until the author is on leave.
The rule needs to be a file, with a test you can run on data you own. Write the rule. Commit it. Run it against a fixture. Then ship it to the console that actually searches. Skip the fixture and you versioned a guess.
Portable YAML, Python next to a lake, and vendor rule repos are different handoffs. osquery asking the host a SQL question is not a SIEM rule.
Pick the handoff your next shift can run without the original author. That is the bar, not a new correlation language.
How we evaluated
We read first-party docs, source, licenses, and release notes, and we treat a marketing page as a claim, not as proof that two products do the same work.
We cared about whether the rule is a file you can grep, whether tests exist, whether you operate the runner, and whether the docs name a sample you can run on data you own. A console-only editor missed.
We read first-party docs, licenses, and release notes. Unless a write-up says otherwise, we did not run a paid tenant.
| Tool | Best for | What to check |
|---|---|---|
| Sigma | Portable detections you can convert | YAML you convert · LGPL-2.1 on the language · you keep the files |
| osquery | SQL on the host you own | SQL on the host · Apache-2.0 or GPL-2.0 · you deploy the agent |
| Elastic detection-rules | Versioned Elastic SIEM content | TOML in git · Elastic License 2.0 · Elastic fields |
| Splunk ESCU | Splunk security content you can pull | Analytic stories · Splunk content terms · SPL you read |
| Falco rules | Runtime rules on syscalls you allow | YAML conditions · Apache-2.0 · runtime, not history |
| Wazuh rules | Decoders and rules on a SIEM you host | XML rules and decoders · GPL-2.0 · tied to the Wazuh agent |
Sigma
Best for portable detections you can convert
Sigma is a YAML detection that converters turn into Splunk, Elasticsearch, or a SIEM you already have. The repo is the catalog.
If the SIEM changes, the YAML can still move. That is the point of the format. A converter is not a guarantee, because fields differ on your indices.
Key features
- YAML rule format
- Converters for major SIEMs
- Huge public rule set
- You keep the files in git
Why we like it
A rule that can leave the console is the practical portable job. You review the file, not a screenshot.
Limits
Converters miss fields. You still run the query on your indices. Rule licenses in the catalog vary.
osquery
Best for SQL on the host you own
osquery exposes the host as tables. Detections are SQL. Fleet and others schedule the queries. The project is open.
When the question is whether a binary is still running, a SIEM query on a log you never sent will miss it. This entry is the host ask. The EDR list rows the same agent as a box you deploy.
Key features
- SQL tables for processes, sockets, users
- Scheduled queries
- Extensions
- Works with Fleet and others
Why we like it
Asking the box beats hoping the log arrived. The query is a file you can review.
Limits
You must deploy an agent. SQL that scans everything is a load problem. This is not a network IDS.
Elastic detection-rules
Best for versioned Elastic SIEM content
Elastic publishes detection-rules as a repo. Rules are TOML and have a Python harness. That is detection as code for the Elastic SIEM.
A vendor content pack that is actually a git repo is rarer than the brochure. You can fork it. The rules assume Elastic fields, so they do not port to Splunk without work.
Key features
- TOML rules in git
- Python test harness
- Mapped to Elastic SIEM
- Version history you can read
Why we like it
Versioned content you can fail in CI is the practical platform row when the SIEM is already Elastic.
Limits
ELv2 is not Apache. The rules stay on Elastic. You still map your indices.
Splunk ESCU
Best for splunk security content you can pull
Splunk ESCU is the security content update. Research.splunk.com lists analytic stories. The bits live as SPL you can review.
If the SIEM is Splunk, this is the content option. Treat it as code you review, not as a score, because SPL stays in Splunk and still needs the data model.
Key features
- Analytic stories
- SPL you can read
- Mapped to data models
- Versioned content
Why we like it
A story you can pull is better than a rule that only exists in a demo. You still own the data model.
Limits
SPL does not leave Splunk. Empty indexes make empty stories.
Falco rules
Best for runtime rules on syscalls you allow
Falco rules watch syscalls and Kubernetes audit. The rules repo is a YAML condition language. The Kubernetes list owns the engine.
Runtime is the hole SIEM YAML never sees. Detection as code is the committed rule file. Kubernetes security is the DaemonSet. Noise is a tuning job you will own.
Key features
- YAML conditions
- Syscall and K8s audit sources
- Allow and exception lists
- Open rules repo
Why we like it
A syscall rule you can grep is the detection-as-code for a cluster that changed after admit.
Limits
It is not a historical SIEM. This page does not replay a container escape. You still write exceptions.
Wazuh rules
Best for decoders and rules on a SIEM you host
Wazuh ships decoders and rules as files. You can grep them. The SIEM alternatives list already covers the platform. This row is the rule tree.
If you already operate Wazuh, this is the detection-as-code you have today. Do not pretend the XML is Sigma, because it will not port.
Key features
- XML rules and decoders
- You can add a local rule file
- Tied to the Wazuh agent
- GPL-2.0
Why we like it
Owning the rule file on the SIEM you already host beats inventing a parallel YAML nobody converts.
Limits
XML is not portable to Splunk. You own false positives. The console job is on the SIEM alternatives list.
What we left out
- Panther. Teams want detections in git next to a lake they already like. It is a SIEM product, and Panther is the detection format, not a second SIEM bake-off.
- YARA. People already write file signatures in repos. It matches files, not SIEM indices, so it failed the query-you-store check.
Sigma import threads treat the YAML as a start, not a finished detection. A converter is not a tested query.
Questions before you buy
Ask these before the quote. A product that cannot answer them is selling a different control.
- Can I grep this detection without a vendor login?
- If we change SIEM next year, does the rule move, or do we rewrite it?
- Is this a historical query, a host SQL, or a runtime hook, and which engine already runs?
Put the rule in git if the GUI is the complaint. Use Panther if the lake is already Snowflake. Use osquery when the host is the question.
FAQs
Is detection as code a product I buy?
No. It is a habit. The rows are formats and repos. A lake vendor that keeps rules in a GUI only is the wrong door.
Does Sigma replace my SIEM?
No. Sigma writes the idea of the query. A converter still needs indices and fields.
Why is Falco here and on Kubernetes?
The engine lives with the cluster. The rule files are detection as code. Detection as code is the committed YAML. Kubernetes security is the platform.
Is this a scored bake-off?
No. Order is editorial. We did not replay attacks.
