The AI Vulnerability Wave: What Every CISO Needs to Tell the Board Right Now
Anthropic's Project Glasswing found 10,000+ critical vulnerabilities in open source in a single month. The NCSC has warned of a forced correction of technical debt. What this means for board risk posture, vendor expectations, and patch SLAs that are already obsolete.
On 1 May, the NCSC published an advisory titled “Preparing for a vulnerability patch wave.” On 22 May, Anthropic released the first update from Project Glasswing, its AI-assisted vulnerability research programme: more than 10,000 high- or critical-severity vulnerabilities found in systemically important open source projects. In one month. With only 97 patched.
If you have not yet briefed your board on the structural implications of this shift, now is the time. The AI vulnerability wave is not a future risk. It is a present one — and the risk posture most organisations have been maintaining is calibrated to a world that no longer exists.
The Structural Shift
Vulnerability discovery has historically been the bottleneck in the security pipeline. Finding bugs is hard. Skilled researchers are scarce. The result was a predictable, manageable flow of disclosures that security teams could absorb within their existing processes.
AI changes this equation. Claude Mythos, the unreleased model underpinning Glasswing, and equivalent models from other labs can now find software vulnerabilities at a rate that far exceeds human capacity. The bottleneck has shifted from discovery to remediation.
Patching has always required human judgement: verifying findings, writing fixes, testing for regressions, coordinating with maintainers, distributing through package registries, and waiting for downstream adoption. None of those steps have been accelerated by AI in any meaningful way yet. The result is a widening gap between how fast vulnerabilities are being found and how fast they can be fixed.
Mandiant’s M-Trends 2026 report adds urgency from the other side: 28.3% of disclosed CVEs are now exploited within 24 hours of publication. That figure was under 10% five years ago. The window in which a patch can reduce risk before exploitation has compressed — in some cases to zero.
What This Means for Your Board Conversation
Existing patch SLAs are already obsolete
Most organisations operate patch SLAs calibrated to historical disclosure volumes — critical vulnerabilities within 7–14 days, high within 30. Those SLAs assumed a manageable inflow. The inflow is changing by an order of magnitude.
Your board needs to understand that these SLAs will not be achievable for a growing proportion of CVEs, and that acknowledging this is not a failure of the security function — it is an honest assessment of a structural change in the external environment. The honest question to answer is not “are we meeting our SLAs?” but “what is our actual risk exposure given the gap between disclosure volume and remediation capacity?”
Compensating controls now carry more weight
The practical implication of a narrowing patch window is that compensating controls — network segmentation, least-privilege access, anomaly detection, application allowlisting — are no longer just alternatives to patching. They are the risk reduction that happens in the window before patching is possible, and for some categories of systems, the window that never closes.
Boards that have been viewing compensating controls as secondary options should be reframed toward treating them as primary risk reduction for any asset where timely patching cannot be guaranteed. That is an investment argument as much as a security argument.
Legacy systems face a materially different risk calculus
Systems that cannot be patched — industrial controllers, embedded devices, end-of-life enterprise software — have always carried residual risk. That risk was historically manageable because exploitation rates were low and discovery was slow. Both assumptions are being revised simultaneously.
Boards and audit committees that have been tolerating known unpatched systems because historical exploitation rates appeared acceptable should expect that tolerance to be challenged as AI lowers the cost of both finding and exploiting vulnerabilities in those systems. This is the moment to surface legacy exposure that has previously been deferred.
Vendor risk assessments need updating
If your critical software suppliers’ patch SLAs were set before 2026, they were calibrated against a disclosure environment that no longer exists. The question to ask in every vendor risk review is not “what is your patch SLA?” but “how are you managing a sustained increase in disclosure volume — and what is your strategy for the Glasswing-class programmes that will continue to run?”
Suppliers who cannot answer that question should be flagged. Suppliers who are updating their processes in response should be noted as positive differentiators.
The Immediate Priorities
The NCSC’s practical recommendations in the May advisory were deliberately achievable: reduce internet-facing attack surface, enable automatic updating where possible, and begin transitioning away from end-of-life systems that cannot be patched to vendor support. These are sound starting points.
For CISOs briefing boards, the framing matters. The NCSC presented this as a project to complete. The more accurate framing for governance purposes is that the vulnerability landscape has permanently changed — and risk posture needs to change with it, not as a one-time remediation effort but as a sustained shift in how risk is measured, reported, and managed.
The organisations that adapt their risk posture now — increasing compensating controls, reducing legacy exposure, and revising vendor expectations — will be materially better positioned than those that treat this as a temporary spike. The wave has arrived. The question is whether your risk appetite is calibrated to it.