Detection-as-Code: A Detection Engineering Playbook With Sigma, CI/CD and MITRE ATT&CK Coverage

Most security teams still manage detection rules the way IT managed servers twenty years ago: by hand, in a console, with tribal knowledge about why each rule exists and who last changed it. A rule gets tuned at 2 a.m. to silence a noisy alert and quietly stops detecting anything. A SIEM migration loses half the custom content. Nobody can say with confidence which attacker techniques the organization would actually catch.

Detection-as-code applies software engineering discipline to this problem. Detections live in version control, are written in a portable format, are tested automatically, are deployed through pipelines and are measured against a shared model of attacker behavior. In 2026 the approach has moved from a practice of a few advanced teams to a mainstream expectation, helped by two shifts: Sigma maturing into a capable vendor-neutral language, and MITRE ATT&CK v18 restructuring how detections map to techniques. This playbook explains how to build the program step by step.

Why Detection-as-Code Matters Now

Several pressures are converging on detection teams at the same time:

• Platform churn: organizations are consolidating SIEM, XDR and data lake tools, and many are moving security telemetry into cheaper storage tiers or security data lakes. Detections written in one vendor’s query language become migration debt.
• Scale: cloud control planes, SaaS audit logs, identity providers and Kubernetes add new telemetry faster than teams can write rules for it by hand.
• AI in the SOC: AI triage agents depend on high-quality, well-documented detections. An agent investigating a vague, untuned alert wastes compute and analyst trust. Detection quality is the foundation of the agentic SOC.
• Accountability: regulators, auditors and cyber insurers increasingly ask organizations to demonstrate monitoring capability. Under regimes such as NIS2 and DORA, “we have a SIEM” is not evidence; documented, tested detections mapped to threats are.

Detection-as-code answers all four. It makes content portable, scalable, reviewable and provable.

The Building Blocks

Sigma as the common language

Sigma is an open, YAML-based format for describing log detections independent of any specific SIEM. A rule declares the log source it applies to, the selection logic, metadata such as author, status, severity and false positive notes, and tags that map it to ATT&CK techniques. Tooling built on the pySigma library, including the sigma-cli command-line tool, converts rules into backend queries for platforms such as Splunk, Microsoft Sentinel, Elastic and others through installable backends and processing pipelines that handle field mappings for each environment.

The Sigma Specification 2.0, released in August 2024, closed several gaps that previously pushed teams back to native query languages:

• Correlation rules with four types — event count, value count, temporal and ordered temporal — so you can express patterns like many failed logins across many accounts followed by a success.
• Filters that keep environment-specific exclusions separate from the core rule, so a shared community rule can be tuned locally without forking it.
• Richer metadata and detection features, including taxonomy and scope fields, field existence checks and placeholders.

Sigma will not cover everything. Complex statistical analytics, machine learning models and some platform-specific features still need native code. A pragmatic target is Sigma for the majority of rule logic, with native content stored and tested in the same repository and pipeline.

ATT&CK v18 as the coverage model

MITRE ATT&CK v18, released in October 2025, replaced the free-text detection notes on each technique with structured Detection Strategies and Analytics, and retired the old Data Sources object in favor of updated Data Components. The chain now runs from technique to detection strategy to analytic to the data components (telemetry) the analytic depends on. MITRE’s release notes list 691 detection strategies and 1,739 analytics in the Enterprise domain alone.

For detection engineers this is significant. Coverage is no longer a matter of tagging a rule with a technique ID and coloring a cell in a heatmap. You can now ask more precise questions: which detection strategy does this rule implement, which analytic is it closest to, and do we actually collect the telemetry that analytic needs? ATT&CK has also signaled further structural change, including splitting the broad Defense Evasion tactic, so mapping automation should expect the matrix to evolve.

Git, CI/CD and a test harness

The remaining building blocks are standard engineering tools: a Git repository with branch protection and code review, a CI system such as GitHub Actions, GitLab CI or Azure DevOps, a way to replay or generate test telemetry, and an API-driven path to deploy content into your SIEM or XDR.

Designing the Detection Repository

A clear repository layout prevents the program from becoming a dumping ground. A structure that scales well looks like this:

• rules/ organized by log source or platform (for example windows, linux, cloud/aws, cloud/azure, identity, saas), containing Sigma rules.
• native/ for content that cannot be expressed in Sigma, organized by target platform.
• filters/ for environment-specific Sigma filters and allow lists.
• pipelines/ for field mapping and processing pipeline definitions per backend.
• tests/ containing positive and negative sample events for each rule.
• docs/ or embedded metadata for triage guidance: what the alert means, how to investigate, known false positives and response steps.
• coverage/ generated reports and ATT&CK Navigator layers, never edited by hand.

Define a rule metadata standard and enforce it in CI. At minimum each rule should carry a stable ID, owner, status (experimental, test, stable, deprecated), severity, ATT&CK tags, required data sources, false positive notes, a link to triage guidance and a review date. Ownership is the field most often missing and the one most often needed when an alert misfires.

The CI/CD Pipeline for Detections

A detection pipeline mirrors an application pipeline, with security-specific stages. On every pull request:

1. Lint and schema validation: check YAML syntax, validate against the Sigma JSON schema and enforce the metadata standard. Reject rules without an owner, ATT&CK tags or triage notes.
2. Conversion check: convert each changed rule with the production backend and pipeline. A rule that does not convert, or converts into an unexpectedly expensive query, fails the build.
3. Unit tests: run the converted query against stored positive samples (events that must trigger) and negative samples (benign events that must not). Each rule needs at least one of each.
4. Noise estimate: run the query against a recent window of real production data in a staging workspace and report the hit count. A rule that would fire thousands of times a day needs tuning before merge.
5. Peer review: a second detection engineer reviews logic, performance and documentation. The pull request description states the threat, the source intelligence and the expected volume.
6. Coverage diff: regenerate coverage reports and show which techniques, detection strategies and data components the change affects.

On merge to the main branch, the pipeline deploys converted content to the SIEM through its API, tags the release and records which rule versions are live. Rollback is a revert commit, not a frantic console session.

Continuous validation after deployment

Passing unit tests proves a rule matches sample events; it does not prove that real telemetry still arrives in the expected shape. Schedule recurring validation: execute safe attack simulations, such as Atomic Red Team tests or a breach and attack simulation platform, in a controlled environment and confirm that the expected alerts fire end to end. Monitor data source health separately, since a silently broken log pipeline disables every detection that depends on it.

A detection that has never been tested against real attack behavior is a hypothesis, not a control. Detection-as-code turns hypotheses into versioned, tested and measurable controls.

Measuring Coverage Without Fooling Yourself

ATT&CK heatmaps are powerful communication tools and dangerous measurement tools. A cell colored green because one rule is tagged with that technique says nothing about whether the rule works, which variants it catches or whether the telemetry exists on the systems that matter.

A more honest coverage model scores each technique on several dimensions:

• Telemetry availability: do we collect the data components the ATT&CK analytics require, across what share of in-scope assets?
• Detection presence: do we have at least one stable rule implementing a relevant detection strategy?
• Validation: has the rule fired correctly in a simulation within the last quarter?
• Fidelity: what is its true positive rate in production?
• Relevance: is the technique used by threat actors who target our sector and technology stack?

Weight the last dimension heavily. Not all techniques are equal, and full matrix coverage is neither achievable nor a sensible goal. Build a prioritized list from threat intelligence about the actors and intrusion patterns relevant to you — for many organizations in 2026 that means identity-based intrusions, help-desk social engineering, cloud control plane abuse, ransomware precursors and abuse of remote management tools — and track coverage against that list first.

Detection Engineering Metrics That Matter

A detection-as-code program generates data about itself. Use it:

• Lead time for a new detection: from threat intelligence or incident finding to rule live in production.
• Validated coverage of priority techniques: share of the prioritized list with a tested, stable detection.
• Alert fidelity by rule: true positive rate and analyst disposition data fed back from the SOC or AI triage agent.
• Noisy rule count: rules above a volume or false positive threshold, with owners and tuning deadlines.
• Stale content: rules past their review date, rules that have not fired or been validated in a long period, and rules dependent on deprecated log sources.
• Change failure rate: deployments that caused alert floods, broken queries or rollbacks.

A 12-Week Rollout Plan

1. Weeks 1–2: Inventory. Export all existing rules from SIEM and XDR platforms, identify owners, and classify each as keep, tune, merge or retire. Expect to retire a meaningful share of legacy content.
2. Weeks 2–3: Foundations. Create the repository, metadata standard, contribution guide and branch protections. Choose backends and build field-mapping pipelines for your environment.
3. Weeks 3–5: Pipeline. Implement lint, conversion and unit test stages. Start with deployment to a non-production workspace.
4. Weeks 5–8: Migrate priority content. Convert or rewrite the rules covering your top threat scenarios into Sigma with tests. Import relevant community rules from the SigmaHQ repository, adapted with local filters.
5. Weeks 8–10: Production deployment. Switch deployment to production via the pipeline and freeze console edits, except for documented emergencies that are back-ported to Git within a day.
6. Weeks 10–12: Coverage and validation. Generate ATT&CK coverage reports using v18 detection strategies, run simulation-based validation for priority techniques, and publish a baseline scorecard.

Worked Example: Detecting Suspicious MFA Device Registration

Suppose threat intelligence highlights intrusions where attackers socially engineer the help desk into resetting a user’s multi-factor authentication, then register their own device. The detection engineer opens a pull request that adds a Sigma rule for identity provider audit logs: an MFA method registration that follows an administrator-initiated MFA reset for the same user within a short window, from an IP address or device not previously seen for that user.

Because this is a sequence, the engineer uses a Sigma correlation rule of the ordered temporal type, combining a base rule for the reset event and a base rule for the registration. A filter excludes the organization’s own onboarding automation account. The rule is tagged with the relevant ATT&CK techniques for account manipulation and valid accounts, and linked to the detection strategy for MFA device registration abuse. Triage notes instruct analysts to verify the reset ticket and contact the user through a known-good channel.

CI validates the metadata, converts the rule for the production SIEM, runs it against a positive sample built from a lab reproduction and a negative sample of a legitimate onboarding flow, and reports that the query would have fired a handful of times over the last 30 days of production data. A reviewer checks two of those historical hits, confirms they were legitimate helpdesk-assisted resets with tickets, and suggests enriching the alert with ticket system data. After merge, the pipeline deploys the rule, the coverage report updates, and next quarter’s simulation exercise includes a scripted reset-and-register scenario to confirm it still fires.

Common Pitfalls

• Console drift: allowing ad hoc edits in the SIEM UI breaks the single source of truth. Detect drift by comparing live content to the repository.
• Tests that only test syntax: a rule with no positive and negative sample events is untested, whatever the pipeline says.
• Heatmap theater: reporting coverage by tag count without validation or telemetry checks.
• Ignoring field mapping: most conversion failures and silent misses come from mismatched field names between Sigma taxonomy and your data. Invest in pipelines and normalization early.
• No feedback loop: without analyst or agent disposition data flowing back to rule owners, noisy rules never get fixed.

Conclusion

Detection-as-code is not a tool purchase; it is an operating model. Sigma provides a portable language, ATT&CK v18 provides a structured way to connect techniques to analytics and telemetry, and CI/CD provides the discipline that keeps detections correct as environments change. Start with a clean inventory and a small, high-value set of rules, make every change reviewable and tested, and measure validated coverage of the threats that matter to you. The payoff is a detection estate you can migrate, explain and trust — and a stronger foundation for every AI agent and analyst who depends on it.

How Hanoi Technology Can Help

Hanoi Technology builds detection-as-code pipelines, migrates SIEM content to Sigma and maps coverage to ATT&CK, as projects, dedicated teams or managed services.

• Cyber Threat Detection
• Incident Response
• Security
• Azure

Further Reading

• Updates – October 2025 (ATT&CK v18) – MITRE ATT&CK
• What’s New in MITRE ATT&CK v18 – Picus Security
• Sigma Specification 2.0: What You Need to Know – Graylog
• sigma-cli – SigmaHQ on GitHub