Patch Tuesday
Project Glasswing: End of the 30-Day Patch Cycle
On 7 April 2026, Anthropic announced Project Glasswing. The headline numbers are easy to quote and hard to absorb. A single AI model uncovered thousands of zero-day vulnerabilities, a 27-year-old bug in OpenBSD and a 16-year-old flaw in FFmpeg. Twelve of the world’s largest technology companies, including Microsoft, Google, Apple, AWS, CrowdStrike and Palo Alto Networks, signed up as participants. The programme committed a hundred million dollars and attached a coordinated 90-day disclosure policy to every finding.
Read past the announcement and the implication cuts sharper than any of those numbers. For three decades, most of the security industry assumed that attackers and defenders roughly tracked each other. Someone discovered a vulnerability, someone wrote a patch, an advisory shipped, and enterprises closed the gap inside a 30-day window. That loop has broken. Discovery is now industrialised, and the gap between a flaw becoming known and a working exploit appearing in the wild has collapsed from months to hours.
The assumption the patch cycle was built on
Calendar-based patching rests on a quiet assumption: that new vulnerabilities surface slowly enough for a monthly rhythm to cope. Patch Tuesday, quarterly Java releases, scheduled Adobe updates - a predictable cadence shaped the entire operational model of enterprise application management. Packaging teams plan work a month ahead. Change-advisory boards meet weekly. Teams rebuild SCCM collections, test them and roll them out over a controlled window. None of that was inefficient. It matched the landscape.
Glasswing dismantles that assumption. An AI model that surfaces thousands of flaws across every major operating system and browser, continuously, does not arrive in monthly batches. It produces a steady stream of findings, each paired with a 90-day countdown. Some flaws will sit in widely deployed third-party applications that most portfolio owners cannot name with confidence. Others will sit in legacy code untouched for a decade. All of them will be public knowledge long before most enterprises finish analysing the first.
What Project Glasswing exposes in the average application estate
Most large organisations carry an uncomfortable gap between what they believe they have deployed and what actually runs on their endpoints. Portfolios drift. Old versions linger. Shadow installs propagate through user-initiated MSIs, bundled suites and silent auto-updates. Security teams relying on CVE feeds keyed to product names have tolerated that drift, because the feeds themselves moved at a pace that forgave imprecision.
That tolerance is gone. When CVE data must map not to “Adobe Acrobat” but to “Adobe Acrobat 23.006.20320 installed on 4,200 endpoints,” imprecision becomes exposure. A vulnerability discovered on Monday and exploited on Wednesday will not wait for an inventory refresh.
Three specific problems come into focus.
Legacy applications carry the worst of the risk. The longer a codebase goes unreviewed, the more attractive it becomes to an AI scanner. The oldest findings in the Glasswing announcement - the 27-year-old OpenBSD flaw, the 16-year FFmpeg bug - preview what this looks like across the long tail of enterprise software. Accounting packages, plant-floor control applications, bespoke internal tools: the applications hardest to repackage are where the worst findings will surface.
Insurance is already repricing. Cyber insurers have spent eighteen months modelling AI-assisted attack economics. Glasswing gives them a structured event to anchor new exclusions around. Expect policies renewed through the rest of 2026 to name AI-discovered vulnerabilities explicitly and tie coverage to defined remediation windows.
Regulators will follow. “Reasonable care” has always been a moving target, calibrated against what the competent operator was doing at the time. Glasswing resets that baseline. An enterprise that cannot demonstrate an event-driven remediation capability in twelve months will find the burden of proof has shifted.
The infrastructure gap
Most estates cannot respond at the speed the new landscape demands, and the reason is structural rather than cultural. SCCM, for all its strengths, was designed for predictable cadence. Its distribution model, its collection hierarchies, its reliance on planned maintenance windows - all of it assumes the work arriving is known a week in advance. Moving a package from discovery to production inside 24 hours is possible, but it remains the exception, not the pattern.
Intune, by contrast, assumes that packages land in the estate within minutes. Assignment groups react to membership changes in near real time. Detection rules drive state reconciliation without manual intervention. The difference matters because rapid remediation is not a packaging problem - it is a delivery problem, and the delivery tier is where most enterprises are slowest today.
Migrating to Intune has, until now, been a five-year modernisation project that most organisations have deferred. Glasswing reframes it as a security prerequisite.
What continuous remediation actually looks like
The practical shift is from calendar-driven to event-driven. A new CVE affecting an application in the portfolio no longer queues for the next patching window; it triggers a defined workflow with an SLA attached. Critical findings move from analysis through packaging, QA and delivery inside 24 to 48 hours. Lower-severity findings run through the same pipeline on a longer SLA. The pipeline itself runs continuously, not in scheduled batches.
Four capabilities underpin that shift. The first is portfolio accuracy: a complete, versioned inventory that overlays against live CVE and KEV data without a three-week reconciliation. The second is deep package analysis, so that a rapid patch does not break a production deployment. The third is an automated path from packaged MSI or MSIX into the Intune estate, with detection rules and close-apps logic intact. The fourth is continuous monitoring, so that drift surfaces while correction is still cheap.
None of these capabilities are new in isolation. What is new is the requirement to run all four continuously, at a pace the packaging and QA functions in most enterprises have never been asked to sustain.
A practical starting point
The organisations that weather the next twelve months well will treat vulnerability response not as a monthly event but as a production line. That line begins with knowing the portfolio in detail, ends with tested packages arriving in Intune, and runs continuously in between.
A Glasswing Readiness Assessment is the baseline. The focused review covers the current portfolio inventory, a CVE and KEV overlay against the versions actually installed, a risk-prioritised remediation roadmap, and an Intune migration readiness score. The output is a clear picture of where the estate stands against the new baseline and a concrete plan for reaching continuous remediation speed.
Preparation time is short. The first 90-day disclosure deadlines from the Glasswing cohort will land before most enterprises finish their next planning cycle. The useful question for the week ahead is not whether to respond, but whether today’s pipeline can move a critical patch from discovery to deployment inside 48 hours. For most estates, answering that honestly is the first step.
Greg Lambert is CEO of Application Readiness. To schedule a Glasswing Readiness Assessment, contact greg.lambert@applicationreadiness.com.