Detection as Code: Sigma Rule Pipeline, MITRE ATT&CK Coverage Mapping, and Atomic Red Team Validation
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most SOC detection rules are managed directly in the SIEM console: a analyst writes a search, saves it as a correlation rule, and there is no change history, no peer review, and no way to know whether that rule is covering the technique it was written for. When an incident occurs and the question is 'why did this detection not fire?' the answer requires reconstructing what the rule looked like at the time, what log sources it was querying, and whether the field names it referenced were correct — all of which is unavailable without version control.
Detection as code puts the detection engineering workflow on the same infrastructure as software development: Git for change history, pull requests for review, automated validation for syntax and coverage, and Atomic Red Team for functional validation that the detection fires when the technique is executed.
Building the detection pipeline in 60 days
The 60-day detection-as-code implementation follows a deliberate sequence: capture existing rules first, then build the pipeline infrastructure around them, and add automated validation last. Starting by converting current SIEM correlation rules to Sigma YAML is more valuable than writing new rules from scratch, because it creates the first version of the ATT&CK coverage map reflecting actual deployed coverage rather than aspirational coverage. Practitioners use pySigma backends (sigma convert -t splunk, -t elasticsearch, -t microsoft365defender) to generate SIEM-native queries from Sigma YAML within the CI/CD pipeline, ensuring every rule change is automatically converted and deployed rather than manually pasted into the SIEM console. The Git repository structure mirrors the MITRE ATT&CK tactic hierarchy so that coverage gaps are visible by directory, and mandatory ATT&CK technique tags in each rule's metadata enable DeTT&CT to generate an ATT&CK Navigator layer on every commit. Atomic Red Team validation tests for the 20-30 highest-priority techniques are the final layer, running automatically after rule deployment to confirm detections fire before the pipeline reports success.
Start with existing detection rules converted to Sigma format before writing new rules
The first step in adopting detection as code is not writing new rules — it is capturing existing rules in Sigma format. Export current SIEM correlation rules or saved searches and translate them to Sigma YAML, adding the required ATT&CK technique tags to each based on what the rule detects. This converts the existing detection investment into the format required for the pipeline and produces the first version of the ATT&CK coverage map showing current state. Capture existing rules before adding new ones so that the coverage map reflects actual deployed coverage rather than only new rules written after the process started. This also reveals how many existing rules have never been mapped to a specific ATT&CK technique, which indicates detections whose detection intent is unclear.
Integrate Atomic Red Team validation into the deployment pipeline for critical technique coverage
For the 20-30 highest-priority ATT&CK techniques (based on threat actor relevance to your organization), create a validation test record that maps each technique to the specific Atomic Red Team test number that validates the detection. Run these validation tests on a dedicated test Windows system immediately after deploying rule changes that affect those techniques, and fail the deployment if the expected detection alert does not appear in the SIEM within 5 minutes of test execution. This automated validation prevents deploying a detection change that inadvertently breaks coverage for a high-priority technique — the same kind of regression testing that software CI/CD uses to prevent breaking working functionality.
Coverage reporting: communicating detection posture
Translating detection engineering work into communication that security leadership can act on requires converting Git-tracked Sigma rules and ATT&CK technique tags into a visual coverage report that non-engineers can interpret. The ATT&CK Navigator layer generated by DeTT&CT from the tagged rule set serves this purpose: techniques colored green are covered by deployed and validated detections, yellow indicates deployed but unvalidated coverage, and white indicates gaps. Generating this layer automatically on every main branch commit means the coverage report is always current without requiring manual updates. Monthly metrics — ATT&CK coverage percentage for the prioritized technique list, mean time from threat intel identification to detection deployment, and false positive rate per rule — communicate program maturity beyond the visual heatmap and give the detection team a prioritized backlog for closing the highest-risk gaps.
Generate a monthly ATT&CK Navigator coverage report from the pipeline
Configure the CI/CD pipeline to generate an ATT&CK Navigator JSON layer file on every main branch commit and publish it as a static artifact or to an internal portal. The Navigator layer shows each ATT&CK technique colored by coverage level: covered by a deployed and validated detection (green), covered by a deployed but not validated detection (yellow), or not covered (white). This visualization communicates detection posture to security leadership without requiring them to understand SIEM query syntax, and provides the detection engineering team with a prioritized gap list showing which high-priority techniques lack coverage.
Track detection lifecycle metrics to measure program maturity
Track detection program metrics monthly: mean time from threat actor technique identification (from threat intelligence feed or CISA advisory) to detection rule deployment (measures detection agility), the ATT&CK coverage percentage for your prioritized technique list (measures breadth), the percentage of deployed detections that have been validated with Atomic Red Team tests (measures confidence), and the false positive rate per rule measured by the ratio of analyst-closed true-positive alerts to suppressed or tuned alerts. A detection program is mature when new high-priority techniques are covered within 30 days of identification, 80% or more of prioritized techniques have coverage, and the false positive rate per rule is below 10%.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
Detection as code replaces SIEM console-based rule management with a version-controlled pipeline that provides change history, peer review, automated validation, ATT&CK coverage mapping, and Atomic Red Team functional validation. The implementation starts with converting existing rules to Sigma format with ATT&CK technique tags, building the pySigma conversion and SIEM deployment pipeline, and generating the first ATT&CK Navigator coverage layer from the tagged rules. Atomic Red Team validation confirms detections fire when techniques are executed. Monthly coverage reports communicate detection posture to leadership and produce the prioritized backlog of coverage gaps that drives the detection engineering roadmap.
Frequently asked questions
What is detection as code and why should SOC teams adopt it?
Detection as code applies software engineering practices to security detection rule management: rules are stored in Git version control rather than directly in the SIEM console, changes go through pull requests with peer review, automated tests validate rule syntax before deployment, and a CI/CD pipeline deploys validated rules to the SIEM automatically. The benefits over direct SIEM console management: change history shows who changed a detection, when, and why — making post-incident analysis possible, rule review catches logical errors and missing conditions before they cause false positives or missed detections, rollback restores a previous rule version in seconds if a change causes problems, and MITRE ATT&CK coverage can be automatically calculated from rule metadata rather than manually maintained in a spreadsheet.
How do I convert a Sigma rule to Splunk SPL using pySigma?
Install the Sigma CLI and the Splunk backend: pip install sigma-cli pySigma-backend-splunk. Convert a single rule file with sigma convert -t splunk -p splunk_windows rule.yml which outputs the Splunk search query. The -p flag specifies the pipeline — splunk_windows maps Sigma field names to Splunk field names for Windows event log data. Convert multiple rules from a directory: sigma convert -t splunk -p splunk_windows rules/ outputs all converted queries separated by newlines. For integration with Splunk's saved search API, the sigma convert output is the search string that goes in the search field of a Splunk saved search or correlation search. Add --output-format saved_searches to format the output as a Splunk saved search configuration file directly. Different SIEM platforms require different pipelines (field name mappings) — check the pySigma backend documentation for the correct pipeline for your SIEM platform and data source.
How do I structure a detection rule Git repository?
Structure the detection rule repository with a directory hierarchy matching the MITRE ATT&CK tactic structure: rules/initial_access/, rules/execution/, rules/persistence/, rules/privilege_escalation/, rules/defense_evasion/, rules/credential_access/, rules/discovery/, rules/lateral_movement/, rules/collection/, rules/command_and_control/, rules/exfiltration/, rules/impact/. Store each rule in its tactic directory as a .yml file named by technique ID and a brief description: rules/credential_access/t1003.001-lsass-memory-access-mimikatz.yml. Create a tests/ directory mirroring the rules structure for Atomic Red Team test mappings and test result archives. A README.md at the repository root documents the pipeline, the rule naming convention, the mandatory metadata fields for each rule, and the contribution workflow for adding or modifying rules.
How do I map my detection rule coverage to MITRE ATT&CK using DeTT&CT?
DeTT&CT (Detect Tactics, Techniques and Combat Threats) generates MITRE ATT&CK Navigator layer files showing which techniques have detection coverage. Install DeTT&CT with pip install dettect. Create a data sources YAML file documenting which log sources are available in your SIEM, then create a detection YAML file referencing each Sigma rule and its corresponding ATT&CK technique tags. Run dettect.py detection -fd detection.yaml -l to generate a Navigator layer JSON file showing coverage as a heatmap: techniques with coverage appear colored and techniques without coverage appear in white. Export the Navigator layer to the ATT&CK Navigator web app for visualization. Integrate this into the CI/CD pipeline so that every commit to the detection rule repository regenerates the coverage layer, making the MITRE ATT&CK coverage map always current with the deployed rule set.
How do I validate that a detection actually fires using Atomic Red Team?
Atomic Red Team provides PowerShell-based adversary simulation tests for each MITRE ATT&CK technique. Install the Invoke-AtomicRedTeam PowerShell module on a test Windows system (Install-Module -Name Invoke-AtomicRedTeam -Force) and install the test content (Install-AtomicRedTeam -Force -getAtomics). To test a specific technique: Invoke-AtomicTest T1003.001 -TestNumbers 1 executes atomic test number 1 for T1003.001 (LSASS Memory credential dumping). After execution, check the SIEM for the corresponding detection alert — if the detection fired, the validation passes. If not, investigate whether the required log source is sending data, whether the Sigma rule converted correctly to the SIEM query, and whether the SIEM query field names match the actual log field names. Document validation results per rule: which atomic tests were run, on which Windows version, and whether the detection fired.
How do I build a CI/CD pipeline for detection rule deployment?
Build the detection pipeline as a GitHub Actions or GitLab CI workflow with three stages: validate, convert, and deploy. In the validate stage, run sigma check rules/ to verify all rules pass Sigma schema validation, and run any custom validation scripts that enforce team standards (required fields, MITRE tag format). In the convert stage, run sigma convert for each target SIEM and save the output as pipeline artifacts. In the deploy stage (on merge to main only), use the SIEM's API to upload the converted queries as saved searches or detection rules: the Splunk REST API accepts saved search definitions, the Microsoft Sentinel API accepts analytics rule objects, and Elastic supports detection rule import via the REST API. Store SIEM API credentials as pipeline secrets rather than in the repository. Run the pipeline on every pull request for validation and conversion, and trigger the deploy stage only on merge to main after the required code review approval.
How do I identify detection coverage gaps using the MITRE ATT&CK framework?
Identify detection gaps by comparing your current rule coverage map (from DeTT&CT or manual technique tagging) against the threat actor techniques most relevant to your organization. Prioritize techniques used by threat actors in your industry sector (from MITRE ATT&CK Groups pages and your threat intelligence feeds), techniques flagged in recent CISA advisories for your sector, and techniques involved in significant breaches in your industry over the past 12 months. For each high-priority uncovered technique, determine whether the required log source is available (if not, log source onboarding is the prerequisite), whether a community Sigma rule exists for the technique (check the SigmaHQ/sigma repository), and whether a custom rule needs to be written. The coverage gap list becomes the detection backlog: prioritize items by the combination of threat actor relevance, log source availability (low-cost to add detection), and the criticality of the technique to your threat model.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.