Wide uses the full column for everything, text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
▾
Detection-as-Code (SEC407): Course Orientation
Module 0
DETECTION-AS-CODE · SEC407 · MODULE 00
Ship detections through a pipeline, not a console.
A detection written in a SIEM console has no history, no test, no review, and no rollback. When it breaks in production, nobody can tell you who changed it or why. This course teaches you to manage detection content the way a software team manages code: every rule version-controlled, peer-reviewed, automatically tested, and deployed through a pipeline you build in your own GitHub account. You write each rule once in Sigma and ship it to Sentinel, Splunk, or Elastic without clicking through a console.
12 modules
across 6 phases
Your pipeline
you build it, you keep it
Vendor-neutral
Sigma to KQL, SPL, Elastic
40 CPE
credits on completion
Why this course exists
Most detection teams write rules directly in the SIEM console. The rule works when they test it by hand, so they save it and move on. Six months later, a tuning change breaks it. Nobody notices because nobody tested it after the change. When someone finally asks why the detection stopped firing, the team discovers there is no history of what the rule looked like before, no record of who changed it, and no way to roll back. The original author has moved on. The rule is rebuilt from scratch.
This failure is not a tooling gap. Sigma exists. Git exists. CI exists. The gap is the discipline that connects them: the practice of treating detection content as engineered software rather than disposable configuration. Writing the rule in a vendor-neutral format. Committing it with test fixtures that prove it works. Reviewing it before it ships. Blocking it from production when the tests fail. Deploying it through a pipeline that never requires a console login. Measuring it after deployment so you know when it stops working.
That discipline is detection-as-code. This course teaches every stage of it, on the real toolchain, and you finish with a working pipeline in your own GitHub that you take with you.
What you will build and keep
This is a build course. You do not read about a pipeline; you build one. Every module produces a file you commit, and by the end the repository is a working system you take with you.
A structured detection repository
A Git repo with the rule/test/documentation contract enforced by folder layout. Every rule file travels with its test fixtures and its metadata.
A Sigma rule set
Detections written in the vendor-neutral format, covering a representative spread of ATT&CK techniques, each with committed true-positive fixtures.
A fixture-based test harness
Tests that assert each rule fires on its true-positive events and stays silent on benign baseline. A broken rule is caught before your SOC is.
A CI workflow
GitHub Actions: lint, convert, test, block. A PR with a non-passing rule does not merge. The workflow YAML is a file you write and own.
Automated SIEM deployment
A merged rule pushes to Sentinel or Splunk without console interaction. Rollback when a rule misfires. The deployment stage is the last pipeline step.
Coverage and rule-health reporting
An ATT&CK coverage layer generated from your repo, and a rule-health report produced from pipeline data. Your coverage answer comes from the inventory, not a spreadsheet.
The toolchain
The course uses the real, current detection-as-code toolchain. Nothing is simulated. You install these tools at the start and use them throughout.
Sigma + sigma-cli + pySigma
The vendor-neutral detection format, the CLI converter, and the Python library that powers backend-specific conversion pipelines.
Git + GitHub
Version control, branching, pull requests, code review. Git is the substrate; GitHub hosts your detection repository and runs your CI.
GitHub Actions
The CI/CD platform. Your workflow YAML lints, converts, tests, and blocks a non-passing rule. Free tier is sufficient for the whole course.
Atomic Red Team
Pre-captured test events committed as fixtures. You do not need a Windows test host to complete the course; the fixtures travel with the rule in the repo.
You need a GitHub account and Python 3.11 or later. For the deployment module (M7), a Sentinel workspace or a Splunk instance is optional; the module offers parallel tracks, and if you have neither the pipeline still works end to end with the deployment step deferred.
How the course is built
Twelve modules move through six phases. Each phase advances the pipeline one stage, from the source format through to the operating model that keeps it healthy.
What you need and who this is for
You are a detection engineer, SOC analyst, or security automation engineer who can already write a detection but manages rules by hand in a SIEM console. You want the engineering discipline around your detection content. Detection-engineering team leads building a sustainable programme belong here, as do platform engineers asked to stand up a detection pipeline.
The course is self-contained. Sigma structure, Git branching, CI configuration, and backend conversion are taught at first use. An experienced reader skips past what they already know. You need comfort reading a SIEM query (KQL or SPL), basic command-line use, and willingness to learn Git. No prior Git, Sigma, or CI/CD experience is required.
Vendor-neutral by design
You write each detection once in Sigma and convert to whichever backend your organization runs. The pipeline discipline is the same regardless of SIEM.
You keep what you build
Your detection repository, test harness, CI workflow, and deployment pipeline live in your own GitHub account. Demonstrate it in an interview or deploy it at your next organization.
How to get the most
Build the pipeline alongside the course. Every module asks you to commit a file. Do it. The repository is only useful if you built it; reading about one teaches the concepts, building one teaches the discipline.
Do I already know this material?
Six quick scenarios across the full range of this course, from Sigma fundamentals to pipeline operations. Answer them to find out where you sit and whether this course will build new skills or sharpen knowledge you already have.
Your team writes every detection directly in the SIEM console. When a rule starts producing false positives, you edit it in place. A month later someone asks what the rule looked like before the change. How do you find out?
Check the SIEM's built-in version history, which tracks every edit automatically.
Ask the original author to rewrite the rule from memory.
You cannot. Console-managed rules have no version history by default. A rule managed in a Git repository would have every prior version in the commit log, with a diff showing exactly what changed and a message explaining why.
Most SIEMs do not track a change history for detection rules. Version control is the foundation of detection-as-code: every change is a commit, every commit has a diff, and every diff has a reviewer. The course starts here because without version history, every other engineering practice breaks down.
Export the SIEM's audit log, which records detection rule diffs.
You want to write a detection once and deploy it to both Sentinel and Splunk. What format do you write it in?
KQL, since it is the most widely supported query language.
Sigma, the vendor-neutral detection format. sigma-cli and pySigma convert it to KQL, SPL, Elastic, and other backends through backend-specific conversion pipelines.
Sigma is the detection equivalent of writing source code: a single representation that compiles to multiple targets. The conversion is not just string substitution; pySigma pipelines handle field mapping, logsource translation, and backend-specific syntax. This is the source format you learn in Phase 1.
YAML, since both SIEMs can import raw YAML files.
JSON, which both platforms read natively.
You have a Sigma rule for detecting Kerberoasting. Before merging it, you want proof it catches the attack and does not fire on legitimate service-ticket requests. What do you test it against?
Committed test fixtures: a true-positive event (a Kerberoasting TGS request with the distinguishing fields) and a benign baseline event (a normal service-ticket request). Both are files in the repo alongside the rule, and the test asserts the rule fires on the first and stays silent on the second.
Fixture-based testing is the centre of the course (Phase 3). The fixtures are committed with the rule so the test is repeatable, reviewable, and does not depend on a live environment. A rule that passes on its fixtures and fails in production tells you the fixtures were incomplete, which is a fixable, trackable problem.
A live SIEM by watching for alerts over a week.
The rule's YAML syntax only; if it parses, it works.
A manual review of the query logic without running it.
Your CI pipeline converts a Sigma rule to KQL and the conversion fails with a field-mapping error: the Sigma field name does not exist in the Sentinel schema. What is the correct response?
Skip the error and deploy the rule anyway.
Remove the Sentinel backend from the pipeline.
File a bug against Sigma for using the wrong field name.
Update the pySigma field-mapping configuration to map the Sigma field to the correct Sentinel column, or fix the Sigma rule to use a field the mapping already covers. The pipeline config is code, and the fix is a reviewed change to that config.
Field-mapping errors are the most common conversion failure. The fix is in the pipeline configuration (the pySigma processing pipeline or field mapping YAML), not in abandoning the backend or ignoring the error. Treating the pipeline config as code means the fix is a commit, a review, and a test, same as a rule change.
You have 140 Sigma rules deployed. Leadership asks what percentage of MITRE ATT&CK techniques your detections cover. How do you answer?
Estimate based on how many rules you remember writing for each tactic.
Generate an ATT&CK Navigator layer from the rule metadata in your repository. Each Sigma rule carries its ATT&CK mapping in the tags field; a script reads the repo, maps rules to techniques, and produces a coverage layer you can load in the Navigator to see which techniques are detected and which are gaps.
Coverage-as-code (Phase 5) means your ATT&CK coverage answer comes from the same repo that holds your rules. The coverage layer is a generated artifact, not a maintained spreadsheet, and it updates every time a rule is added or removed. The gap analysis is accurate because it reads the inventory, not someone's memory.
Count the total number of rules and divide by the total number of ATT&CK techniques.
Check the SIEM's built-in ATT&CK dashboard.
A Sigma rule uses the near modifier to correlate two events within a five-minute window. sigma-cli converts it to KQL, but the converted query does not preserve the temporal correlation. The detection is for a real threat and needs to ship. What do you do?
Recognize that this is the Sigma expressiveness ceiling for this backend. Write the detection as a native KQL rule that handles the temporal join correctly, and version that native rule through the same pipeline: same repo, same PR review, same CI tests, same deployment stage. Sigma is the default unit, not the only one.
Sigma has real expressiveness limits, and pretending otherwise would be dishonest. Module 9 teaches exactly this: the point where a detection legitimately escapes to native query language. The discipline (version it, test it, review it, deploy it through the pipeline) still applies; only the source format changes. A course that claimed every detection is a Sigma rule would be a marketing course.
File a feature request and wait for the Sigma project to add support.
Deploy the broken converted query and accept the gap.
Remove the detection from your coverage because Sigma cannot express it.
This course is for you.
You will build the full detection-as-code pipeline from the source format through testing, CI, deployment, coverage tracking, and the operating model, in your own GitHub account.
You have the fundamentals. The value here is the engineering practice.
You know Sigma and version control. The payoff is the testing, CI, deployment, coverage-as-code, the tuning feedback loop, the expressiveness ceiling, and the operating model that keeps a detection programme healthy.
You handled the version-control rationale, fixture-based testing, conversion pipeline, coverage-as-code, and the Sigma expressiveness ceiling. Take the course to close the gaps you did not expect and turn strong instincts into a pipeline you own.
You are a student of this course now, so start by deciding what you want from it. Are you here to stand up a detection pipeline for the first time, to replace a console-managed rule set with an engineering practice, or to bring structure to a team that already writes detections but ships them by hand? Name that outcome, then turn it into a study plan: which pipeline stages matter most to your organization, how much time you will give it each week, and what you want to be able to ship by the time you finish.
The rest of Module 0 sets you up to do exactly that. Work through it to see what detection-as-code is and why console-managed detection fails, watch a single Sigma rule convert to two SIEMs and pass through a CI check, walk the end-to-end pipeline and the repository you build, set up the toolchain, and read how the course is structured. Then begin Module 1.
Stuck on this lesson?
Your question goes straight to the team and we'll reply by email. Sign in to ask.
