Detection as Code Workflows in Modern Security Teams

Detection as Code applies the discipline of software engineering, version control, automated testing, peer review, continuous deployment, to the business of writing and maintaining threat detection logic. Security teams that manage detection rules the way engineering teams manage application code get an audit trail, a rollback button, and a way to scale detection coverage that clicking through a SIEM console never could. Closing the gap between the teams that talk about Detection as Code and the teams that actually run it this way is mostly a matter of understanding what the workflow demands in practice, not just in theory.

Consider the alternative first, because it explains why the industry started moving. Under traditional rule management, analysts log into a SIEM's graphical interface and build detection logic by hand, click by click, with no version history and no single owner attached to any given rule. When an incident hits, the questions that matter most, who changed this rule, when, and why, often have no answer, because there was never an audit trail to begin with. Rules get written reactively, in the heat of a live investigation, and then tested against production traffic instead of a staging environment; this pattern is common in less mature security operations. None of this would be a survivable problem if alert volume were small. It isn't, because none of this would be a survivable problem if alert volume were small. Security teams face, on average, 960 alerts, and large enterprises average 3,181. One estimate puts the daily load on an average SOC at 11,000 alerts, of which only 19% turn out to be worth investigating. Forty percent of alerts never get investigated, and the average dwell time before an analyst even triages an alert runs to 56 minutes. At that scale, sloppy rule management is a structural failure waiting to surface during the next incident. It's a structural failure waiting to surface during the next incident.

What Detection as Code is and where it came from

Detection as Code treats detection rules, SIEM logic, WAF filters, alert conditions, the works, as software. That means the rules get written in structured, plain-text formats such as YAML or Python instead of being buried inside a vendor's UI, stored in version-controlled repositories instead of a database table nobody can diff, and deployed through CI/CD pipelines instead of a person clicking "save" in a browser tab.

None of this is a novel idea invented by security teams. It's a direct import from the Infrastructure as Code and DevOps movements that took hold in the early 2010s, when engineering teams realized that treating servers, networks, and deployment steps as version-controlled code eliminated whole categories of manual error. Security caught up a few years later. Cloud providers and security-focused vendors started publishing detection rules in public repositories around 2016 to 2018, and that's roughly the point where Detection as Code stopped being a theoretical crossover and started being something teams could actually copy.

The gap between wanting DaC and running it

Most teams say they want this, and most teams don't have it. Sixty-three percent of security professionals say they'd like to frequently or always use Detection as Code going forward, but only 35% currently do. Adoption among enterprise security teams did grow, roughly threefold between 2022 and 2025, but that growth started from a low base, so the raw percentage gain flatters the underlying reality more than it should.

Even among the teams making progress, adoption tends to run shallow. A lot of what gets called Detection as Code amounts to pulling vendor-supplied rules or public repository content into a pipeline and calling it done, rather than writing and owning custom detection logic tuned to an organization's own environment. Vendor rules are built for the general case, and environment-specific tuning is where much of the real detection work still falls on internal analysts.

The 2026 SANS State of Detection Engineering Report puts a number on how much this gap costs. Only 18% of practitioners say they're staying ahead of the evolving threat landscape. Cloud-native environments rank as the number one detection coverage gap, by a margin far exceeding any other environment category. Those two figures together paint a blunt picture: 80% of teams are treading water or falling behind, even while reporting high confidence in their own internal processes. Confidence and coverage, in other words, have come apart.

The four engineering disciplines DaC imports into security operations

Version control is the foundation everything else sits on. Git, whether hosted on GitHub or GitLab, becomes the single source of truth for detection logic. That gets a team an audit trail of who changed what and when, review and approval gates that a rule has to pass before it goes live, and a rollback option the moment a rule misbehaves in production. Commit messages, often treated as an afterthought, end up preserving the reasoning behind a detection decision long after the analyst who wrote it has moved to a different team or a different company. That's institutional memory that a point-and-click workflow simply has no place to store.

CI/CD pipelines handle the testing and deployment layer. The workflow in practice: an analyst defines a detection in a YAML file, commits it to a Git repository, and a CI/CD pipeline, built on something like GitHub Actions or GitLab CI, automatically tests the rule and pushes it to the SIEM. That replaces manual, GUI-driven rule creation with something repeatable and auditable, and it lets a team deploy the same detection logic consistently across multiple environments or multiple security tools without a human retyping it each time.

Test-driven development is the discipline that changes the underlying question a SOC can answer. Instead of guessing at coverage, Detection as Code lets a team see exactly which detections exist, and the precise conditions under which each one fires or fails to fire. That means testing against different input data types, different platform versions, and different plugin versions that transform data along the way, since a detection that works against one log format can silently break against another. Sixty-two percent of teams that adopt Detection as Code say it's what unlocked test-driven development for their detection logic specifically, as opposed to just their application code.

Peer review closes the loop. Detection logic goes through a pull-request model, reviewed before it reaches production, the same way application code does. That opens the door to cross-functional collaboration: threat intelligence analysts, incident responders, and detection engineers can all propose changes or review someone else's. It also cuts down on the coverage gaps that occur when detection engineering happens in a silo, where one analyst's blind spot never gets a second set of eyes.

Key tools that make DaC workflows operational

Sigma sits near the center of most Detection as Code stacks. It's a generic, vendor-agnostic format for writing detection rules in YAML, and the Sigma rule repository organizes rules into three types: generic detection, threat hunting, and emerging threat. The command-line tool sigma-cli lets teams create and manage these rules and convert them for use across multiple SIEM platforms, which turns out to matter most during a SIEM migration, when a team can convert an existing rule library instead of rebuilding it from scratch. The core value of Sigma is interoperability: write a detection once, deploy it in more than one place.

The MITRE ATT&CK framework provides the structure most teams use to organize detection logic by adversary technique, and it's become close to a universal reference point for that purpose. Tagging Sigma rules with the right ATT&CK techniques, though, is slow, manual work that demands fluency in both detection syntax and how adversaries actually behave, and that friction repeatedly drags on Detection as Code adoption.

GitHub and GitLab supply the repository layer, version control, peer review, and collaboration on detection logic all living in one place, with GitHub Actions and GitLab CI acting as the execution layer that triggers automated testing and deployment the moment someone commits a change. Splunk, meanwhile, remains one of the more widely used SIEM and data analytics platforms that plugs directly into these CI/CD workflows, giving teams continuous monitoring and automated detection deployment without a separate manual step at the end.

What a DaC workflow looks like end to end

Following a single detection rule through its full lifecycle makes the value of the approach concrete fast. Threat intelligence surfaces a new lateral movement pattern, and an analyst writes the detection logic in YAML or Python, not inside a SIEM's graphical console. That code gets committed to a Git repository, a pull request opens, and a detection engineer along with a threat intel analyst review it before anything moves further.

From there, the CI/CD pipeline takes over the testing. Against synthetic attack data, does the rule fire? Does it throw false positives against benign traffic? Does it hold up across different log formats and plugin versions? A rule that passes moves to staging, then to production. A rule that fails gets flagged, and the pipeline blocks deployment until someone fixes it. Once live, a noisy rule can trigger an auto-disable mechanism or get routed into a feedback loop for post-mortem review, rather than sitting in production quietly generating alerts nobody trusts.

That same structure, version-controlled rules tested in staging before reaching production, is what allows teams to strengthen detection coverage and reduce alert fatigue at the same time, rather than trading one for the other. The same principle scales further when teams compile version-controlled Sigma rules into executable formats and run them on streaming engines, compressing detection latency significantly.

That end-to-end structure also doubles as a maturity path for less advanced teams. The 46% of teams currently running on out-of-the-box vendor detections don't need to start by writing custom logic from scratch. Running those existing vendor rules through version control and a CI/CD pipeline first, before attempting anything custom, gives a team the operational muscle memory it needs before it takes on harder detection engineering work.

How AI is being integrated into DaC workflows, and where it still falls short

The case for bringing AI into this pipeline starts with a scale problem that has nothing to do with hype. Research suggests that in recent years the volume of high-severity vulnerabilities published has outpaced what an internal detection team could realistically write manual rules for by more than an order of magnitude. Manual rule authoring, in other words, has run into a wall that more headcount won't solve. The volume of AI-generated rules reflects that pressure: at SOC Prime alone, AI-generated detection rules grew from roughly 60 in June 2025 to nearly 1,000 by October 2025, doubling month over month.

Research is moving fast to catch up with that demand. RulePilot is an LLM-based agent that takes a natural-language description from an analyst and generates a detection rule without further human intervention. The AVDA framework goes a step further, using the Model Context Protocol to feed an AI system organizational context, existing detections, telemetry schemas, house style guides, so the rules it generates fit a specific environment instead of a generic one.

The numbers coming out of AVDA cut in two directions at once. Agentic workflows show a 19% improvement in overall similarity score over baseline approaches, and sequential workflows reach 87% of that agentic quality at 40 times lower token cost, a trade-off that matters to any team paying by the API call. TTP matching accuracy is 99.4%, and syntax validity is 95.9%, both strong results by any measure. Exclusion parity, though, is just 8.9%. That's the gap between a rule that fires correctly and a rule that fires correctly without also drowning analysts in false positives, since exclusion logic is what filters out the noise. An AI system can learn to match a technique with startling precision and still miss the nuanced carve-outs that keep a rule usable in production. Expert validation on a 22-detection subset found a solid correlation, a Spearman coefficient of 0.64, between these automated metrics and what practitioners actually judged useful, which suggests the metrics are measuring something real rather than gaming themselves.

The direction the tooling is heading points toward Detection as Code workflows with AI assistance integrated directly into the authoring environment, offering context-aware suggestions as an analyst writes. That's the direction the tooling is heading. Trust in the outputs, though, is not keeping pace with adoption. A SANS 2026 AI survey of 536 security practitioners and 57 CISOs found that AI adoption in security strategy jumped from 50% to 78% year over year, yet only 27% describe their production AI deployment as mature. Sixty-three percent of practitioners reported significant AI shortcomings in threat detection and response, up from 45% the year before, meaning confidence in the technology's rollout is rising while confidence in its output is falling.

The exclusion parity figure from AVDA, that 8.9%, is a concrete technical answer for why this gap exists and why it isn't closing on its own. AI systems have gotten genuinely good at pattern-matching a known adversary technique to a detection rule. They have not gotten good, yet, at the quieter, more judgment-heavy work of knowing what to leave out.