A group of the most credible voices in cybersecurity just published a document that deserves your full attention.

The “AI Vulnerability Storm” briefing, authored by contributors including the CISO of Google, the former Director of CISA, the former Cybersecurity Director of the NSA, and the CEO of SANS, is not a vendor whitepaper or a think piece. It’s a coordinated warning from practitioners who collectively have more signal on where this is heading than almost anyone else on the planet. When this group agrees on something, it’s worth treating that consensus seriously.

The trigger for the briefing is Anthropic’s Claude Mythos. Mythos is an AI system that autonomously discovered thousands of zero-day vulnerabilities across every major operating system and browser, generated working exploits without human guidance, and did it at a speed and scale that has no precedent. Anthropic responded by standing up Project Glasswing, coordinating early access to Mythos for critical infrastructure providers and open source maintainers so they could patch before disclosure. The authors describe it as possibly the largest multi-party vulnerability coordination effort in history.

But here’s the part that matters for your organisation: Project Glasswing can only cover so much. The attack surface it can’t reach is vastly larger than what any curated partner programme can realistically address, and most software teams (including yours) will not have early access to Mythos-class capabilities.

Meanwhile, comparable offensive tools will proliferate. The briefing estimates that similar capabilities will be available in open-weight models within six to 12 months of the Mythos announcement. When that happens, those tools will be accessible to anyone.

The briefing was produced by the Cloud Security Alliance CISO Community alongside SANS, the [un]prompted conference, and the OWASP Gen AI Security Project, with observations from an unusually heavyweight list of practitioners. It is available in full on the CSA’s website and is worth reading directly if you want the complete risk register, priority action tables, and board-level talking points. What follows is our read of the key implications for SaaS businesses, specifically the parts of the briefing we think deserve the most attention from technical leaders in this space.

Why SaaS Teams Are Particularly Exposed

The open source software that your SaaS products are built on (your frameworks, your dependencies, your runtime environments) is exactly the surface area that AI vulnerability discovery tools are already being pointed at. This is not a future concern.

By February 2026, Anthropic’s own research using Claude Opus 4.6 had already reported over 500 high-severity vulnerabilities in open source software. AISLE found 12 OpenSSL zero-days, including a CVSS 9.8 flaw that had existed, undetected, since 1998. The Linux kernel went from two vulnerability reports per week to ten. The curl project, which had previously shut down its bug bounty because it was drowning in hallucinated AI-generated reports, has reversed course, and an increasing share of the reports it now receives are verified, high-quality findings.

That last detail is important. The noise-to-signal problem in AI-assisted vulnerability research is resolving in the wrong direction for defenders, meaning that the findings are getting real. The Zero Day Clock, launched by Sergej Epp at the [un]prompted conference in March, visualises what this means in practice. Time-to-exploit (being the gap between CVE disclosure and confirmed exploitation) has collapsed from years to hours. In 2026 it is now under one day, and this trajectory is not levelling off.

For SaaS businesses, this has a specific implication: the patch window you have historically relied on may no longer exist in any meaningful sense. A vulnerability in a library you depend on could be discovered, weaponised, and exploited before a patch is even available, let alone deployed. The briefing describes this as “a permanent acceleration, not a temporary spike.”

This Is Accurate, Not Alarmist

The authors are careful to draw a distinction worth repeating. The Zero Day Clock trend is a leading indicator of where attacker capability is heading, i.e. it is not yet a direct measure of current damage levels at scale. The most consequential incidents of recent years have still largely involved credential abuse, social engineering, and supply chain compromise rather than zero-day exploitation, and that context does matter.

But the direction is unambiguous, and the practitioners warning about it have been consistently ahead of the curve. In September 2025, Google’s CISO Heather Adkins and Knostic’s Gadi Evron published a warning that autonomous vulnerability discovery and exploitation was roughly six months away. Within that window, the first AI-orchestrated espionage campaign was disclosed; a Chinese state-sponsored group using Claude Code to autonomously run full attack chains from reconnaissance through exfiltration across approximately 30 global targets.

These are not just thought experiments, they are documented events that have already occurred. The question the briefing is asking organisations to answer is not whether this threat is real, it is how far behind they are willing to be when Mythos-level offensive tools become broadly accessible.

What the Briefing Is Actually Recommending

The authors organise their recommendations across three time horizons, and the immediate actions are specific. A few are particularly relevant to SaaS teams.

The most pressing is turning AI vulnerability discovery inward on your own code. The briefing frames this as a priority action starting ‘this week’. The point is straightforward: the same tools that will be used against you can be used by you first. Running LLM-assisted security review against your codebase and CI/CD pipeline before an adversary does is now a realistic, accessible capability, not a theoretical one. Anthropic’s Claude Code Security and OpenAI’s Codex Security both launched in March. Knostic’s OpenAnt is available open source, including free scans for open source projects.

Alongside that, the briefing recommends taking dependency management seriously in a way most teams have not had to before. Every third-party library in your stack is now a surface that AI can scan at scale for vulnerabilities you have not (yet) found. Generating real Software Bills of Materials, aggressively retiring unmaintained dependencies, and tightening your software supply chain are not abstract governance exercises, they directly reduce the area that can be targeted.

The briefing also pushes hard on the basics: network segmentation, egress filtering, phishing-resistant MFA, and Zero Trust architecture. The reasoning is sound because these controls do not depend on knowing which vulnerabilities will be found. They limit what an attacker can do after a successful exploit. When exploit frequency increases, blast radius containment becomes even more valuable, not less.

The longer-horizon recommendation that will take more planning is what the authors call a VulnOps function; a permanent capability for continuous vulnerability discovery and remediation, staffed and automated in the way DevOps is. For most SaaS businesses this is not something you build in a week, but it is the direction the briefing says there is no long-term alternative to. Regular pen tests and reactive patching cycles were designed for a world where critical CVEs arrived in dozens per month, not hundreds.

The Y2K Comparison Is Intentional

The briefing makes a direct comparison to Y2K, and it is worth sitting with rather than dismissing. Y2K is often treated retrospectively as an overblown panic, but the actual lesson from that episode is that the threat was real and the coordinated, disciplined response was precisely why it did not become a catastrophe. The infrastructure did not fix itself, people mobilised, prioritised, and worked through it methodically before the deadline hit.

The authors are suggesting that this moment has the same character. The difference is that the deadline is not a fixed date on a calendar. The window is the time between now and when Mythos-class offensive tools become broadly accessible to a much larger population of threat actors, including criminal groups who currently lack nation-state resources but will not much longer.

That window is not years, it is likely months.

Where to Start

For a technical leader at a SaaS company reading this, the practical question is where to focus first. The report’s own answer is to work through a short triage of your actual security programme state, we’re not talking policy documents, but ground truth. Can you get a security-driven production change deployed in days rather than weeks? Are your critical dependencies actually tracked and current? Is there a real security gate between code change and production? Do you know how to escalate urgently with your key third parties?

The answers to those questions tell you where your highest-leverage starting points are.

The honest position for most SaaS businesses is that they are not yet in a posture to absorb what is coming without significant uplift. That is not a cause for panic, but it is a cause for prioritisation. Understanding your actual exposure, starting to use AI-assisted scanning against your own codebase, and revisiting your patching and dependency management practices are all things that can start now.

The briefing ends with a line worth noting: “Building a Mythos-ready security programme is not about reacting to one model or announcement. It is about permanently closing the gap between how fast vulnerabilities are found and how fast your organisation can respond”.

That gap is closing from the wrong direction, and the organisations that come out of this period in reasonable shape will be the ones that started closing it from their end before they had to. If you want to understand what your current exposure looks like, or start thinking through how pen testing and continuous assurance fit into a Mythos-ready posture, that’s a conversation we’re well placed to have.