Detection-as-Code: The Pipeline From Rule to Production

This section walks the full lifecycle of a single detection rule, from the moment the analyst opens their editor to the moment the rule is firing in production and tracked on a coverage map. Every stage is a module in this course. By the end of this section you will know what the pipeline looks like end to end, and the rest of the course teaches you to build each stage yourself.

The lifecycle, end to end

A detection rule in a pipeline moves through seven stages. Each stage produces an artifact, and each artifact is a file the student commits.

Stage 1: Write the rule

The analyst authors the detection as a Sigma rule. The rule file defines the logsource (what log and what product), the detection condition (what fields to match and how), and the metadata (title, ATT&CK tags, severity, false-positive notes). The rule is a YAML file in the detection repository, not a query typed into a console.

This is where the vendor-neutral promise lives. The analyst writes category: process_creation, product: windows and a condition using Sigma field names and modifiers. They do not write KQL or SPL. The backend-specific query is produced by the converter in a later stage.

The mental shift matters as much as the format. In a console-managed workflow, the analyst thinks in the target query language from the start. The rule is the query. In a pipeline, the analyst thinks in detection logic: what event, what fields, what values, what modifiers. The query is a downstream output they never manually edit. This separation is what makes the pipeline portable. When the team adds a new backend or migrates to a different SIEM, the Sigma rules do not change. Only the conversion configuration changes. The analyst's work, the part that required domain expertise and judgment about what to detect, is preserved.

Module 1 teaches Sigma's full structure: the logsource taxonomy, the detection condition syntax, modifiers, and the metadata fields. Module 2 teaches where this file lives in the repository and the naming and folder conventions that keep the repo navigable at scale.

Stage 2: Commit with test fixtures

The rule alone is not enough. The analyst commits two more files alongside it: a true-positive fixture (a representative event that the rule must match) and a benign-baseline fixture (a representative event that the rule must not match). These three files, the rule and its two fixtures, form the minimum unit of detection content. The pipeline treats them as a package: if any piece is missing, the CI stage fails and the merge is blocked.

The true-positive fixture is a single event that contains the fields and values the detection is looking for. For the encoded-PowerShell rule from Section 0.3, the fixture would be a process-creation event where the image is powershell.exe and the command line contains -enc. The benign fixture would be a normal PowerShell execution without an encoded command.

These fixtures are not pulled from a live environment. They are authored artifacts: representative events constructed to contain exactly the fields the test needs. This is the same approach used in software testing, where unit tests run against known inputs, not against production data. The fixtures travel with the rule in the repository, so the test is repeatable by anyone.

Module 5 is the course's centre of gravity: it teaches fixture construction, the true-positive and benign-baseline assertions, and the test harness that runs them.

Stage 3: Open a pull request

The analyst creates a branch, commits the rule and its fixtures, and opens a pull request. The PR is the review surface. It shows the diff: the new Sigma rule, the test fixtures, and any changes to the conversion configuration. A designated reviewer reads the PR before it merges.

The review is not a rubber stamp. The reviewer checks the detection logic (is the scoping condition tight enough?), the test fixtures (do they represent realistic events?), the ATT&CK mapping (is the technique tag correct?), and the false-positive notes (are the documented exceptions realistic?). A rule that passes CI but has a bad scoping condition is caught in review. The PR diff makes this possible: the reviewer sees the rule, the fixtures, and the CI result in one view.

Module 3 teaches the branching model for detection content, the PR workflow, CODEOWNERS configuration, and why detection PRs review differently from application-code PRs.

Stage 4: CI runs automatically

When the PR is opened, a GitHub Actions workflow fires. The workflow runs four steps in sequence, and if any step fails, the PR is blocked from merging.

Lint validates that the Sigma YAML is well-formed, that the required fields are present, and that the logsource and metadata conform to the repository's schema. A rule missing an ATT&CK tag, a severity level, or a false-positive note fails the lint step. This catches the metadata gaps that would otherwise accumulate: rules without technique mappings cannot contribute to the coverage layer, and rules without false-positive documentation cannot be reviewed effectively.

Convert runs sigma-cli with each configured backend pipeline. The rule is converted to KQL, SPL, and Elastic query (or whichever backends the repository targets). A conversion failure, such as a field-mapping error where the Sigma field name does not exist in the backend's schema, stops the pipeline. The conversion step also catches logsource misconfigurations: if the logsource category does not exist in the pipeline's mapping, the converter cannot produce a valid query, and the error tells the analyst exactly which mapping is missing.

Test runs the fixture assertions. The converted query is evaluated against the true-positive fixture; the test asserts it matches. The same query is evaluated against the benign fixture; the test asserts it does not match. A rule that fires on benign activity or fails to fire on the true-positive event fails the test. The test step is what gives the CI pipeline its teeth: a rule can be valid YAML and convert cleanly but still be wrong, and the fixture test is what catches that class of error.

Block or pass. If any step fails, the PR is marked as failing and cannot be merged. The analyst fixes the issue, pushes a new commit, and CI runs again. The rule does not reach production until all four steps pass. The merge button is greyed out on a failing PR, which means the protection is enforced by the platform, not by team discipline.

Module 6 builds the actual GitHub Actions workflow YAML. The student writes every step, and the workflow runs on their own repository.

Stage 5: Merge and deploy

When the PR passes CI and the reviewer approves, the analyst merges to the main branch. A second workflow triggers on merge: it takes the converted query (already validated by CI), packages it in the format the target SIEM expects (an ARM template for Sentinel analytics rules, a savedsearches.conf stanza for Splunk), and pushes it to the SIEM through its API. The rule is live in production. Nobody logged into a console.

The deployment stage is where the pipeline delivers its most visible value. The gap between "the rule is merged in Git" and "the rule is running in the SIEM" used to be a manual step: someone logs in, pastes the query, configures the alert, and enables it. That manual step is a reliability gap, a delay, and a source of configuration errors (wrong alert severity, wrong entity mapping, wrong suppression window). The automated deployment eliminates all three.

If the rule misfires in production, the response is a revert: git revert the merge commit, push, and the deployment workflow removes or replaces the rule in the SIEM. The rollback is documented in the commit history, and the pipeline handles the mechanics.

Module 7 teaches deployment for Sentinel and Splunk as parallel tracks. The student follows the track for their platform. If they have neither, the pipeline is still complete; only the live-deployment step is deferred.

Stage 6: Coverage updates

Each Sigma rule carries its ATT&CK technique in the tags field. When a new rule merges, a script reads every rule in the repository, extracts the technique tags, and generates an ATT&CK Navigator coverage layer. The layer shows which techniques are detected and which are gaps. The coverage answer comes from the inventory, not a spreadsheet.

The coverage layer is a JSON file that the ATT&CK Navigator renders as a heatmap. Techniques with detections are coloured; techniques without are blank. The colour intensity can reflect the number of rules covering each technique, so you can see not only which techniques are detected but how deeply. A technique with five rules from different vantage points is more robustly covered than a technique with one rule that depends on a single log source.

Module 8 teaches coverage-as-code: generating the layer, integrating it with DeTT&CT, and running gap analysis from the repo.

Stage 7: Rule health

After deployment, the pipeline produces data: which rules fired, how often, what the false-positive rate is, when the rule was last updated. This data feeds a rule-health report that tracks detection age, firing rates, and FP ratios. A rule that has not fired in 90 days may mean the technique is no longer seen in your environment, or it may mean the detection is broken. A rule that fires 200 times a day is producing noise, not signal. A rule that has not been updated in 18 months may have drifted from the current threat landscape.

The rule-health report is the mechanism that closes the loop between "we have detections" and "our detections are working." Without it, the pipeline ships rules into production and the team assumes they are working. With it, the team knows which rules are healthy, which need attention, and which should be retired.

Module 10 teaches the operating model: rule-health metrics, the maturity gradient, and the cross-team flow that keeps the detection programme healthy after the pipeline is running. The rule-health data is what turns the pipeline from a delivery mechanism into a managed programme: it tells you not just that rules shipped, but whether they are still doing useful work months after they shipped. A pipeline without a health loop will quietly fill with detections that no longer fire on anything real, and nobody will notice until an audit or an incident exposes the gap.

The feedback loop

The pipeline is not linear. A rule that produces false positives in production feeds back into the same workflow: the analyst opens a tuning PR, adjusts the scoping condition or the suppression list, commits updated fixtures that include the false-positive case, and the change goes through CI and review before reaching production again. The tuning is version-controlled, tested, and reviewed the same way the original rule was.

Module 9 teaches the tuning feedback loop, suppressions and allowlists as code, and the Sigma expressiveness ceiling: the point where a detection escapes to native query language and is versioned through the same pipeline.

Section 0.5 details the specific deliverables you build in this course: the files, the workflows, and the repository structure you take with you.