Detection-as-Code: Course Structure and How to Study

The six phases

The course moves through six phases. Each phase advances the pipeline one stage, from the source format through to the operating model. The phases are sequential by design: later phases depend on what earlier phases built.

Phase 1: The Source Format (Modules 1 and 2) teaches Sigma itself and the repository that holds it. You learn the logsource taxonomy, the modifier system, and the condition language, and you commit your first rules into a folder structure designed to enforce the rule-plus-fixtures contract. This phase is where you stop thinking in a target query language and start thinking in portable detection logic.

Phase 2: Version Control and Conversion (Modules 3 and 4) teaches Git for detection content and the conversion that turns one Sigma rule into many backend queries. Module 3 covers the branching model, the PR workflow, and CODEOWNERS, all shaped by how detection content reviews differently from application code. Module 4 covers the pySigma pipelines that map Sigma's abstract fields to your SIEM's real tables, the translation layer that makes "write once, deploy many" work in practice.

Phase 3: Testing and CI (Modules 5 and 6) is the heart of the course. Module 5 teaches fixture construction and the test harness: how to build a true-positive event that proves the rule fires and a benign event that proves it stays silent. Module 6 wires that harness into GitHub Actions so the test runs automatically on every PR and blocks a failing merge. After Phase 3 your pipeline enforces quality without depending on anyone remembering to run the test.

Phase 4: Deployment (Module 7) teaches automated deployment to a live SIEM, with parallel tracks for Sentinel and Splunk. You build the workflow that triggers on merge, packages the converted query in the format the SIEM expects, and pushes it through the API. Nobody logs into a console.

Phase 5: Coverage and Tuning (Modules 8 and 9) teaches the two measurement loops. Module 8 generates an ATT&CK coverage layer from the rule tags so you can answer "what do we cover" from the repository. Module 9 teaches the tuning feedback loop, suppressions as code, and where Sigma's expressiveness ceiling forces a detection into native query language managed through the same pipeline.

Phase 6: Programme and Capstone (Modules 10 and 11) closes the course. Module 10 teaches the operating model: rule-health metrics, the maturity gradient, and the RACI for detection content across teams. It covers the cross-team dynamics that determine whether a pipeline succeeds or stalls: who owns the detection backlog, who reviews PRs, who monitors rule health, and who decides when to retire a rule. Module 11 is the capstone: a new threat arrives, and you carry a detection through the entire lifecycle end to end, from Sigma rule through fixtures, PR, CI, deployment, and coverage update, in a single assessed exercise. The capstone is the proof that the pipeline works as a system, not as a collection of independent stages.

What each phase builds on

The phases are cumulative. Phase 1 gives you the source format and the repository. Phase 2 adds version control and conversion. Phase 3 adds testing and CI. Phase 4 adds deployment. Phase 5 adds coverage and tuning. Phase 6 ties it together as an operating model and tests the whole lifecycle.

You can see the dependency: you cannot test a rule (Phase 3) until you can convert it (Phase 2), because the test runs against the converted query, not the Sigma source. You cannot deploy it (Phase 4) until CI passes (Phase 3), because the deployment workflow is triggered by a merge, and the merge is blocked until CI passes. You cannot track coverage (Phase 5) until you have rules with ATT&CK tags in the repo (Phase 1), because the coverage-generation script reads the tags field. The phases build on each other because the pipeline builds on itself. This is not an arbitrary pedagogical choice; it reflects the real dependency structure of the system you are building.

The Northgate Engineering thread

The course uses Northgate Engineering as the worked narrative. NE's detection team has a backlog of console-managed rules, no CI, and no systematic coverage tracking. Over the course, you build the pipeline that replaces their console-managed workflow. The NE personas (the SOC analysts, the detection-engineering lead, the platform engineer) populate the PR reviews, the RACI, and the cross-team scenarios.

The NE narrative does several things at once. It gives every exercise a realistic context: you are not writing an abstract Sigma rule, you are writing a detection for a Kerberoasting technique that Northgate's SOC identified as a gap after a tabletop exercise. It populates the review scenarios: the detection-engineering lead reviews the PR and flags a scoping concern based on NE's legitimate service-account usage. It makes the operating-model discussions concrete: the RACI in Module 10 names NE's roles and shows who owns what in the detection lifecycle.

Your parallel build is the point. As NE's detection team moves from console management to a pipeline, you build the same pipeline in your own GitHub repository. The NE scenarios give the exercises context; your repository gives them reality. By the capstone, the NE narrative and your repository converge: the final exercise uses NE's scenario, but the pipeline it runs through is the one you built.

What each module produces

Every module leaves a concrete artifact in your repository. This is the build-alongside-the-course contract: if you finish a module and have not committed a file, you missed the exercise. The repository is not built all at once; it accumulates, phase by phase, until it is a working system.

Phase 1 commits rules. Phase 2 adds conversion pipelines. Phase 3 adds tests and CI. Phase 4 adds deployment. Phase 5 adds coverage. The directory tree is the visible record of your progress.

The accumulation is also a dependency chain. The CI workflow references the test harness. The test harness reads the conversion output. The conversion output comes from the Sigma rules. The coverage layer reads the Sigma tags. Nothing is standalone; everything connects, which is why building in order matters. A module's exercise assumes the artifacts from the previous modules already exist in your repository.

Pacing

The course is designed for 36 to 40 hours of study, which includes reading, building, and the capstone. There is no fixed schedule. The course is self-paced, and you can take as long as you need.

If you have 4 to 6 hours per week, plan on 7 to 9 weeks. That gives you roughly one module per week, with the longer modules (M5 testing, M6 CI, M11 capstone) taking two sessions. Phase boundaries are natural stopping points: finish Phase 3 (testing and CI) and you have a pipeline that lints, converts, tests, and blocks. That is a meaningful milestone even if you pause before Phase 4.

If you have a concentrated block, the course can be completed in 5 to 6 full days. Each phase is a natural stopping point: finish a phase, take a break, start the next. The first three phases take the most time because they build the core infrastructure; Phases 4 and 5 are faster because they extend an existing pipeline.

Build alongside the course. Every module asks you to commit a file to your repository. Do it at the time, not later. The pipeline is cumulative, and the capstone expects a working repository with rules, fixtures, CI, and conversion configs already in place. If you read the modules without building, the capstone will be a cold start. The commit is the learning; the reading is the preparation for the commit. Students who build as they go report that the later modules feel faster because the repository already contains the artifacts those modules reference. Students who read first and build later report spending significant time re-reading earlier modules to reconstruct the context they need.

Where to focus if time is limited. If you can only complete part of the course, prioritise Phases 1 through 3 (Modules 1 through 6). That gives you the Sigma source format, the repository structure, version control, conversion, testing, and CI. You will have a pipeline that lints, converts, tests, and blocks a bad rule from merging. Deployment, coverage, and the operating model are valuable, but the core discipline is in the first three phases. A team that has Phases 1 through 3 and no deployment automation is further ahead than a team that has manual deployment to a SIEM console with no testing or review. The first three phases establish the quality controls; the later phases extend the reach.

The reference and completion modules

After the 12 content modules, two reference modules close the course.

Module 99 (Operational Reference) consolidates the sigma-cli commands, pySigma pipeline snippets, Actions workflow templates, conversion configs, metadata schema, and naming standard into a single reference. This is the lookup module you return to when you need a quick command or config pattern after finishing the course. It is not teaching material; it is a condensed operating manual for the pipeline you built. The sigma-cli command reference, the YAML schema for rule metadata, the fixture file format, the CI workflow snippets, and the deployment configuration are all here in one place. When you are working on your own pipeline six months from now and need the exact syntax for a pipeline configuration flag, this is the module you open.

Module 101 (Course Exam and Completion) is the course exam: a three-phase simulation covering triage (read a detection PR and evaluate it), investigation (debug a pipeline failure), and response (ship a tested rule end to end). Pass is 70, distinction is 90. On completion you receive 40 CPE credits. The exam is designed so that a student who built alongside the course can complete it from their existing repository; a student who only read the material will need to build first.

The exam is designed to test the full lifecycle, not isolated knowledge. The triage phase gives you a detection PR and asks you to evaluate it: is the scoping condition tight enough, are the test fixtures representative, is the ATT&CK mapping correct, would you approve or request changes? The investigation phase gives you a CI failure log and asks you to diagnose it: is the failure a lint error, a conversion error, or a test failure, and what is the fix? The response phase gives you a new threat and asks you to carry a detection through the pipeline end to end: write the Sigma rule, construct the fixtures, open the PR, verify CI passes, and confirm the coverage layer updates. Each phase tests a different aspect of the discipline, and together they cover the full pipeline.

Where to start

If you have completed the setup in Section 0.4 and your tools are installed, you are ready. Module 1 begins with Sigma's structure: the logsource, the detection condition, the modifiers, and the metadata. By the end of Module 1, you will have written your first Sigma rule and committed it to your detection repository. The pipeline starts there.

The transition from "I understand the discipline" to "I am building the pipeline" happens in Module 1. Everything in Module 0 is orientation: what the discipline is, why console management fails, how Sigma works, what the pipeline looks like, what you will build, what you need, and how the course is structured. Module 1 is where you start writing files and committing them. The shift is from reading about the practice to doing it.