Detection as Code: When SOC Rules Become Software
09.09.2026 detection-engineeringsocthreat-huntingci-cd
From Gut Feeling to Pipeline
In many SOCs, detection rules still get built the way they did 15 years ago: an analyst clicks through the SIEM UI, cobbles together a query, saves it — done. Who wrote it, why it exists, and whether it still works often becomes a mystery within months. That’s exactly the problem “Detection as Code” (DaC) addresses: treating detection logic like software — version-controlled in Git, covered by automated tests, and shipped through CI/CD pipelines. Detection as Code changes this model, treating detections like software: versioned, owned, testable, and automated from the start. Rather than relying on manual, UI-driven workflows, DaC uses code, version control, and automated pipelines to keep rules reliable, auditable, and maintainable.
The driver isn’t academic — it’s alert fatigue, plain and simple. Teams using AI-driven enrichment report that roughly 60-70% of the alerts they work on are categorized as benign, a noise level that ad-hoc rule writing simply can’t keep pace with. Leading SOCs show it can be done differently: world-class SOCs maintain false positive rates below 10% through MITRE ATT&CK-aligned detection logic, ML classification models, and automated enrichment. Security provider Expel reported that 75.6% of the detections it monitored in 2025 were Expel-written or Expel-enhanced — custom logic built for high-fidelity alerts rather than sheer volume.
Two Roles, One Feedback Loop
The organizational consequence is significant: detection engineering is becoming its own discipline, distinct from classic SOC triage and from threat hunting. Security operations focuses on monitoring, triaging, and responding to alerts in real time — SOC analysts work the alert queue, investigate incidents, contain threats, and coordinate remediation, while detection engineering is a development discipline focused on building and maintaining the detection content the SOC relies on. Mature programs formalize this with a concrete staffing ratio: roughly one detection engineer per five to seven SOC analysts, with a minimum of two for organizational redundancy — a 20-analyst SOC should have three to four dedicated detection engineers.
Crucially, detection engineering and threat hunting aren’t rivals — they feed each other. Detection engineering focuses on creating and improving rules that spot known and emerging threats, while threat hunting is a more manual, proactive search for suspicious activity. Both are vital, but detection engineering helps defenders operate at scale, and successful hunts should yield detections, keeping the two in a feedback loop. In practice, this means integrating threat hunting into the detection development cycle so that successful hunts must produce a detection rule within two weeks.
What This Means for Incident Response
For IR practice, DaC pays off in several concrete ways. First, speed: with a DAC CI/CD pipeline, security teams can respond to emerging threats quickly by creating or modifying detection rules and having them tested and deployed with minimal manual effort. Second, traceability during an active incident: version control answers who changed which rule and when — a detail that matters both in the heat of the moment and for later regulatory reporting. Third, discipline against rule decay: a “zero-hit lifecycle” principle ensures that rules without true positives or near-miss evaluations for three months are either left as-is, adjusted, escalated to threat hunting, or disabled — with owner assignment and a review date.
Teams still relying entirely on manually maintained SIEM rules shouldn’t treat DaC as a mere tooling upgrade. It’s an organizational rebuild: clear roles, CI/CD infrastructure, and a tight, documented feedback channel from incidents and hunts back into rule code. That’s precisely what determines whether the next 3 a.m. alert storm stays a routine event — or escalates into a genuine crisis.
← Back to overview