Most organizations learn whether their defenses work the same way: once a year, a red team shows up, spends a few weeks, and hands over a report. The report is accurate the day it is written and slowly decaying every day after, because the environment changes, controls drift, rules get disabled "temporarily," and new techniques enter the wild. Continuous attack emulation is the answer to that decay. Instead of asking "did we pass the audit in March," it asks, every day, "if a known adversary ran their actual playbook against us right now, which steps would we catch, which would we block, and which would walk straight through." This article previews the Continuous Attack Emulation capability coming to Pragma Core, and uses it as a lens on why the whole industry is moving from point-in-time testing to a loop that never stops.
This is a two-layered breakdown. The first part is for readers who need to understand what continuous attack emulation is, how it differs from a pentest or a vulnerability scan, and whether their team needs it, with no framework jargon required. The second part goes into the mechanics: how the MITRE ATT&CK matrix turns into executable tests, what a continuous emulation loop actually does, and how Pragma Core wires this into the same workspace that already holds your code, dependencies, and findings. Because this is a feature preview, the article is explicit about what is available today and what is on the roadmap, rather than pretending everything already ships.
Part I. Executive breakdown
What continuous attack emulation is
Adversary emulation is a structured offensive exercise where defenders replicate the specific tactics, techniques, and procedures of a real, named threat actor, drawn from threat intelligence, to see whether their controls would detect, prevent, or respond to that actor's real-world behavior. Unlike open-ended red teaming, it is scoped to a particular adversary or campaign, and it produces direct evidence: this technique was detected, this one was blocked, this one was missed.
Breach and attack simulation, or BAS, is what makes that exercise automatable and safe to run on a schedule. A BAS engine executes prebuilt attack techniques mapped to known adversary behavior, measures how your security controls react, and scores the result. "Continuous" is the word that changes everything: rather than a single annual snapshot, the same battery of techniques runs again and again, so the moment a control silently stops working, you see the test go from green to red instead of finding out during an incident.
Put plainly, continuous attack emulation is a robot adversary that safely re-runs a curated set of real attacker moves against your environment on a recurring basis, and tells you exactly which of your defenses are doing their job today.
How it differs from the testing you already do
A vulnerability scanner tells you a door might be unlocked. A penetration test pays a human to try the door, walk through it, and see how far into the house they get, once. Continuous attack emulation checks every day whether the alarm goes off when that specific door is opened, and whether the lock you installed last month is still engaged. They answer different questions, and mature programs run all three.
The crucial distinction is that emulation tests your detective and preventive controls, not just the existence of a flaw. Your SIEM, EDR, email gateway, and segmentation rules are not "ready out of the box"; they need tuning, and tuning drifts. Continuous emulation is the regression test for that tuning.
Who needs it
| Team profile | Why it matters |
|---|---|
| SOC and detection engineering | Continuous proof that detections still fire after every rule change, agent upgrade, or vendor update. |
| CISOs and risk owners | A defensible, evidence-based answer to "are our security investments actually working," expressed as ATT&CK coverage rather than a vendor's promise. |
| Teams under CTEM or compliance pressure | A repeatable, scheduled validation loop that maps cleanly onto continuous threat exposure management and audit requirements. |
| Lean teams without a standing red team | Adversary-grade testing without hiring a full offensive team or waiting for the annual engagement. |
The number worth sitting with: a control that was validated once at deployment and never again is, after the first configuration change, an assumption rather than a fact. Continuous emulation is how you keep it a fact.
What this preview includes
This is a feature preview, so candor matters. The capability arrives in stages. The early access focuses on scheduled emulation of selected ATT&CK techniques mapped to current threat intelligence, with results expressed as a coverage view across the matrix. Deeper threat-actor playbooks, tighter SOC-response chaining, and richer remediation workflows follow on the roadmap. Where this article describes the destination, it says so.
Part II. Technical breakdown
The matrix underneath: MITRE ATT&CK
MITRE ATT&CK is a continuously updated knowledge base of real-world adversary tactics and techniques, organized as a matrix: tactics are the attacker's goals (initial access, persistence, privilege escalation, lateral movement, exfiltration, and so on), and techniques are the concrete ways they achieve each goal. It is the lingua franca of modern defense because it gives offense and defense a shared vocabulary. When you say a control "covers T1059," everyone knows you mean command and scripting interpreter abuse, and everyone can check whether you actually do.
MITRE also publishes Adversary Emulation Plans, prototype playbooks built from public threat reports and ATT&CK, precisely so defenders can model real adversary behavior rather than abstract checklists. Continuous attack emulation is the operationalization of that idea: take the matrix and the plans, make the techniques executable and safe, and run them on a loop.
How a technique becomes an executable, safe test
The path from a matrix cell to a running test has a few steps:
- Select techniques from intelligence, not at random. The techniques you emulate should be the ones that named actors relevant to your sector actually use. Emulating APT29 or Scattered Spider behavior is more useful than firing every technique blindly, because coverage of techniques nobody uses against you is busywork.
- Make each technique a safe, parameterized action. A good emulation action exercises the real behavior (for example, a specific credential-access or discovery action) without causing the real damage. This is the line that separates breach and attack simulation from an actual breach, and getting it right is the hard engineering.
- Evaluate preconditions before each step. Multi-stage scenarios run against a live environment full of uncertainty, so each step should re-check whether its preconditions hold immediately before it runs, rather than blindly executing a fixed script. Asynchronous, state-aware execution is what keeps a multi-step emulation realistic instead of brittle.
- Measure the control response. For each action, capture whether it was prevented, whether it was detected (did an alert fire, was the event even logged), and whether anyone would have responded. The output is not "vulnerable / not vulnerable," it is a prevention and detection result per technique.
- Map results back onto the matrix. The aggregate is a coverage heat map: green where you prevent and detect, amber where you log but do not alert, red where the technique walks through untouched.
What "continuous" actually buys you
The single-run version of this is already valuable. The continuous version changes the failure mode you are protected against. Consider the lifecycle of a real detection:
Day 0 Detection rule deployed, emulation confirms it fires [GREEN]
Day 14 EDR agent auto-updates, rule silently stops matching [still shows GREEN in last year's report]
Day 15 Continuous emulation re-runs the technique, alert is absent [RED] <-- caught here
Day 16 Detection engineering fixes the rule, emulation confirms [GREEN]
Without continuous emulation, the gap between day 14 and the next annual test is an open window you do not know is open. With it, the window is the time between two scheduled runs. That is the entire argument for the category, compressed: continuous testing converts silent control failures into visible, dated, actionable findings.
Where Pragma Core fits this in
Pragma Core is a continuous, AI-driven application security platform built by zer0day Technologies and Expertware. It already connects to your repositories, runs continuous SAST, dependency and SBOM tracking, AI security research, and pentesting, and it carries Adversary Emulation as a platform pillar: breach and attack simulation aligned with the live MITRE ATT&CK matrix. Continuous Attack Emulation is the productization of that pillar into a recurring loop.
The differentiator is context. A standalone BAS tool knows your controls but not your code. Pragma Core runs emulation in the same workspace that already holds your repositories, your dependency graph, your call graphs, and your prior findings. That means an emulation result does not float free as "technique T-whatever was missed"; it can be tied back to the part of your stack that made the technique reachable, the way the Splunk-style internal-service exposures and the deserialization sinks we have written about elsewhere connect a code-level defect to an attacker-level outcome.
A note on the methodology
Two design principles separate a useful continuous emulation capability from a noisy one. First, intelligence-led selection: the matrix is large, and coverage for its own sake produces dashboards nobody acts on. The techniques worth running continuously are the ones tied to actors and campaigns that target your sector. Second, AI-assisted reasoning over results: the value is not the raw red cells, it is the agent that looks across a failed technique, the control that should have caught it, and the code or configuration that exposed it, and proposes the specific fix. That is where Pragma Core's autonomous-agent approach to investigation extends naturally from finding flaws in code to validating whether your defenses would catch their exploitation.
Why continuous emulation matters, beyond any single tool
- Point-in-time assurance decays the moment it is issued. Every annual pentest report starts aging on day one. A loop is the only structure that keeps an assurance statement true over time, because the environment it describes never stops changing.
- Controls fail silently, and silence is the dangerous part. A detection that stops firing rarely announces itself. The failure is invisible until an incident or an emulation surfaces it, and only one of those two is something you can schedule.
- ATT&CK coverage is a better KPI than vulnerability counts. "We detect and prevent the techniques the actors targeting our sector actually use" is a defensible posture statement. "We closed 400 findings" is activity, not assurance.
- Emulation tests the defense, scanning tests the surface. They are complementary, not interchangeable. You need to know both that a door is unlocked and that the alarm fires when it opens.
- Continuous beats periodic for the same reason CI beats a yearly code review. The shorter the loop, the smaller the window in which a regression survives undetected. Security validation is converging on the same insight software testing reached a decade ago.
What the Pragma Core Continuous Attack Emulation preview does
This section is the feature preview proper. It describes the capability as it is taking shape, and is explicit about staging.
Scheduled, intelligence-led emulation against the live matrix
The core of the preview is a recurring emulation loop: select techniques drawn from current threat intelligence and the live MITRE ATT&CK matrix, run them safely on a schedule, and track the result over time. Because the matrix is updated continuously upstream, the emulation set keeps pace with how adversary behavior actually shifts, instead of testing last year's techniques forever.
Coverage expressed as an ATT&CK heat map
Results roll up into a coverage view across tactics and techniques: prevented, detected-but-not-prevented, logged-but-not-alerted, and missed. The point is to give a CISO and a detection engineer the same picture at different zoom levels, the executive sees posture, the engineer sees the exact technique to fix.
Findings tied back to your code and configuration
This is the part a standalone BAS product cannot do. Because emulation runs in the same Pragma Core workspace as your SAST results, dependency tracker, and call graphs, a missed technique can be correlated with the code path, exposed service, or vulnerable dependency that made it reachable. The autonomous agents that investigate code-level findings extend to reasoning about why a control failed and what to change.
Continuous, not a one-off engagement
Like the rest of Pragma Core, this runs as an ongoing extension of your subscription rather than a separate, scheduled external engagement. The same loop that scans your repositories on every change re-validates whether your defenses still catch the techniques that matter, on a recurring basis.
On the roadmap
Deeper named-actor playbooks, tighter chaining into full SOC-response validation (not just prevention and detection but response), and richer, prioritized remediation workflows are on the roadmap rather than in the first preview. The honest framing: the preview proves the loop and the matrix coverage; the destination is a fully chained, response-aware, code-correlated validation engine.
Closing thoughts
Continuous attack emulation is not, fundamentally, about having more attack scripts. It is about a change in tense: from "we were secure when we last checked" to "we are secure right now, and here is the dated evidence." The same shift happened in software delivery years ago, when teams stopped trusting a quarterly QA pass and moved to continuous integration, because the only way to keep a fast-changing system trustworthy is to test it continuously. Security validation is making that same move, and the MITRE ATT&CK matrix is the shared map that makes it measurable.
The difference between treating your last red-team report as the truth and treating it as a snapshot already going stale comes down to AppSec maturity and how much of your environment you can actually see and test on a loop. Organizations that want to move from "we scan and report" to "we systematically and continuously verify what is fragile, in our code and in our defenses" can reach Pragma Core at pragma-core.com for a demo and early access to the Continuous Attack Emulation preview.
Sources
- MITRE ATT&CK, Adversary Emulation Plans, attack.mitre.org.
- Picus Security, What Is Adversary Emulation? Definition, Process, and How It Differs From Red Teaming.
- SafeBreach, MITRE ATT&CK: The Complete Guide, December 2025.
- Picus Security, Breach and Attack Simulation Platform and MITRE ATT&CK Framework Guide.
- SCYTHE, Best Breach and Attack Simulation (BAS) and AEV Tools 2026, April 2026.
- MITRE Corporation, Automated Repeatable Adversary Threat Emulation with Effects Language, arXiv preprint, 2025.