What is Detection as Code?

Understanding Detection as Code

Think of Detection as Code as simply extending the successful "as Code" philosophy - like Infrastructure as Code - into the world of security monitoring. Instead of treating SIEM rules or EDR detections as one-off configurations managed directly through a UI, you define them in a structured, text-based format (like YAML, JSON, or specific query languages).

This shift fundamentally changes how security teams operate. Your detection logic becomes an artifact in a Git repository, subject to the same rigorous development workflow as application code. This enables collaboration, peer review, and a clear audit trail for every change made to your threat detection logic. It's about bringing engineering discipline to security operations.

How DaC Differs from Traditional SIEM Rule Management

Traditional SIEM rule management is often manual, fragile, and lacks visibility. When a detection needs updating, an analyst usually logs into the SIEM, makes a change directly, and hopes it works.

Here is a breakdown of the key differences:

In the traditional model, detection failures (false positives, false negatives, or missed events) may not be discovered until after they cause operational impact in production. With DaC, you can trust that every detection has been peer reviewed and passed automated tests before it reaches production.

Core Principles Behind Detection as Code

The strength of DaC comes from adopting standard software engineering practices. These principles ensure that detection logic is reliable, maintainable, and deployable at scale.

Version Control

All detection rules are stored in a Git repository. Every change - from a simple query tweak to an entirely new detection - is tracked.

• Auditability: Every commit shows who made the change, when, and why. This is important for compliance and incident response.
• Rollbacks: If a new detection causes performance issues or false positives, rolling back to a previous, stable version is instantaneous and reliable using Git commands.

Testing

Testing is the most important part of DaC. Detections are tested against simulated threat scenarios - called "atomic tests" or "integration tests" - before deployment.

• Unit Tests: Validate the syntax and functional correctness of a detection query by testing it against isolated, known test cases to ensure it produces expected results.
• Integration Tests: Run detection logic against realistic, pre-recorded security logs (like Sysmon events or AWS CloudTrail data) to check it triggers correctly for known attack techniques. This helps avoid deploying broken or ineffective detections.

Automation

Automation eliminates manual steps in the deployment process, reducing human error and improving speed.

• Packaging: Tools automatically package the detection logic into the format required by the target SIEM or security platform.
• Deployment: Automated scripts handle the secure insertion or updating of detection rules in the live production environment.

CI/CD Integration

Continuous Integration and Continuous Deployment (CI/CD) pipelines power DaC. A typical DaC workflow follows a DevSecOps process:

1. A detection engineer writes a new detection (e.g., a Sigma rule) and pushes it to a branch in the Git repository.
2. The engineer creates a Pull Request (PR).
3. The CI pipeline is triggered. It automatically runs tests: syntax checks, unit tests, and integration tests against a test log environment.
4. A colleague (a peer reviewer) reviews the code for quality, accuracy, and efficiency.
5. If tests pass and the review is approved, the PR is merged into the main branch.
6. The CD pipeline automatically takes the merged detection code, compiles it for the target platform (e.g., Splunk, Sentinel), and deploys it to production.

Real-World Example

Here's a practical walkthrough of deploying a new detection for the "Pass the Hash" technique (T1550.002 in MITRE ATT&CK):

1. Writing the Detection: The detection engineer defines the logic in a universal format - a YAML file named pass_the_hash.yml - placed in the team's Git repository under /detections/windows/.
2. Creating Atomic Tests: They also create a corresponding test file, pass_the_hash_test.json, containing sanitized log data that should trigger the detection. This is the ground truth.
3. The Pull Request: The engineer commits both files and opens a PR. The PR description links to the threat intelligence source and the relevant MITRE technique.
4. Automated Testing: The CI system (like GitLab CI) runs a testing framework that processes the test logs, applies the detection logic, and confirms the detection triggers exactly once. If the query is too broad, the test fails - prompting improvements.
5. Peer Review: Another detection engineer reviews the query logic and test case, ensuring it's accurate and efficient.
6. Deployment: After merging, the CD system automatically converts the YAML into the needed SIEM format (e.g., a Splunk SPL query) and uses an API to add the new detection to the production SIEM. The whole process takes minutes, not hours, and is fully documented.

Benefits of Adopting Detection as Code

The shift to DaC offers significant operational and security advantages for any modern Security Operations Center (SOC).

Improved Consistency and Reliability

Manual deployment often causes configuration differences across environments. DaC ensures the exact same tested and reviewed detection is deployed everywhere, every time - building trust in your security alerts.

Faster Response to New Threats

When new threat intelligence emerges, a detection engineer can quickly create a matching rule, test it with simulated data, get peer approval, and deploy it automatically within minutes. This speed is key to lowering Mean Time to Detect (MTTD).

Higher Quality Detections

Automated testing pushes detection engineers to be precise. If a detection is too noisy, tests will fail when run against known-good data, providing fast feedback that improves detection quality before it reaches an analyst's queue.

Enhanced Team Collaboration

Using Git and pull requests encourages shared ownership. Detection engineering becomes a team effort where security researchers, SOC analysts, and DevSecOps professionals can all contribute, review, and discuss detection logic.

Scalability

As data sources and environments grow (multi-cloud, hybrid), managing hundreds or thousands of detection rules manually becomes impossible. DaC handles this complexity at scale with clear structures and automation templates.

Common Challenges When Implementing DaC

While the benefits are clear, implementing DaC can present several challenges that teams need to address.

Tooling Fragmentation

There isn't a single "Detection as Code" tool. Teams usually combine several: Git for version control, a CI/CD platform, a detection testing framework, and different SIEM APIs. Bringing these systems together takes strong engineering work.

Expertise Gap

Teams need a mix of security knowledge (understanding threats) and software engineering skills (Git, CI/CD, and testing frameworks). Finding security experts with strong DevSecOps experience can be challenging.

Legacy Infrastructure Integration

Many organizations still use older SIEM or security platforms without modern APIs or easy ways to import rules automatically. This can make automated deployment difficult, requiring custom scripts and extra maintenance.

Handling Sensitive Data in Testing

Effective integration testing needs realistic log data. Ensuring this data is cleaned, anonymized, or synthetically generated to protect sensitive information requires careful planning.

Tools and Technologies Commonly Used in DaC Workflows

Detection as Code relies on a mature ecosystem of standard and specialized tools:

• Version Control: Git (GitHub, GitLab, Bitbucket) - essential for storing detection code.
• Rule Formats:
  • Sigma: An open standard for writing generic SIEM signatures. Write a rule once and use pySigma to convert it to SPL, KQL, EQL, or other SIEM query languages. Actively maintained with backends for all major platforms.
  • YARA / YARA-X: Pattern-matching rules for malware classification and endpoint detection — complementary to log-based SIEM detections. The original YARA was rewritten in Rust as YARA-X, with version 1.0 released in mid-2025.
  • Platform-native query languages: SPL (Splunk), KQL (Sentinel), EQL (Elastic), and YARA-L 2.0 (Google SecOps/Chronicle) are the languages detection engineers write in day to day.
• CI/CD Platforms: GitLab CI, GitHub Actions, Jenkins, or Azure DevOps for automating the testing and deployment pipeline.
• Testing Frameworks:
  • Atomic Red Team: An open-source library of executable test cases mapped to MITRE ATT&CK techniques. Each test simulates a specific attacker behavior to generate telemetry, validating that your detections trigger correctly.
  • Custom Frameworks: Python scripts or utilities built specifically to run Sigma rules against sample log data in isolated test environments.
• Deployment Automation: Platform APIs (Splunk REST API, Sentinel APIs, Elastic Security API), infrastructure-as-code tools (Terraform, Ansible), or native repository integrations to push detection rules to production.

Native Platform Support for Detection as Code

A significant shift in the DaC landscape is that major SIEM platforms are now building DaC capabilities directly into the product, rather than teams needing to build the entire pipeline themselves.

Microsoft Sentinel Repositories

Sentinel offers a native Repositories feature (currently in preview) that connects directly to GitHub or Azure DevOps. When you push changes to analytic rules, hunting queries, playbooks, or workbooks in your repo, Sentinel automatically syncs and deploys them to your workspace. This provides built-in version control, change tracking, and CI/CD without needing to build custom deployment pipelines.

Splunk Security Content

Splunk's Threat Research Team maintains the Security Content repository on GitHub with over 600 detections. The project uses GitHub Actions for CI/CD, automatically testing each detection against Splunk's Attack Range before merging. Teams can fork this repo, add custom detections, and run the same automated testing pipeline against their own environment.

Elastic Detection Rules

Elastic maintains a public detection-rules GitHub repository with built-in DaC tooling. Recent updates added Terraform resources for managing detection rules and exceptions, a custom rules directory with schema validation, and configurable unit testing. This makes Elastic one of the most complete open-source DaC reference implementations available.

DaC-Native Platforms

Beyond traditional SIEMs adding DaC features, platforms like Panther (detections written in Python), Anvilogic (AI-assisted detection engineering), and Google SecOps (formerly Chronicle, using YARA-L 2.0) were built with DaC as a core design principle rather than a bolt-on feature.

Who Should Use Detection as Code

While any organization benefits from improved detection reliability, DaC is particularly essential for specific teams and environments.

Detection Engineers

This practice is the modern way for detection engineers to work. It allows them to focus on high-value threat hunting and rule creation, knowing that deployment and maintenance burden is automated.

Security Operations Center (SOC) Analysts

SOC analysts may not write the code, but they benefit greatly from more accurate alerts, fewer false positives, and clear documentation with every deployed detection.

DevSecOps Professionals

DaC aligns perfectly with the DevSecOps mindset. It bridges the gap between security and development teams by using common tools and practices (Git, CI/CD) to manage security artifacts.

Technical Managers

Managers in security and engineering leadership should drive this adoption. It provides clear metrics on detection coverage, deployment velocity, and team efficiency, enabling better resource allocation and risk management.

Any organization with a significant investment in a SIEM, EDR, or cloud logging infrastructure that handles a high volume of data will quickly find DaC essential for maintaining detection efficacy and control.

Related Labs

Practice writing and testing detection logic with hands-on labs that use real cloud logs and production SIEM tooling:

• Identify IAM Breaches with CloudTrail and Athena - Practice writing SQL-based detection queries against real CloudTrail logs to identify brute force attacks and extract attacker indicators. While Athena is an ad-hoc query tool rather than a DaC deployment target, the skill of crafting precise detection logic from raw logs is foundational to writing rules for any SIEM.
• Investigate a Ransomware Attack in AWS using Splunk - Use Splunk SPL queries to investigate a full ransomware attack chain through CloudTrail logs: trace credential compromise, IAM privilege escalation, KMS key abuse, EBS volume re-encryption, and S3 bucket manipulation.

For structured, certification-track training that covers Detection as Code alongside real attack chains:

• Microsoft Cloud Red Team Expert (MCRTE) Bootcamp - An intensive instructor-led program focused on detection engineering: execute real-world attack chains across Entra ID, Azure, and Microsoft 365, then build detections and response playbooks to catch them.
• Microsoft Cloud Red Team Professional (MCRTP) Bootcamp - Covers practical attack techniques across Azure and Microsoft 365 with a defense component, giving detection engineers first-hand understanding of the attack paths they need to write rules for.

Frequently Asked Questions