Detection-as-Code: What the Discipline Is and Why It Matters

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.

The difference is not the rule itself. The same detection logic can live in either column. The difference is the system around the rule: the history, the test, the review, and the measurement.

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.

Every practice the discipline borrows maps to a specific failure mode it prevents. The mapping is not decorative; it is the reason each practice is worth the overhead.

The practices are not borrowed because they sound professional. Each one closes a failure mode that detection teams hit in production.

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 looks at the specific failure modes of console-managed detection, so you can see exactly what the pipeline replaces. Each failure mode is concrete, and each one maps directly to a stage of the pipeline this course builds, which is the clearest way to understand why the discipline is structured the way it is.