Detection Engineering, as Code

Enterprise SOCs already collect enough telemetry to detect more than 90% of the adversary techniques used against them. Their SIEMs actually detect about 21% — and roughly one in eight production rules is broken and will never fire at all (CardinalOps, State of SIEM Detection Risk, 2025; the 13% broken-rule figure is the average across five years of their data).

That gap has a name now. It isn't a data problem, and it isn't a headcount problem. It's an engineering problem — and it's why we built Talon Studio.

The coverage illusion

The numbers across the industry's own measurement studies tell one consistent story:

• 21% of MITRE ATT&CK techniques are covered by detections that actually exist in production SIEMs, while the telemetry already being ingested could support 90%+ (CardinalOps, 2025).
• 14% of simulated attacks raise an alert, even though 54% are successfully logged — fewer than one in seven (Picus Blue Report, 2025).
• The average SOC fields roughly 4,484 alerts a day, and its analysts are unable to deal with about two-thirds of them (Vectra AI, 2023).
• Global median attacker dwell time has now worsened two years running — 10 to 11 to 14 days — the first back-to-back deterioration on record (Mandiant M-Trends, 2025–26).

Evidence reaches the SIEM and no alarm sounds. Rules break silently — nothing alerts when a detection dies, so the failure mode of a broken rule is indistinguishable from a quiet network. And the content most teams run is content they don't own: in a SANS/Anvilogic survey, respondents reported that 66% of false positives originate in vendor-provided rules (State of Detection Engineering, 2026).

The discipline's answer — and where it stalls

The detection engineering community has known the fix for years: treat detections the way engineers treat software. Anton Chuvakin sketched it in 2020 — "a more systematic, flexible and comprehensive approach to threat detection… somewhat inspired by software development." Open formats like Sigma made rules portable. Atomic Red Team made them testable. Palantir's ADS framework popularized documenting and reviewing them.

Adoption tells a sharper story. Per the SANS/Anvilogic 2026 survey (n=307): 62% of practitioners now report version control for detection rules, 58% have peer review — and only 42% have CI/CD for detections. Teams adopt version control, then stall twenty points short of automated test-and-deploy, because that last step demands platform engineering most detection teams can't spare. 72% cite time and resource constraints; 61% a lack of in-house skills.

The practice is proven. The tooling burden is what a platform has to absorb.

What we built

Talon Studio is a self-hosted, vendor-neutral detection engineering platform, delivered as a single container you run on your own infrastructure. A few opinions are built into its bones:

Start from evidence, not assumptions. Talon Studio connects to your SIEM with metadata-only introspection — indexes, sourcetypes, fields, CIM data models, the existing rule estate. No raw log streams are ingested. That metadata becomes a live evidence topology, and an evidence engine distills it into canonical gap records: blind spots, missing fields, broken dependencies, failed deployments. Every gap carries a severity and a confidence — confirmed, probable, or inferred. What it cannot prove, it does not claim.

Detections are code. Every detection is a vendor-neutral YAML file — Sigma as the canonical query — versioned in a Git-backed workspace with branches, change requests, and full commit history. One canonical rule compiles through an embedded pySigma engine into SPL, KQL, EQL/ES|QL, and YARA-L. Splunk gets a live deployment loop today, continuously verified in CI against a real Splunk instance; Sentinel, Elastic, and Chronicle get generated artifacts, with live loops on the roadmap.

Prove it, then watch it. Detections validate on demand against Atomic Red Team-derived telemetry where a matching test exists. Release gates block anything the connected SIEM can't actually run. Every installed rule — Talon-managed or legacy — gets a scored health grade: broken, silent, noisy, or stale. A rule that regresses from pass to fail is marked degraded, never silently forgotten.

The agentic part — and why the substrate matters

AI agents are arriving in the SOC faster than governance can keep up. The same 2026 survey found 83% of detection practitioners already use AI tools — but only 42% trust them for core work like tuning detections. Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027, largely over inadequate risk controls.

The teams making agentic AI work in detection engineering — Block, Panther, Google, Elastic — converged on the same pattern independently: agents propose, automation validates, humans approve through code review. At Block, roughly 40% of new detections in 2025 were created with AI assistance, and every one still required human review before it shipped.

Talon Studio ships that pattern as a hard platform invariant, not a convention. Talon Claw, the platform's AI layer, brings a fleet of ten purpose-built agents — detection engineer, coverage analyst, threat hunter, triage analyst, and more — running on models you choose, including fully self-hosted ones. Every agent is propose-only. An agent's output lands on a branch as a reviewable change request with validation evidence attached. Merging requires an approving human, and that's enforced in the service layer: the merge call throws unless a human approved it. No agent can push to a protected branch, approve, merge, or deploy — and every run is recorded step-by-step, under token budgets, concurrency caps, and a kill switch.

Our engineering principle, straight from the evidence engine's design document: AI is allowed to suggest fixes, but only from structured gap evidence. AI is not a source of truth.

Where we are

Talon Studio is in open beta, and we're deliberately candid about what that means: the Splunk loop is live, other SIEM targets are export-only today, and the platform hasn't yet completed an external security audit — the plan for one is published in the repository. What's already there: the full authoring-to-deployment lifecycle, the evidence engine, ATT&CK coverage from SIEM evidence, threat-intel-driven prioritization, rule health scoring, a public API, MCP support in both directions, and the governed agent fleet.

If you want the long version — the full industry analysis, architecture diagrams, and the governance model in detail — it's below.

Your detections, as code, in your Git, on your infrastructure — with AI that proposes and never merges. That's the whole idea.

---

Industry figures cited from: CardinalOps State of SIEM Detection Risk (2024, 2025); Picus Blue Report 2025; SANS/Anvilogic State of Detection Engineering (2025, 2026); Vectra AI (2023); Mandiant M-Trends (2025, 2026); Gartner (2025); Detection at Scale (2025, 2026); Anton Chuvakin, "Can We Have Detection as Code?" (2020). Vendor-sponsored research is attributed to its vendor throughout.