Detection as Code: Building Versioned, Testable Security Detections for Splunk ES, CrowdStrike, and GitHub

Your security team wrote 200 detection rules last year. How many were tested before deployment? How many have an owner? How many still fire on threats that matter, and how many generate noise that everyone ignores?

For most organizations, the honest answer is uncomfortable. Detection rules accumulate like technical debt: created in a GUI, copy-pasted between environments, never version-controlled, rarely tested, and impossible to audit. When a breach happens, the first question regulators ask is "what detections did you have in place?" and the second is "how did you validate them?" If your answer involves screenshots from a SIEM console, you have a governance problem.

Detection as Code (DaC) eliminates this problem by treating detection logic exactly like application code: version-controlled in Git, peer-reviewed through pull requests, tested in CI/CD pipelines, and deployed through automated workflows. According to Splunk's 2025 State of Security research, 63% of security professionals want to adopt DaC practices, but only 35% do so today. That gap represents both risk and opportunity.

Why Detection as Code Matters for the Business

The shift from GUI-managed rules to code-managed detections is not a developer preference. It is a governance imperative that directly impacts three board-level concerns: audit readiness, operational efficiency, and incident response effectiveness.

**Board Brief:** Detection as Code transforms your security monitoring from an unauditable collection of GUI rules into a governed, testable, version-controlled engineering discipline. It directly supports SOC 2, ISO 27001, and NIST CSF control evidence requirements while reducing mean time to deploy new detections from days to minutes.

Platform Playbook: Splunk Enterprise Security

Splunk offers the most mature DaC ecosystem in the SIEM market, anchored by two open-source projects: the security_content repository and the contentctl CLI tool.

How It Works

Detections are authored as YAML files that define the SPL search logic, MITRE ATT&CK mappings, data model requirements, and test cases. The contentctl tool validates these YAML definitions, transpiles them into Splunk .conf files (correlation searches, analytic stories, macros), and packages them as an Enterprise Security Content Update (ESCU) app.

The CI/CD pipeline runs through GitHub Actions: every pull request triggers validation of SPL syntax and macro references, unit testing against sample data using Splunk's Attack Range lab environment, integration testing that verifies risk actions and notable events generate correctly, and automated packaging of the ESCU app for deployment.

Getting Started with Splunk DaC

Fork splunk/security_content as your organization's detection repository

Install contentctl (pip install contentctl) for local development

Structure detections as YAML with mandatory fields: search, type, datamodel, mitre_attack_id

Configure GitHub Actions to run contentctl validate and contentctl test on every PR

Deploy validated packages to Splunk ES via REST API or the deployer

The Splunk RBA Community maintains additional resources for teams implementing risk-based alerting alongside DaC practices.

Platform Playbook: CrowdStrike Falcon

CrowdStrike's detection as code story centers on Custom IOA (Indicators of Attack) rules managed through the FalconPy SDK, a Python library that wraps the Falcon API.

How It Works

Custom IOA rules define behavioral patterns that CrowdStrike's Falcon sensor evaluates on endpoints. Rather than creating these rules through the Falcon console, DaC teams define rule groups and individual rules in code, store them in Git, and deploy through API calls in CI/CD pipelines.

The FalconPy CustomIOA service class supports the full lifecycle: creating and updating rule groups, defining rules with platform-specific criteria (Windows, macOS, Linux), enabling or disabling rules across tenants, and replicating rule sets across MSSP environments. Community tools like CrowdStrike IOA Clone extend this further for multi-tenant management.

Closing Detection Gaps

CardinalOps has documented a critical integration that maps your MITRE ATT&CK coverage goals against existing Falcon detections, identifies gaps, and delivers new Custom IOA rules through automated pipelines. This transforms gap analysis from a quarterly spreadsheet exercise into a continuous improvement loop.

Getting Started with CrowdStrike DaC

Generate API credentials with Custom IOA read/write scopes in the Falcon console

Install FalconPy (pip install crowdstrike-falconpy)

Define IOA rule groups as JSON or YAML in your detection repository

Build deployment scripts that use CustomIOA.create_rule and CustomIOA.update_rules

Add CI steps for schema validation and rule conflict detection before deployment

Platform Playbook: GitHub Advanced Security

GitHub's contribution to Detection as Code operates at a different layer: securing the code itself before it reaches production. CodeQL is the core engine, a semantic code analysis framework that compiles source code into a queryable relational database.

How It Works

Instead of pattern matching (like grep for vulnerabilities), CodeQL understands data flow, control flow, and type relationships. Security engineers write queries in the CodeQL query language (QL) to describe the characteristics of insecure code. These queries run as part of GitHub Actions workflows, flagging results as code scanning alerts directly in pull requests.

CodeQL supports 14 languages including Python, JavaScript, TypeScript, Go, Java, C/C++, C#, Ruby, Swift, and Rust. GitHub provides default query suites, but the real DaC value comes from custom queries tailored to your organization's frameworks, libraries, and coding patterns.

Beyond CodeQL

GitHub's security toolchain includes three additional DaC surfaces: secret scanning with custom patterns (regex-defined rules for detecting proprietary token formats), Dependabot configuration as code (.github/dependabot.yml for automated dependency updates and vulnerability alerts), and GitHub Actions security workflows that orchestrate SAST, DAST, and SCA tools in your CI/CD pipeline.

Getting Started with GitHub DaC

Enable GitHub Advanced Security on your organization

Configure default CodeQL setup for immediate coverage

Create custom CodeQL queries for organization-specific vulnerability patterns

Define custom secret scanning patterns for internal token formats

Build a .github/dependabot.yml with your update strategy and security policy

Cross-Platform Detection Strategy with Sigma

The practical challenge with multi-platform DaC is avoiding vendor lock-in. Sigma addresses this as an open, vendor-agnostic detection format. Sigma rules are written in YAML with structured fields for detection logic, and community-maintained converters transpile them into platform-specific queries for Splunk SPL, CrowdStrike LogScale, Microsoft Sentinel KQL, and dozens of other targets.

Over 350 community Sigma rules are already mapped to MITRE ATT&CK tactics and techniques. MITRE's own Cyber Analytics Repository provides a cross-walk of CAR, Sigma, Splunk Security Content, and Elastic Detection rules in terms of their ATT&CK coverage, giving you a clear picture of where your detection gaps live.

The recommended architecture for organizations running multiple security platforms: maintain a central Sigma repository as your canonical detection library, with platform-specific repositories that consume Sigma rules and transpile them for each target (e.g., detections-splunk, detections-crowdstrike, detections-github).

Mapping to NIST CSF 2.0

Detection as Code directly supports multiple NIST Cybersecurity Framework 2.0 functions:

Implementation Readiness Checklist

Before rolling out DaC across your security stack, validate these prerequisites:

[ ] Git Repository Structure: Dedicated detection repos with branch protection and required PR reviews

[ ] CI/CD Platform: GitHub Actions, GitLab CI, or equivalent with secrets management for API credentials

[ ] MITRE ATT&CK Baseline: Current coverage assessment documenting which techniques you detect today

[ ] Detection Ownership Model: Every rule has a named owner responsible for tuning and lifecycle management

[ ] Testing Infrastructure: Splunk Attack Range or equivalent lab for validating detections against sample data

[ ] Sigma Adoption Plan: Decision on whether to use Sigma as a canonical format for multi-platform deployments

[ ] Metrics Dashboard: Track detection deployment velocity, false positive rates, and ATT&CK coverage percentage

[ ] Runbook Integration: Connect detection metadata to response playbooks so analysts know what to do when a rule fires

How I Help

Detection as Code is a security architecture discipline that requires strategic planning, tooling decisions, and organizational change management. With 20+ years of experience designing and leading security programs, I help organizations move from ad-hoc detection management to engineered, auditable detection pipelines.

Security Architecture Services: I design the detection-as-code architecture for your environment, including repository structure, CI/CD pipelines, cross-platform Sigma strategies, and MITRE ATT&CK coverage mapping. This is where the technical blueprint gets built.

Virtual CISO Services: I embed as your security leader to drive DaC adoption across your SOC, building the governance model, ownership structure, and metrics framework that sustain the program long-term.

Compliance Advisory: Detection governance directly supports SOC 2 CC7.1 (monitoring), ISO 27001 A.8.16 (monitoring activities), and NIST CSF DE.CM controls. I map your DaC practices to framework evidence requirements so audit preparation becomes a byproduct of your engineering workflow.

Board Advisory: I translate detection maturity into board-ready metrics: ATT&CK coverage percentage, mean time to deploy new detections, and false positive reduction trends. Your board gets visibility into whether security monitoring is keeping pace with the threat landscape.

AI Governance: As AI-powered detection tools proliferate (auto-generated Sigma rules, ML-based alert tuning), establishing governance around AI-assisted detection engineering becomes critical to maintaining trust in your security monitoring.

Ready to move your detection program from GUI screenshots to governed, testable, version-controlled code? Let's build the architecture.

Schedule a discovery call →