The post-Mythos period is a few weeks old now and the security community has mostly metabolized the news. A frontier model found thousands of zero-days, including a 27-year-old OpenBSD bug. Anthropic gated the release through Project Glasswing. Similar capabilities will be in the hands of attackers in 6 to 18 months (or, even now?). We've moved past shock and into the part where everyone is quietly recalculating what the next months and years look like.
Let me do that math out loud, because I think most people are still doing it in their heads.
A typical enterprise SOC sees somewhere in the range of 2 to 3 critical incidents a week today. Add the steady churn of high-severity alerts that don't quite hit incident level. Daily patches landing across endpoints, browsers, libraries, and SaaS connectors that the SOC has to absorb as context even when it's not running them. A detection coverage program that was already aging out faster than the team could refresh it.
Now multiply the volume of disclosed vulnerabilities by an order of magnitude. Multiply the variant generation rate by another. Add AI-generated polymorphic payloads that change hashes per victim. Add supply chain compromises like Axios where the blast window is three hours and the affected packages have hundreds of millions of weekly downloads. The disclosed vulnerability volume isn't the SOC's problem directly - that's vulnerability management and engineering. But every spike there produces a corresponding spike in incidents the SOC has to triage, contain, command, and close.
The math is not "this gets harder." The math is "this stops being mathematically possible to handle at human speed with the current architecture."
If you accept the trajectory - 20 to 30 critical incidents a week instead of 2 to 3, a constant rolling drumbeat of supply chain events, daily zero-days landing across the stack - the SOC's day-job math breaks. Investigate. Scope. Decide. Contain. Command the response. Coordinate with engineering. Communicate. Document. At thirty minutes of attention per incident before the real work starts, that's a 15-hour day before anyone handles a real escalation. At an hour each it's a team of six doing nothing else.
You cannot triage your way out of this. You cannot run just build playbooks faster. You cannot hire your way out. We've spent twenty years getting better at playing this game and the game just sped up by 10x.
The architecture that defends an enterprise SOC in 2027 is not the architecture that defends it in 2025 with a faster engine. It's a different architecture. The SOCs that survive are the ones that stop trying to win the existing game and build for a different one.
The body you don't know
There's a useful analogy here from medicine.
Until about 2000, medical practice was reactive at scale. Symptoms appear, doctor diagnoses against a generic library of conditions, treatment follows a standard protocol designed for a generic patient. The whole apparatus assumed a generic body.
The shift to personalized medicine over the last twenty years was structural, not incremental. Your genome, your biomarkers, your medication history, your family pattern all feed into a continuous model of your specific body. Treatment is targeted to your particular biology - not because doctors got smarter, but because the system finally knew enough about you to do something useful. Detection happens earlier, often before symptoms, because the system knows what "normal for this body" actually means.
Security is roughly where medicine was in 2000. We diagnose by symptoms (alerts). We treat with protocols designed for a generic enterprise (vendor playbooks, off-the-shelf detection content). We use the same Sigma rules every other customer of our SIEM vendor uses. We don't know your body - your specific applications, your normal traffic patterns, your crown jewels, your tolerable risk, your ownership topology.
This was always a problem. In the post-Mythos era it becomes a survival issue, because when the volume hits, the SOC needs answers in seconds about things that today take a war-room day to figure out. A critical lands at 2am. The on-call analyst needs to know, before deciding anything:
- Has this affected resource production, staging, or a developer sandbox?
- Who owns it? Which team gets paged for an outage, which gets paged for a breach?
- Which line-of-business applications depend on it? If I contain at the edge, what breaks?
- This service account that just did something suspicious - which automation runs as it? Is it a build pipeline that breaks the deploy if I revoke, or a forgotten cron job nobody will miss?
- What's the blast radius if I'm wrong about any of the above?
These are the questions a SOC analyst asks during every incident. Today they get answered by paging the right person, opening the right runbook, pulling the right CMDB record if there is one, and accepting that the answer is at least partially guessed. That takes an hour on a good day and four hours on a bad one. It's the actual reason most incidents take hours instead of minutes - not the triage itself, but the time to assemble enough context about your specific environment to act with confidence.
A SOC operating on a body it doesn't know spends most of its time figuring out what's actually happening in your specific environment. That's exactly the time you don't have when the volume hits twenty critical incidents a week.
You don't need a faster SOC. You need a SOC that knows your body.
Detection is necessary. It is not sufficient.
A few weeks ago Doug Merritt wrote a sharp post about containment-by-design. The argument was that the era of pure detection is over - at the volumes we're going to see, you cannot triage your way to safety. The architecture has to enforce, contain, and shrink blast radius by default, with the SOC operating the policy rather than chasing the alerts. He's right about the diagnosis.
The piece I'd add - and this is what I posted to Doug at the time - is that containment without continuous control is the next alert fatigue. We spent a decade getting better at producing detection signals and bad at operating them. If we replace that with containment policies we can't operate, we trade alert fatigue for friction fatigue. Legitimate workloads blocked because nobody refreshed the policy. Trust eroding because the system says no and the operator can't say why. Policy hardening around assumptions that aged out six months ago.
Containment is necessary. Containment without trust is the same trap, one layer deeper.
The architecture that holds is containment plus continuous detection and diagnosis - not as eras, as one loop. Detection, investigation and response are all connected. They're not separate disciplines with handoffs between them. They're one continuous control plane, with knowledge flowing between layers the way an immune system shares state between innate immunity, adaptive immunity, and immunological memory.
An immune system doesn't queue tickets. It contains at the edge, escalates only what matters, learns from every event, and persists the lesson without anyone managing the knowledge base. (When it’s working as expected of course…)
That's the architecture we need to build.
Continuous Detection, Continuous Response
We've been calling this CD/CR - Continuous Detection, Continuous Response. The name borrows from the discipline that already solved an analogous problem in software: CICD turned software releases from artisan events into continuous flow. SRE turned operations from firefighting into engineering, with SLOs and error budgets and shared accountability between dev and ops.
Security operations is currently where software operations was in 2010 - detection engineers writing rules, throwing them over the wall to a SOC, the SOC living with whatever quality emerges. Detection coverage decaying silently in production. The two disciplines treated as separate jobs with a handover between them.
CD/CR collapses the wall. Detection and response on the same control plane. Knowledge flowing continuously between them. The detection layer knows what investigation will trigger (and handles the right data) and what response can enforce. The investigation and response layer feeds back into what detection should catch, and what should have been prevented to begin with. Every closed investigation becomes a candidate to be turned into a sharper detection.
The architecture that makes this possible has a specific shape, and at Mate we've been building it around three things.
The first is the Security Context Graph - the substrate that holds your environmental truth. Knows how to find your Policies. Crown jewels. Identity topology. Log sources and where they live. Service account ownership and what runs as them. The investigation history of every incident your team has closed. The reasoning your senior analysts used to close them. Production-versus-development boundaries. Line-of-business application ownership. Without this graph, every detection is generic and every response is risky, because the SOC has to guess at the questions that decide blast radius.
The second is a unified runtime where detection and response are not two systems with a handoff, but one substrate with two faces. Detections fire with reasoning attached and predefined response options scoped to the affected entities. The runtime federates queries across your data sources in place - so context assembly takes seconds, not hours. Containment actions enforce with trust and define by detection fidelity with continuous visibility back to the operator. The SOC operates the policy, and governs the operations; the policy doesn't operate the SOC.
The third is a continuous learning loop where investigations are not just closed but written back into the graph as institutional memory. The next analyst reasoning about a similar case starts where the last one finished. Recurring patterns get compressed into new detections. Stale exceptions get retired before they become permanent holes. The graph compounds.
CD/CR is not a feature, a category, or a workflow improvement. It's the architectural shift that makes a SOC viable when the volume hits the levels Mythos and its successors will produce.
What Mate ships today
I want to be specific, because positioning posts can read like architectural ambition without product to back them up.
What this looks like in a customer environment:
The on-call analyst opens an incident and Mate has already assembled the context the human used to spend an hour gathering - what's production versus development, who owns the affected resources, what depends on this service, what runs as the suspicious service account, what containment action would break. The reasoning the senior analyst used on the last similar incident is queryable. Investigation time compresses from hours to minutes because the questions are pre-answered, and where trust it built, moving to response, automatically.
Detection engineering works in the same loop as the SOC, not adjacent to it. When investigations close, discoveries and patterns surface automatically as detections candidates. New detections enter a supervised tuning zone where agents observe firings and tune against noise without burning analyst attention. Coverage decay gets measured continuously, and silently broken detections are surfaced before they become exposure.
When a public threat disclosure lands - the Axios-style scenarios that are going to become weekly events in the post-Mythos era - the response is automatic and scoped: environment-aware exposure analysis, tailored detections for the affected assets, federated IoC hunts across data in place, multi-step detections compressed for the TTP shape so the next variant gets caught too. The leadership gets a single scoped report, within minutes, not a war room.
How do you know if you're doing CD/CR?
Carson Zimmerman has a presentation called "14 Questions Is All You Need" that I keep coming back to. It's a practitioner-originated framework for measuring SOC health by outcomes, not feature lists. In many cases SOC measurement is either vanity metrics (alerts handled per analyst) or governance metrics (SLA compliance) that don't tell you whether the SOC is actually getting better.
In the spirit of Carson's framing, here are four questions you should be able to answer in numbers if you've built a CD/CR architecture. If you can't, you're playing the old game with a new vendor's logo.
1. Time from threat disclosed to threat contained in your environment.
When the Axios npm supply chain compromise broke on March 31, 2026, one of our Fortune 500 customers had a full picture within minutes of the public disclosure. The threat intelligence agent ingested the reports. The Security Context Graph identified every affected service across their SBOM automatically. Detections were generated only for the exposed assets and tailored to the specific log sources covering those assets. Federated queries hunted the IoCs across their data sources in place - no ingestion lag, no SBOM cross-check by hand. The team opened the platform to a single scoped page: exposed assets, what was hunted, what was detected, what was tuning for the variant. That entire sequence happened automatically while the war room was still being scheduled.
This is the kind of timeline a CD/CR architecture produces. Without it, the same disclosure becomes a war-room day of cross-checking data sources by hand, paging engineering managers to figure out which services pulled the affected versions, and writing detections from scratch against logs you have to discover. That's the model that's going to break under Mythos-era volume. If you can't name a number for "time from disclosed to contained" on a recent incident, you're still inside it.
2. When an incident lands, how long until your analyst has the context to act?
This is a real bottleneck. Not just the detection latency - the time it takes the on-call analyst to figure out whether the affected resource is production, who owns it, what depends on it, and what breaks if they contain. If that's measured in hours, your architecture isn't ready. In a CD/CR architecture grounded in a Security Context Graph, this is measured in seconds because the answers are already structured. The graph answered the question before the analyst asked it.
3. What percentage of your team’s time goes to reactive triage versus proactive work?
Most enterprise SOCs run 80 percent or more reactive - alert chasing, ticket grinding, status reporting. The proactive 20 percent - hunting, detection engineering, purple team work, threat modeling - is what actually compounds. Every vendor in this market claims workload reduction. This is how you actually test the claim. Measure the ratio before a pilot, measure it after. If the proactive share doesn't grow, the tool is processing alerts but not changing how your team spends its time. The Gartner AI SOC evaluation work gets at the same thing when it frames Tier 1/Tier 2 reduction as a success metric, but ratio of proactive time is sharper because it captures what the freed time actually becomes. In a CD/CR architecture the ratio shifts because the reactive work gets absorbed by the loop - investigations close themselves with reasoning attached, detections tune themselves before the SOC sees them, context assembles before the analyst asks for it. Humans move up the value chain. If your humans aren't moving up the value chain after a year, the architecture is wrong.
4. Of your closed investigations in the last twelve months, how many produced a new detection, collecting missing logs, adding prevention mechanisms, a refined playbook, or a process change?
This is the test of whether your SOC is a learning system or a ticket-closing machine. Most SOCs close investigations and the knowledge dies in a Jira ticket. The senior analyst's reasoning lives in their head until they leave. The recurring pattern across five similar incidents never compresses into a sharper detection. The exception that should have triggered a playbook update gets noted in a post-incident review nobody reads. Carson Zimmerman has questions in his framework about post-incident review satisfaction and procedure freshness - together they ask whether closing an investigation actually changes anything downstream. For most teams the honest answer is no, and the cost compounds invisibly: every new attacker pays the same price the last one paid, because the lesson never made it into the system. CD/CR closes this loop. The Security Context Graph holds the reasoning. Compression turns recurring investigation patterns into new detections automatically. Stale exceptions and aging procedures surface for retirement. If your investigations produce reusable artifacts, the next attacker pays for the last one. If they don't, you're paying the cost of every investigation twice - once when it happens, and again every time something similar happens that you could have already detected earlier or prevent from even happening.
Where are we (the security community) going with this?
Everyone in security operations is going to face a choice in the next months: keep scaling the existing game, or build for a different one. Mythos is the writing on the wall. We have a narrow window before its capabilities are commoditized and the incident volume reflects it.
The SOC leaders I talk to are mostly in two camps. The first is trying to scale the existing game - more analysts, more tools, more automation bolted onto the same architecture. The second is starting to ask whether the architecture itself needs to change. I think the second camp is correct. The first camp is going to spend the next 18 months learning expensively that you can't optimize your way out of a math problem.
We need to bend the rules of the game so we don't have to lose it.
Continuous Detection, Continuous Response is what bending the rules looks like in architecture form. A body the system knows. Detection and response on one plane. Knowledge that flows between layers like an immune system instead of getting stuck in handoffs. A graph that holds the institutional memory of every incident your team has ever closed, so the next analyst starts where the last one finished.
If you want to talk about what this looks like in practice, I'm always open to a conversation.
