A detection-as-code pipeline from repository to SIEM

Detection as code means a rule is a file, a change is a pull request, and a SIEM only ever receives what a pipeline has built from main. That is the whole idea. The rest is plumbing. This guide walks the plumbing in order and names the commands each platform documents, so you can see which stages arrive ready made and which you build.

A pipeline has five stages and each one can fail alone

The stages are validate, test, review, deploy and verify. Validate checks that the file parses and the fields exist. Test runs the rule against fixed events. Review is a human reading the diff. Deploy pushes the rule to the SIEM. Verify confirms the SIEM is actually running it.

Teams skip the last one. A deploy that returns success tells you the API accepted the rule. It does not tell you the rule ran. Rule health, covered in a separate guide, is the verify stage.

Validate before anything touches a SIEM

Validation is cheap and catches the dull failures: a bad YAML indent, a missing severity, a field name with a typo. Run it on every commit, not only on pull requests.

Elastic's detection-rules repository documents a CLI with validate-rule and validate-all, plus kibana import-rules and export-rules for moving rules between the repo and Kibana (detection-rules CLI reference, read 2026-11-03). Splunk's contentctl lists init, new, validate, build and test (contentctl user guide, read 2026-11-03). Panther's panther_analysis_tool documents test, validate, zip, upload and delete (Panther Analysis Tool docs, read 2026-11-03).

Sigma has a validator too. pySigma documents a validation step for rules, and sigma-cli converts from the command line, but the pages read describe no deploy step (pySigma docs, read 2026-11-03). Sigma is a format and a converter. You supply the rest of the pipeline.

Test in CI with fixed inputs

A validate job that passes tells you the file is well formed. A test job tells you the logic does what you meant. Keep the inputs in the repo next to the rule: one event that must alert, one near miss that must not.

Panther documents unit tests with test events and an expected alert outcome, and sets no minimum number of tests per rule (Panther testing docs, read 2026-11-03). Splunk's contentctl test runs detections against attack data in a real Splunk instance, which means your CI runner needs a Splunk instance (contentctl testing guide, read 2026-11-03). Microsoft Sentinel documents manual rerun of analytics rules and a results simulation, with no unit test step in the repositories docs (Sentinel rule integrity page, read 2026-11-03). If you run Sentinel, the unit test layer is yours to write.

Review the diff like code

Branch protection does the work here. Require one reviewer, require the validate and test jobs to pass, and block direct pushes to main. A rule change is a production change. It can page someone at 3 a.m. or go quiet for a month.

Put the review checklist in the pull request template: what does the rule detect, which log source feeds it, what is the expected volume, what is the test, what is the rollback. Five lines. Reviewers answer faster when the questions are already there.

Deploy with the mechanism the platform documents

Deploy is where platforms differ most.

Microsoft Sentinel connects a workspace to GitHub or Azure DevOps and deploys analytics rules, hunting queries, parsers and playbooks when the repository changes (Sentinel repositories docs, read 2026-11-03). The connection creates the workflow for you. The docs also state that Azure portal support ends after 2027-03-31 and Sentinel then runs only in the Defender portal, so check your connection setup against the Defender portal before that date.

Google Security Operations publishes a content_manager CLI in its community detection-rules repo, described as a tool to manage rules and other content through the REST API (chronicle detection-rules README, read 2026-11-03). The README describes a pipeline but no pull request trigger, so you add the trigger.

Panther documents GitHub Actions and CircleCI workflow files that test the repo and then upload through an API token (Panther GitHub Actions workflow, read 2026-11-03). Panther's docs treat the CI workflow as the normal way to ship rules, not an add-on.

Splunk is a special case. Sample workflows build and unit test on pull request, and loading content into a Splunk environment stays a manual step. The contentctl README also says future investment is shifting to Detection Studio and the repo no longer accepts new pull requests (read 2026-11-03). Treat contentctl as a tool you can use today and plan for a migration.

Verify after deploy, because success is not the same as running

After deploy, query the platform for the rule's state. In Sentinel that is the SentinelHealth table. In Elastic it is the Rule Monitoring tab. In Google Security Operations it is the Rule Observability dashboard. Add one post-deploy check to the pipeline: the rule exists, it is enabled, and its last run did not fail. If the check fails, the pipeline fails and the author hears about it in the pull request.

Know what the platform leaves manual

Read the docs for the gaps, not the headlines. Sentinel documents the repository connection but no staged dev to prod flow. Elastic's detection-as-code reference calls the CI pipeline optional and the pages read give no customer workflow file. Hunters says customers are not required to build detections themselves, so there is no repo to sync. Mate Security publishes no repo sync, pull request flow, CLI or API for its detections on the pages read (read 2026-11-04), and ranks eleventh of fourteen on the proposed scores. Anything a vendor says about its own pipeline without commands or fields is a vendor claim.

Checklist

• Every rule is a file in git, one rule per file, with an owner field.
• Validate runs on every commit and blocks the merge on failure.
• Each rule has at least one alerting test event and one near miss.
• Main is protected: one reviewer, passing checks, no direct pushes.
• Deploy runs from main only, using the CLI or connection your platform documents.
• Credentials for deploy are scoped tokens stored as pipeline secrets.
• A post-deploy check confirms the rule is enabled and its last run succeeded.
• The pipeline posts the result on the pull request.
• You wrote down which stage is manual and who owns it.