Your detections are lying until you prove they fire
A SOC dashboard reports seventy-eight percent detection coverage. Someone runs one Atomic Red Team test against a Windows technique the rule was supposedly watching, and nothing fires: not the EDR alert, not the SIEM alert, not the SOAR runbook. The rule had been enabled in the SIEM for over a year, and nobody had ever tested it, so by the day the test finally ran it did not work.
That is the load-bearing miss most blue teams inherit. Rule count is not coverage. A rule you never proved is a rule that eventually is not there.
Detections also rot after they have been proven to work. EDR gets tuned to quiet a noisy release and drops a Sysmon channel in the process, a log source gets rerouted through a new aggregator that renames one field, a group policy pushes a Sysmon configuration change that quietly reverts on a subset of endpoints during a Windows update. None of those changes trip a red banner, and every one of them narrows what a rule can catch. Deepwatch and the wider detection engineering community call the failure mode detection rule decay, and it is why a rule tested green in March can be broken by June without a line of the rule itself changing.
The category is not new
Gartner named the fix in the 2026 market guide: Adversarial Exposure Validation (AEV). Gartner defines AEV as technologies that deliver "consistent, continuous and automated evidence of the feasibility of an attack" and confirm how attack techniques would exploit an organization and bypass its prevention and detection controls. AEV is positioned as the validation stage of Continuous Threat Exposure Management, and it explicitly replaces the older 2023 Hype Cycle labels of Breach and Attack Simulation and automated pentesting. Gartner projects that by 2029, sixty percent of organizations will run a structured exposure validation practice as part of CTEM, with AEV vendors and managed providers as the primary enablers. Full framing in Hadrian's summary of the guide.
Detection engineering maturity models arrive at the same conclusion from the practitioner side. Elastic's Detection Engineering Behavior Maturity Model, the community maturity matrix by Kyle Bailey, and Anvilogic's continuous coverage scoring all put continuous, automated validation at the top tier and define coverage the same way: a rule that has been tested to fire, measured against MITRE ATT&CK rather than counted as raw rules in a SIEM. An untested rule does not count.
The commercial AEV vendors already sell the finished chain end to end. Picus, Cymulate, SafeBreach, and AttackIQ each promise the same loop as a product: technique executed against the environment, EDR detection or miss recorded, SIEM alert generated or absent, SOC workflow triggered, response action verified, cycle repeated. The category and its finished shape are not what needs inventing.
What actually needs building is the on-ramp
Most SOCs have never reached the top tier of any of those maturity models. Practitioner surveys over the last three years land on the same finding year after year: a majority of blue teams either do not run continuous validation at all, run one-off annual purple team weeks and call it done, or trust a rule count on a dashboard. The whitepapers describe a destination they have not been shown how to reach without vendor budget.
The playbook below is not a new framework. It stitches together five open-source parts into the same loop the mature shops already run, so a team with no AEV budget can climb into it. Every piece is production-grade already, every piece is free, and every piece can be swapped for a paid AEV product later without discarding the work.
The loop, in five open-source parts
1. A coverage matrix keyed to MITRE ATT&CK
The matrix is a plain repository, a spreadsheet, or a self-hosted ATT&CK Navigator layer that lists every technique in scope for the environment, with three states per technique: a detection exists, the detection was tested to fire in the last N days, the detection produced a verified downstream response. The matrix is the source of truth for coverage. Rules in the SIEM are the implementation, not the score.
2. A safe emitter that produces real telemetry
Atomic Red Team ships more than 1,800 small, portable tests mapped to MITRE ATT&CK, each one reproducing a specific technique through the same command sequences an operator would run. MITRE Caldera sits above it with 527 default procedures and adds multi-step emulation through a lightweight agent, at the cost of a heavier operator setup. Stratus Red Team from Datadog covers cloud with 27 granular AWS attack techniques that self-provision, detonate, and clean up. Between the three, most of the ATT&CK grid a normal SOC needs to cover has a validated open-source emitter.
3. A scheduler you build yourself
Atomic Red Team ships no orchestration on purpose, and Red Canary's own docs recommend Invoke-Atomic and leave the runner to you. The scheduler is a small service: a scheduled GitHub Actions workflow, a Kubernetes CronJob, a Nomad batch job, or a Python script under systemd. It walks the coverage matrix, picks the next technique due for re-test, provisions a sandboxed target, invokes the emitter, and stamps the run with a timestamp and target metadata. Fifteen lines of YAML is enough to start.
4. An evidence gate that reads the alert side
The gate queries the SIEM and EDR alert stores after each execution and records whether the expected alert fired, how long it took, and whether the parser populated the required fields. A missing alert is not a defect in the emitter. It is a recorded gap against the technique, with the raw telemetry the SIEM did or did not receive attached as evidence. Coverage state on the matrix updates from these results, not from what the analyst thinks is enabled.
5. A gap ledger fed to detection engineering, with response verified end to end
Every recorded gap becomes a ticket in the detection engineering backlog carrying the technique ID, the emitter payload, the queries that should have matched, and the raw telemetry that reached the SIEM. Detection engineers stop guessing and start closing falsifiable coverage requests. The gate also reads the SOAR run log to confirm the runbook triggered and the response step completed, because an alert with no response is a half-coverage. The whole chain then re-runs on a cadence: high-severity techniques monthly, the rest quarterly, and everything after a rule change immediately. Re-test is the part that beats decay.
One technique, before and after
Take T1053.005, Scheduled Task creation through schtasks. In the before state, the SIEM has a correlation rule tagged with the technique ID and a status of enabled. Coverage is reported as one point on the matrix. Nothing else is known. In the after state, the coverage matrix records that atomic test T1053.005-1 ran on a controlled Windows host at 03:00 UTC last Sunday, the corresponding SIEM alert fired within a median of forty seconds across the last twelve runs, the SOAR runbook opened a case and requested analyst review, and the last full-chain green run was three days ago. Same technique, same rule, same SIEM. The difference is not new tooling; the difference is that the loop turns a rule status of "enabled" into a rolling record of when it last actually caught what it was written for.
What this playbook does not do
It is not a red team. It cannot cover initial-access techniques as well as post-compromise ones, because Caldera and Atomic Red Team both lean toward the phases where an agent is already resident on the host, and the two libraries carry thinner coverage for the perimeter. It also cannot prove what your telemetry does not capture: if a Sysmon event ID is missing from the pipeline, the technique will execute on the host, no telemetry will reach the SIEM, and the gate will (correctly) surface a gap in the parser or the sensor rather than the rule. Treat that as a feature, and pair the loop with a small perimeter emulation exercise or a lightweight external emulator for the phases the libraries cover thinly.
Why we published it
The AEV vendors did the work of naming the category and shipping the finished loop, and their case is not wrong. The reason most SOCs have never reached the top of the maturity model is not that they disagreed. It is that no one handed them an on-ramp they could adopt without buying a platform first. This is the on-ramp: five parts, all in production somewhere already, all free.
CVEasy runs the same loop end to end through BlueTeamAutomation for teams that would rather operate the assembly than build it. The loop is worth having on any stack, and continuous proof beats a rule count on any budget.