Detection-as-Code Managing Detections Like Software

Somewhere in your environment there’s probably a detection rule that was edited directly in the SIEM console by someone who left the company two years ago. Nobody knows why the threshold is set to 7. Nobody wants to touch it. That’s not detection engineering that’s detection archaeology, and it’s a symptom of never having treated rules like code in the first place.

Detection-as-code isn’t a buzzword dressed up to sound modern. It’s the straightforward idea that a detection rule is a software artifact with a lifecycle, and it deserves the same rigor you’d apply to a production application: version control, peer review, automated testing, and a deployment pipeline.

Why Console Edits Are the Enemy

Editing detections directly in a SIEM UI feels fast. It is fast right up until three analysts have each made slightly different tweaks to the same rule over six months and nobody can explain the current logic without archaeology. There’s no diff. There’s no blame. There’s no rollback beyond hoping someone remembers what it used to say.

Compare that to a rule living in a Git repo as YAML or Sigma. Every change is a commit with a message, an author, and a timestamp. Want to know why the exclusion for svchost.exe spawning powershell.exe got added? Check the commit it’ll usually reference the false-positive ticket that caused it. That traceability alone justifies the migration for most teams, before you even get to testing.

Testing Detections Before They Meet Production Traffic

Here’s a concrete example. Say you’re writing a detection for suspicious scheduled task creation used for persistence. In a code-managed workflow, you don’t just write the query and ship it you write test cases first. A positive case: a scheduled task created via schtasks with a suspicious binary path pointing to a temp directory. A negative case: the same command structure but from a known software updater that legitimately creates tasks during patching.

You run both through the rule logic in CI before merge. If the negative case fires, the pull request fails automatically and nobody’s paged at 2 a.m. because of it. This is the part that most teams skip, and it’s the part that actually prevents alert fatigue not better dashboards, not more tuning meetings, just tests that run before code merges.

Tools like Sigma with its unit-testing frameworks, or custom pytest harnesses against sample log data, make this achievable without needing a dedicated platform engineering team. You don’t need Kubernetes. You need a repo, a CI runner, and discipline.

Branching Strategy for Detection Content

A lot of teams over-engineer this part and end up with a branching model more complex than their actual application codebase needs. Keep it simple: a main branch that mirrors production, feature branches per detection or per hunt-derived rule set, and a staging branch that maps to your alert-only tier in the SIEM.

Pull requests get reviewed by someone other than the author this catches logic errors and, just as often, catches detections that duplicate existing coverage nobody remembered writing. I’d argue the second-order benefit of code review surfacing tribal knowledge before it becomes an incident matters as much as catching bugs.

CI/CD Isn’t Optional Once You Have More Than a Handful of Rules

Below maybe 20 detections, you can get away with manual deployment. Above that, manual deployment is how drift happens staging says one thing, production says another, and nobody notices until an incident review asks “wait, was this detection even live?”

A basic pipeline: commit triggers automated syntax validation, then unit tests against sample data, then a deploy step that pushes to staging automatically and requires manual approval to promote to production. This isn’t exotic GitHub Actions or GitLab CI can drive most SIEM APIs without much custom tooling. The upfront investment is a few days. The payoff is not debugging “which version of this rule is actually live” during an active investigation, which is a genuinely bad time to be doing archaeology.

Version control also solves a problem nobody plans for: audits. When a compliance reviewer asks “show me every change to your privileged access detections in the last year,” a Git log answers that in thirty seconds. A pile of undocumented console edits does not.