On June 9, 2026, an unknown threat actor published the full source code for the Miasma worm toolkit. Not a proof of concept but the actual toolkit, with payloads targeting 15 AI coding agents running inside enterprise CI/CD pipelines. Within hours, derivative campaigns were already in motion.
Your team got an alert on this threat. Now what?
That’s the question most enterprise security programs can’t answer cleanly. Not because they missed the signal — catching the signal is the easy part. Miasma didn’t emerge from nowhere. It follows the playbook TeamPCP ran a month earlier with Shai-Hulud 3.0: open-source the worm, launch a public affiliate contest, and convert from a single threat actor into a platform. Once that happens, you’re no longer tracking a campaign. You’re defending against a technique deployed by an unknown number of operators on unknown timelines pointing at targets you can’t see.
The Problem With “We Got the Alert”
Traditional threat intelligence is built around actor tracking. You monitor who holds a capability, what infrastructure they’re using, and who they’ve targeted before. That model works reasonably well when the capability is concentrated. When an actor publishes the source code publicly, it stops working. You can’t track the downstream operators. You don’t know their timelines. You’re defending against a technique now, not an actor.
Most programs aren’t built to solve those issues. They’re built to respond to alerts — open a ticket, trigger a playbook, and patch what’s exposed. What they can’t do quickly is answer three questions at once: does this technique intersect with our environment right now? Are the controls designed to catch it configured to catch this, not just generically enabled? And where’s the gap we don’t know about yet?
The time between asking those questions and answering them is where exposure lives.
There’s a fourth problem that doesn’t get named enough: cyber threat intelligence (CTI) teams aren’t 24/7 operations. Most run business hours with an on-call rotation, and threat actors know this. The Bitwarden CLI compromise ran for a 90-minute window on April 22, 2026. This window isn’t accidental; it’s a structural feature of how these campaigns are built.
Compressed, high-velocity supply chain campaigns are designed to execute and retract within the gap between when a human analyst would notice and when they could act.
The continuous monitoring layer isn’t a replacement for the CTI team’s analytical function. It’s what makes sure that when something happens at 2 AM, the environment context and control validation are already running, the alert is already formed, and whoever picks it up — an on-call responder or the team lead walking in at 8 AM — inherits a complete picture rather than a raw signal that needs hours of assembly. The CTI team’s job is judgment, and the continuous layer exists so that judgment is never applied blind.
Three Layers, Not Three Tools
The right response to Miasma isn’t faster alert response. It’s a different program architecture, one where three layers operate continuously and in parallel, rather than sequentially under pressure.
Real-time external monitoring is the first layer. Not just the publication event, but everything that follows. Which actors are referencing the capability in their own communications? What campaign infrastructure is being stood up? Is there sector-specific targeting chatter pointing Miasma at financial services, critical infrastructure, or your organization? The signal evolves as the capability spreads across an expanding and largely invisible actor set. The monitoring has to keep pace.
Environment fusion is the second layer, and it’s where most programs break down. External signal without internal context is a guess, not a risk determination. Do you run any of the 15 targeted AI coding agents? In what context — isolated dev environment, or with access to production secrets? Those questions need to get answered automatically and in minutes, not through a ticket to asset management. Fusion is what turns an awareness alert into something actionable: a prioritized risk determination routed to the right people with the right context already attached.
Continuous control assessment is the third, and the one layer most programs don’t have. Knowing you run one of the targeted tools is necessary but not sufficient. What actually determines your exposure is whether the controls designed to catch Miasma’s persistence mechanism are working right now. As Dataminr’s Shai-Hulud 3.0 deep dive documented, TeamPCP’s supply chain tradecraft exploits the moment of import before application-level secrets management activates and before pipeline controls fire. The payload doesn’t breach anything, it executes inside what you’ve already authorized. Miasma follows the same logic, extended to 15 AI coding agents and their IDE workspace trust relationships. Continuous control assessment tells you whether the behavioral controls that would catch this technique are actually configured correctly, against your actual build agent, today — not as of your last audit.
What It Looks Like When the Three Layers Are Working
Dataminr for Cyber Defense surfaces the open-sourcing event the moment it appears, be it from a dark web forum, a GitHub repository, or a paste site. In the DurableTask campaign, Dataminr detected initial signals ahead of broader industry notification, before the Wiz FLASH alert was confirmed on May 19. That gap between early signal and industry-wide awareness is exactly where this model earns its keep.
Dataminr cross-references immediately against your environment. You run two of the 15 targeted tools, and both have pipeline access to production secrets. That’s a specific, prioritized risk determination, not a generic alert pushed to a queue.
At the same time, the control monitoring layer runs a validation check. Your endpoint detection coverage on those two tools surfaces a configuration gap from last week’s infrastructure update. The behavioral rule designed to catch Miasma’s persistence pattern isn’t active on your new build agent. That gap wouldn’t have appeared in your last audit. It doesn’t surface from the external signal alone, it surfaces because all three layers are running continuously and talking to each other.
One alert reaches your security team with full context: you’re in scope, here’s the exposure, here’s the control gap, and here’s the remediation. Not three separate findings assembled manually under time pressure.
Speed metrics also miss something important. They assume a human is in the loop at the moment the threat materializes. Usually they’re not. Faster response times don’t solve a problem that occurs between shifts. What solves it is monitoring that doesn’t sleep, so the analyst’s first action is a decision, not a reconstruction of what happened overnight.
The Board Conversation This Enables
Boards have gotten better at asking hard questions about cyber posture. “We detected it and responded” used to be enough. Increasingly it isn’t, particularly under NIS2, SEC reporting requirements, and DORA, where the question is whether the organization has a verified defensive posture, not whether it recovered after the fact.
The three-layer model changes what a CISO can say in that room. A new capability emerged. Within minutes, we determined whether we were in scope. We validated our control coverage against the specific technique before any exploitation attempt. We found and closed a gap our last audit wouldn’t have caught. That’s a different conversation than incident response, and it’s the one regulators and boards are starting to demand.
The open-sourcing problem actually makes this argument easier to land. When a single actor holds a capability, monitoring that actor is a reasonable proxy for exposure. When the capability is public, that logic breaks down entirely. Continuous validation that your controls hold against the technique itself, regardless of who’s deploying it, is the only answer that scales.
One of the harder conversations is the coverage gap itself. NIS2 and the UK Cyber Security and Resilience Bill create personal accountability for cyber exposure, but exposure doesn’t observe business hours. The question worth putting to your own program isn’t simply, “do we have a CTI function?” It’s what happens to the threat picture at 6 PM on a Friday. If the answer is an on-call number, that’s a gap worth closing. The threat doesn’t clock out; the program needs a component that doesn’t either.
Dataminr for Cyber Defense
Transform intelligence into a preemptive cyber advantage from first signal to risk-prioritized action.
Learn More
