Anthropic confirmed what researchers have been saying for the last year or more: AI will allow the world to find zero days and exploit them faster than ever before. Mythos isn’t new in concept but made this a concern that we can’t ignore. SANS, the Cloud Security Alliance, [un]prompted, and the OWASP GenAI Security Project responded with an emergency strategy briefing, “The AI Vulnerability Storm: Building a Mythos-Ready Security Program,” built by 60+ contributors and reviewed by 250+ CISOs in a single weekend — a full breakdown of that briefing is here. Their conclusion: organizations must stand up a permanent VulnOps function within 12 months. Now Google has confirmed in its May 2026 threat intelligence report that this isn’t theoretical. Adversaries are already using AI to discover and weaponize zero-day vulnerabilities in the wild. The cat is out of the bag, and the attacks are not coming. They are here.
The Old Vulnerability Management Playbook Is Dead
For most organizations, vulnerability management has followed the same cycle for years. A scanner runs on a schedule. Findings get dumped into a ticketing system. A team reviews the backlog, prioritizes by CVSS score, and schedules patches during the next maintenance window. From scan to patch, the process takes days. Often weeks.
That model was built for a world where finding a critical zero-day required significant human expertise and time. That world no longer exists.
When an AI system can autonomously discover and validate a remote code execution flaw in FreeBSD in the time it takes your team to finish a morning standup, the concept of a weekly patching cycle becomes a liability. The attackers are not waiting for your change management process.
What Anthropic’s Claude Mythos Actually Did
Anthropic’s Mythos Preview found thousands of high-severity zero-day vulnerabilities in every major operating system and web browser. Many were more than a decade old. The oldest confirmed so far was a 27-year-old bug in OpenBSD, now patched (which might have been a copy paste from old code, but regardless it was there).
In one documented case, Mythos fully autonomously identified a 17-year-old remote code execution vulnerability in FreeBSD that allows root access on any machine running NFS. In another, it chained four separate vulnerabilities together to write a browser exploit capable of escaping both the renderer and OS sandbox.
Anthropic is not releasing the model to the public. Instead, they created Project Glasswing and are working with a small group of organizations, including AWS, Apple, Cisco, CrowdStrike, Google, Microsoft, and the Linux Foundation, to coordinate responsible disclosure and patching. Over 99% of the vulnerabilities discovered have not yet been patched.
Here is the part that makes this real for all of us: if Anthropic built this, other actors are working on the same capability. The disclosure is a grace period, not a guarantee. The pressure now falls entirely on defenders.
The numbers make this concrete. According to the Zero Day Clock, the mean time from vulnerability disclosure to confirmed exploitation has fallen to less than one day in 2026, down from 2.3 years in 2019. The SANS briefing frames this as a permanent acceleration, not a temporary spike. Every new AI model that ships raises the floor for what attackers can do with any vulnerability in your stack.
What VulnOps Is (and Why It’s Different)
VulnOps is not just a new name for DevSecOps. The term was introduced in October 2025 by Heather Adkins, Gadi Evron, and Bruce Schneier in a CSO essay arguing that vulnerability management needs to become a permanent, dedicated organizational capability, not a feature of other programs.
The distinction matters. DevSecOps is about embedding security into the development pipeline. VulnOps is about what happens after code ships: continuous detection, continuous triage, and continuous remediation at a speed that matches the threat environment.
Think of it this way: DevSecOps prevents vulnerabilities from being introduced. VulnOps deals with the ones that exist anyway, whether they were introduced today or seventeen years ago, and makes sure they get fixed before an adversary finds them first.
In a post-Mythos world, VulnOps is not a best practice. It is a survival requirement.
The Attacks Are Already Happening
For anyone still treating AI-driven exploitation as a future threat, Google’s Threat Intelligence Group published a report in May 2026 that closes that debate. For the first time, GTIG confirmed a threat actor used a zero-day exploit they assess was developed with AI. A criminal group had planned a mass exploitation event. Google’s proactive counter-discovery may have prevented it from executing.
That is not the full picture. State-sponsored actors from China and North Korea are using AI systematically for vulnerability research, feeding specialized datasets of historical vulnerability cases into models to steer them toward semantic logic flaws that traditional scanners miss entirely. APT45 sent thousands of repetitive prompts to recursively analyze CVEs and validate proof-of-concept exploits, building an arsenal at a scale that would be unmanageable without AI assistance. Frontier LLMs are particularly effective at identifying this class of flaw because they reason about developer intent, not just syntax, which means they surface vulnerabilities that look correct to static analysis tools but are strategically broken from a security standpoint.
On the malware side, Google documented active use of AI to generate polymorphic code that evades static detection, autonomous Android backdoors that navigate device interfaces and execute commands without human operators, and supply chain attacks targeting AI infrastructure directly. A threat actor compromised LiteLLM, a widely used AI gateway library, and used it to extract API keys and cloud secrets from build environments. Ransomware groups were among the buyers. Google also documented adversaries using AI to build anonymization networks and rotate command-and-control infrastructure dynamically to stay ahead of defenders.
The threat is no longer “AI could do this.” It is “AI is doing this.” The organizations building VulnOps capability now are building it in a threat environment where their adversaries already have the tools and are already using them.
Why Traditional Vulnerability Management Can’t Keep Up
The core problem with traditional vulnerability management is that it was designed around human throughput. Humans review findings. Humans prioritize tickets. Humans schedule and apply patches. Every one of those steps introduces delay, and delay is now the attacker’s best friend.
Three specific failure modes define the old model:
• Static prioritization: CVSS scores are useful but they do not reflect real-world exploitability. A critical-rated vulnerability in a system that is not internet-facing is less urgent than a medium-rated one in a public-facing API. Teams that prioritize by score alone burn time on the wrong things.
• Backlog accumulation: Most organizations have vulnerability backlogs that number in the thousands or millions. No human team can triage, validate, and remediate at that scale. The backlog grows faster than it shrinks, and AI is accelerating that.
• Patch lag: Even after a vulnerability is prioritized, getting a patch into production takes time. Change management processes, testing cycles, and maintenance windows add days or weeks. In a machine-speed threat environment, that lag is exploitable.
The Mythos disclosure makes each of these problems more acute. If thousands of previously unknown zero-days can be discovered autonomously, the backlog problem gets dramatically worse overnight. And if exploitation can be automated at the same speed as discovery, patch lag is no longer just a risk: it is a breach waiting to happen.
The Core Pillars of a VulnOps Program
Building a VulnOps capability means rethinking vulnerability management from the ground up around four core pillars:
1. Continuous Detection
Periodic scanning is not enough. A VulnOps program requires continuous visibility into your attack surface, including assets that traditional scanners miss: serverless functions, containers, APIs, and third-party dependencies. Detection needs to happen in real time, not on a weekly schedule.
2. AI-Driven Triage
Automated vulnerability management means using AI to triage findings at scale, not just sort by CVSS. Effective triage considers exploitability, asset criticality, network exposure, and existing compensating controls. The goal is to surface the twenty vulnerabilities that actually need patching today, not the twenty thousand that technically exist.
3. Automated Remediation
This is the hardest part, and the most important. Machine-speed remediation requires code-driven infrastructure. If you cannot deploy a patch through an automated pipeline without a human approving each step, you cannot remediate at machine speed. Infrastructure as Code is not optional here. It is the foundation.
This is also where rollback capability becomes critical. Automated patches will sometimes break things, especially at first. The same pipeline that applies a fix must be able to reverse it instantly if something goes wrong. Speed without rollback is just a different kind of risk.
4. Metrics That Reflect Reality
Mean time to detect (MTTD) and mean time to remediate (MTTR) need to be measured in hours, not weeks. If your organization cannot answer those questions accurately right now, that is the first problem to solve. You cannot improve what you cannot measure.
How to Start Building Your VulnOps Capability
You do not build VulnOps overnight. But you can start moving toward it immediately. Here is a realistic starting point:
Audit your current pipeline honestly. Time your actual scan-to-patch cycle for a representative sample of vulnerabilities. Not the best case: the median. The number will probably be uncomfortable.
Invest in Infrastructure as Code. Automated remediation requires automated deployment. If your infrastructure is not code-driven, that is the foundational work. There are no shortcuts.
Choose AI-native tools, not legacy tools with AI stickers. A traditional scanner that added an AI dashboard is not the same as a tool designed from the ground up for machine-speed triage and remediation.
Start with a limited scope. Pick one product line, one cloud environment, or one application stack. Build the capability there, prove it works, then expand. Trying to boil the ocean first is how VulnOps initiatives stall.
Treat VulnOps as a permanent team function, not a project. The Cloud Security Alliance research that emerged in the wake of Mythos is clear on this: VulnOps needs to be a standing organizational capability with dedicated resources and leadership ownership.
The organizations that respond to Mythos by doubling down on their existing processes will be in exactly the same position in twelve months, except the threat environment will be worse. The organizations that use this moment to rethink how vulnerability management works will be meaningfully more defensible.
The Bottom Line
Claude Mythos did not create the vulnerability problem. It revealed that the gap between how fast attackers can operate and how fast defenders can respond is wider than most organizations assumed, and that it is closing in the wrong direction.
VulnOps, built on continuous detection, AI-driven triage, automated remediation, and instant rollback, is the response that matches the threat. It is not a replacement for good security fundamentals. It is what good security fundamentals look like when the adversary operates at machine speed.
If you are building a strategy to address the Mythos era, the SANS emergency briefing offers a blunt starting point: point AI agents at your own code this week. Not next quarter. Not after the governance framework gets approved. This week. The longest-horizon priority in the briefing is standing up a permanent VulnOps function within 12 months, fully staffed and automated for continuous AI-driven discovery across your entire software estate. Between this week and that 12-month mark is where your program either gets built or does not.
Frequently Asked Questions
What is VulnOps?
VulnOps, short for Vulnerability Operations, is an organizational capability focused on continuous vulnerability detection, triage, and remediation. The term was coined by Heather Adkins, Gadi Evron, and Bruce Schneier in 2025 to describe a dedicated, permanent function distinct from general DevSecOps practices.
How is VulnOps different from DevSecOps?
DevSecOps embeds security into the software development lifecycle to prevent vulnerabilities from being introduced in the first place. VulnOps focuses on vulnerabilities that already exist, including in third-party software, legacy systems, and code written before modern security practices existed. The two are complementary, not competing.
What does machine-speed vulnerability remediation mean?
Machine-speed remediation means applying patches and fixes through automated pipelines without requiring human approval at each step. It requires code-driven infrastructure (Infrastructure as Code), AI-driven triage to identify which vulnerabilities to prioritize, and the ability to roll back changes automatically if something goes wrong.
How did Claude Mythos change vulnerability management?
Claude Mythos, Anthropic’s AI model released in preview form in early 2026, demonstrated that AI can autonomously discover and validate thousands of zero-day vulnerabilities across major operating systems and browsers. It compressed a capability that previously required significant human expertise into an automated process, which means both defenders and attackers now have access to AI-driven vulnerability discovery tools. The defender response has to match that pace.
How long should it take to patch a critical vulnerability?
In a mature VulnOps program, the goal is to detect and begin remediating critical vulnerabilities within hours of discovery, not days or weeks. The specific target depends on the nature of the vulnerability and the organization’s risk tolerance, but the industry benchmark is shifting from 30-day SLAs toward same-day or next-day remediation for the highest-severity findings.
