Detection-as-Code: What the Discipline Is and Why the Console Fails

Those three questions are the gap detection-as-code closes. Not "how do I write a better rule" but "how do I operate detection content so it is versioned, tested, reviewed, and measurable."

The discipline, defined

Detection-as-code is the practice of managing detection content with the same engineering discipline that software teams apply to application code. The word "code" is doing real work in that definition: it means the detection rule is a file in a repository, not a configuration in a console. That single shift changes everything downstream.

A detection rule in a Git repository has a commit history. You can see every version, what changed, who changed it, and the message they wrote explaining why. A detection rule in a SIEM console has none of that. It has a "last modified" timestamp and, if you are lucky, the name of the person who saved it.

Where console management breaks

Console-managed detection breaks in predictable ways, and the failures are quiet: a rule stops firing and nobody notices for weeks. Each weakness is a gap in the system around the rule, and each gap is exactly what a pipeline stage replaces. The entire argument for this course fits in one picture: every console gap on the left is answered by a pipeline stage on the right.

The pipeline is not added complexity. Each stage exists because it closes a specific gap that makes console management fragile.

These gaps are concrete, not abstract. The credential-access rule from the scenario broke because someone raised its threshold during a tuning session, and with no history nobody could see the prior value or who changed it. The "no test" gap is just as common: a rule that matches CommandLine contains "-enc" fires when you run it in the console, so it looks tested, but it also fires on the legitimate configuration-management script that runs every morning, and you only find out when the SOC starts triaging the noise. The "no review" gap is where the worst rules ship: an analyst writes a PsExec lateral-movement rule that also matches the IT team's remote-admin tool, nobody checks the scoping, and the rule fires thirty times a day until the SOC learns to ignore it, which is exactly when real PsExec activity slips past.

Each of those failures is a missing pipeline stage. The history gap is the absence of version control. The test gap is the absence of fixture assertions. The review gap is the absence of a pull-request gate. The course builds each stage in turn, and the rest of this section explains what "as code" adds once those stages exist.

Version control is the foundation, but it is not the whole discipline. Detection-as-code also means the rule is tested before it ships. Not tested by running it once in the console and checking that an alert appeared, but tested automatically against committed fixtures: a true-positive event that proves the rule fires, and a benign-baseline event that proves it stays silent. Those fixtures live in the repository alongside the rule, so the test is repeatable by anyone, at any time, without access to a live environment.

It means the rule is peer-reviewed. A pull request shows the diff, the reviewer reads it, and the merge is a deliberate act. The reviewer sees the detection logic, the test fixtures, the ATT&CK mapping, and the false-positive notes before the rule reaches production. A console-managed rule reaches production the moment someone clicks Save.

It means the rule is deployed through a pipeline. When the PR merges, the CI workflow converts the Sigma rule to the target backend (KQL, SPL, Elastic), runs the tests, and pushes the converted rule to the SIEM without a human logging into a console. Deployment is a pipeline stage, not a manual step.

The software-engineering analogy, taken seriously

Detection-as-code borrows from software engineering, but the analogy is worth examining closely because detection content is not application code. A web application serves users. A detection rule watches for adversary behaviour. The failure modes are different: a broken application returns an error page; a broken detection stays silent, and nobody knows until an incident is missed.

This is why the engineering practices transfer. Version control answers "what did this look like before." Automated testing answers "does it still fire after the tweak." Peer review answers "did anyone check the scoping." Each practice exists to close a silent-failure mode, which is exactly the failure mode detection content suffers from. The practices are not borrowed because they sound professional; they are borrowed because a silent detection failure is the most expensive kind, and these are the practices that surface it before an incident does.

The analogy breaks in some places, and the course is honest about that. Application code has unit tests, integration tests, and end-to-end tests in a well-defined hierarchy. Detection testing is simpler in structure (does the rule fire on this event, and does it stay silent on that event?) but harder in judgment (is the true-positive fixture realistic enough to prove anything?). Application code review checks for bugs and style; detection review checks for false-positive risk, ATT&CK mapping accuracy, and whether the scoping condition will survive a busy production environment. The practices transfer; the implementation details differ.

What changes when you treat detections as code

The shift is not abstract. It produces five concrete, measurable differences in how a detection team operates: each one moves a capability from "depends on someone remembering" to "produced by the workflow."

The pipeline does not ask the team to be more disciplined. It produces these five capabilities as byproducts of the workflow itself.

Accountability becomes automatic. Every rule change is a commit with an author, a timestamp, and a message. When a rule misfires at 03:00 and the on-call analyst asks "what changed," the answer is a git log command, not a Slack thread asking if anyone remembers editing the rule. The diff tells you what changed, the message tells you why, and the PR thread tells you who reviewed it.

Testing becomes repeatable. A rule is not "tested" because someone ran it once in the console last quarter. It is tested because CI ran it against its fixtures ten minutes ago, and the test passed. Because the fixtures are committed alongside the rule, anyone on the team can run the test at any time, on any machine, without access to the SIEM or a live data source.

Review becomes structural. A PR is not a rubber stamp. The reviewer reads the detection logic, the test fixtures, the ATT&CK mapping, and the false-positive analysis. A bad rule is caught in review, not in production. The PR comments are also a permanent record of the reviewer's reasoning, valuable when someone revisits the rule six months later and needs to understand a scoping decision.

Coverage becomes measurable. Each Sigma rule carries its ATT&CK technique mapping in the metadata. A script reads the repo, generates a coverage layer, and produces a heatmap showing which techniques are detected and which are gaps. When leadership asks "are we covered for credential access," you load the layer and show them, with the rule names behind each technique. That answer is as current as the last merge to main.

Onboarding becomes faster. A new team member reads the repository and sees every detection the team operates: the rule, the fixtures, the conversion output, the PR history. They do not need tribal knowledge from the person who wrote the rule. The repository is the documentation, and the commit history is the institutional memory.

The maturity gradient

Detection-as-code is not all-or-nothing. Teams adopt it in stages, and each stage delivers value even without the later ones. The course teaches the full pipeline, but the gradient shows where the value compounds: every stage adds a capability the previous stage could not provide, and the enforcement boundary at Stage 3 is the point where the discipline stops depending on individual diligence.

Stages 1 and 2 improve on console management but still rely on the analyst remembering to run the test. Stage 3 is where the machine enforces the rule. This course builds through Stage 5; a team at Stage 2 is already ahead of a team at Stage 0.

A team at Stage 1 has version history and rollback, which many teams call detection-as-code, but a broken rule still reaches production. A team at Stage 2 has committed fixtures and a repeatable test, but whether a broken rule is caught depends on whether the analyst ran the test before merging. Stage 3 removes that dependency: the test runs automatically on every pull request, and a failing test blocks the merge. Stages 4 and 5 extend the reach to deployment and measurement. The course builds all five, but the gradient lets you adopt at the pace your organization allows.

What detection-as-code is not

It is not a Sigma tutorial. Sigma is the source format this course uses because it is the strongest vendor-neutral option, but the discipline applies to any detection format: a native KQL rule, a Splunk correlation search, an Elastic detection rule. If you version it, test it, review it, and deploy it through a pipeline, it is detection-as-code regardless of the format. A team that writes every rule in native KQL and runs it through a tested, CI-gated pipeline is practising detection-as-code. A team that writes every rule in Sigma and pastes the converted output into the console by hand is not.

It is not a Git tutorial. Git is the substrate, and you will learn enough to operate a detection repository confidently, but the course teaches Git as the mechanism for detection version control, not as a general-purpose skill. The branching model, the review workflow, and the commit conventions are all shaped by the needs of detection content. You will not learn advanced Git techniques like rebasing, cherry-picking, or submodule management because detection repositories do not need them.

It is not a replacement for writing good detections. A well-engineered pipeline that ships a bad rule ships a bad rule faster. Detection quality is the precondition; detection-as-code is the operating discipline. SEC401 (Detection Engineering) teaches detection quality: how to identify the telemetry, write the condition, scope it to avoid false positives, and map it to ATT&CK. This course teaches the engineering practice around that work: how to version the rule, test it, review it, gate it on CI, deploy it, and measure it. The two are complementary, and neither is a prerequisite for the other.

The distinction matters in practice because the two disciplines fail in different ways and a strong pipeline can mask a weak detection. A detection engineer who writes a precise Kerberoasting rule but manages it in a console has good content with no operating discipline: the rule works until someone edits it, and then nobody can tell what changed. A team with a mature pipeline but shallow detection logic has the opposite problem: they ship, test, and measure rules that do not actually catch the techniques they claim to cover, and the coverage map shows green for a technique the rule misses in practice. The pipeline tells you the rule is deployed and firing; it does not tell you the rule is correct. That judgment is the detection-engineering skill SEC401 teaches, and this course assumes you either have it or are building it in parallel. The pipeline amplifies whatever quality you put into it, in both directions.

It is not a vendor product. Detection-as-code is a discipline, not a SaaS platform. There are commercial tools that automate parts of the pipeline (CI-integrated SIEM management, detection-content repositories, coverage-tracking dashboards), and some of them are good. But the discipline itself is vendor-neutral: Git, GitHub Actions, Sigma, and pySigma are all open-source, and the pipeline you build in this course runs without commercial dependencies. If you later adopt a commercial tool, the discipline transfers; you are automating stages you understand, not outsourcing stages you do not.

Section 0.2 introduces Sigma, the vendor-neutral format you write detections in, and shows a single rule converting to two different SIEM query languages and passing through a CI check. It is the first place you see the pipeline actually working rather than described.