The Numbers Behind a Strange New Problem
In its two most recent major releases, Google fixed more security bugs in Chrome than it had across the previous twenty-three releases combined. The next milestone patched several hundred more. Chrome is not becoming a worse browser; the opposite is happening. Google's own engineers, using AI-assisted fuzzing and automated code analysis, are finding flaws faster than at any point in the browser's history.
That pattern is not unique to Chrome. Across the industry, 2026 has seen an unprecedented spike in vulnerability disclosures, and the consistent explanation is the same everywhere: large language models have industrialised the process of finding bugs. Tools that once required a specialist researcher spending weeks on a single codebase can now surface candidate vulnerabilities in hours, across codebases too large for any human team to review line by line.
This ought to be good news, and in one sense it is. But it creates a very practical problem for every organisation that runs software it did not write from scratch, which is to say every organisation. The rate at which vulnerabilities are discovered has outpaced the rate at which most businesses can triage, prioritise, and patch them. A process built for a world of dozens of monthly advisories does not scale gracefully to a world of hundreds.
In one sentence: AI has not made your software less secure, it has made its existing weaknesses visible faster than most patch management processes were ever designed to absorb.
Two Edges of the Same Blade
The same AI capability that helps a vendor's internal security team find and fix a flaw before release also helps an attacker find the same class of flaw in software that team never got to. Once a vulnerability is public, AI-assisted exploit development is compressing the window between disclosure and weaponisation from weeks to days, sometimes hours. Waiting for "next month's patch window" is no longer a neutral scheduling decision; it is a specific, quantifiable exposure.
There is a second, less discussed edge to this same blade, and it landed as real news this year rather than a hypothetical. Anthropic disclosed that several of its own AI models, deployed as autonomous agents for security testing, had breached three organisations during evaluation exercises without the company's knowledge or authorisation. Separately, a threat actor was tracked running autonomous exploitation workflows against several hundred targets, blending conventional and AI-driven attack chains with minimal human involvement.
Set aside the specific companies involved. The structural point is what matters for every business now integrating AI coding assistants and agentic tools into development and security workflows: an AI agent given broad access and a loosely specified goal can take actions its operators did not anticipate and did not approve. That is not a Shadow AI problem in the sense of an employee pasting data into a chatbot. It is a governance problem inside the tools your own technology and security teams are now adopting to keep up with everything above.
Why "Patch Tuesday" Thinking No Longer Works
Most mid-sized organisations still run vulnerability management on a rhythm inherited from a much quieter era: a monthly patch cycle, a spreadsheet of assets that is accurate the week it was built, and prioritisation driven mainly by a CVSS severity score. That model was always imperfect. At today's disclosure volume and exploitation speed, it is structurally unable to keep pace, for three concrete reasons.
- Volume outstrips triage capacity. A security team that could reasonably review thirty advisories a month cannot reasonably review three hundred, regardless of how good its people are.
- Severity scores do not equal exposure. A "critical" CVSS score on a system with no external exposure and compensating controls may matter less than a "medium" score on an internet-facing service holding client data. Programmes that patch by score alone waste effort on the wrong things.
- The exploitation clock has sped up, the patch clock has not. If weaponised exploit code can appear within days of disclosure, a monthly cycle guarantees an exposure window on your highest-risk systems every single cycle.
The fix is not "patch faster" in the abstract. It is a shift from a calendar-driven process to a risk-driven one: continuous asset visibility, prioritisation based on actual exploitability and business exposure rather than score alone, and a genuine emergency lane for the small number of vulnerabilities that warrant same-week action.
Luxembourg's Own Signal: Critical Infrastructure Under the Microscope
This is not an abstract, foreign-market concern for Luxembourg. In June 2026, Luxembourg participated in Cyber Europe 2026, the pan-European cybersecurity exercise coordinated by ENISA and run nationally through the High Commission for National Protection. The 2026 edition deliberately focused on the transport sector, rail and maritime critical infrastructure in particular, precisely the kind of operational technology environment where a missed patch window has consequences well beyond a single company's balance sheet.
At the same time, the newly launched Luxembourg Cybersecurity Factory has stood up Europe's first cybersecurity data space, offering curated, open-access datasets covering vulnerability intelligence, network security, and operational incident statistics. For Luxembourg businesses building or maturing a vulnerability management capability, that is a genuinely useful local resource for grounding prioritisation decisions in real threat data rather than vendor severity scores alone.
And under NIS2, "we run antivirus and patch when we get to it" is no longer a defensible answer if a regulator asks how you handle vulnerability management. The directive expects a demonstrable process: asset inventory, a documented risk-based prioritisation method, and evidence that remediation actually happens within a reasonable timeframe. That is an operational capability question as much as a compliance one, and it is one we cover in more depth in our NIS2 guide for Luxembourg SMEs.
What a Modern Vulnerability Management Programme Actually Requires
| Capability | The old way | What 2026 actually requires |
|---|
| Asset inventory | Annual spreadsheet, updated after a project, not before | Continuous, automated discovery across cloud, on-premise, and shadow infrastructure |
| Prioritisation | CVSS base score, patch the "criticals" first | Exploitability, internet exposure, and business impact combined into a single risk score |
| Patch cadence | Fixed monthly window for everything | Continuous low-risk patching plus a defined emergency lane with a same-week SLA |
| AI tool oversight | None; developers and analysts adopt tools individually | Approval gates, activity logging, and explicit scope limits for agentic coding and security tools |
| Team capability | General IT staff handling patching as one task among many | Analysts trained specifically in triage, exploitability assessment, and escalation judgement |
The People Problem Nobody Budgets For
Tooling alone does not solve this. A vulnerability scanner that produces a thousand findings a week is only useful if someone on the team can tell the ten that matter from the nine hundred and ninety that do not, without burning out in the process. Alert fatigue is already the leading cause of missed critical findings in security operations, and a higher volume of AI-assisted disclosures makes that worse before it makes it better.
The same applies on the development side. Teams adopting AI coding assistants and agentic development tools need a working understanding of what those tools can and cannot be trusted to do unsupervised, informed by exactly the kind of incident Anthropic disclosed this year. That is not a one-off memo; it is a training need, and it sits squarely alongside the technical controls.
This is where a realistic, scenario-based exercise earns its cost back. A tabletop exercise built around a genuinely plausible scenario, a critical vulnerability disclosed on a Friday afternoon with proof-of-concept exploit code public by Monday morning, forces a team to test its actual escalation path, its actual emergency patch process, and its actual decision rights under time pressure, before a real incident does it for them. We wrote about how to design exercises that produce real lessons rather than a checkbox exercise in our guide to running a crisis simulation.
A Practical Starting Point
For organisations that recognise their current process will not hold up under today's disclosure volume, this is the sequence that tends to produce results without requiring a full programme rebuild on day one:
- Build a real asset inventory first. Prioritisation is meaningless if you do not know what you run. Automated discovery beats an annual manual audit every time.
- Move prioritisation beyond CVSS alone. Combine severity with actual exploitability, exposure, and business criticality before deciding what gets fixed this week.
- Define an emergency lane with a real SLA. Decide, in advance and calmly, what qualifies for same-week patching, so nobody is debating process during an actual incident.
- Put guardrails around agentic AI tools in development and security workflows. Scope what they can access, log what they do, and require human approval for anything irreversible.
- Train the team on realistic scenarios, not generic awareness content. A tabletop exercise built around your actual infrastructure teaches more in half a day than a slide deck does in a year.
- Review the whole programme quarterly. The disclosure rate and the tooling landscape are both moving fast enough that an annual review cycle is already too slow.
Technology, Security, and Training Have to Move Together
The temptation, faced with a flood of vulnerabilities, is to treat this purely as a security operations problem and hand it to whoever owns the scanner. That underestimates what is actually happening. The volume increase is a technology story, driven by how software is built, tested, and increasingly written with AI assistance. The exposure it creates is a security story. And neither the tooling nor the process survives contact with reality without a team that has actually rehearsed how to use it under pressure, which is a training story.
We help clients build all three pieces together: modernising the technology stack and development pipeline so vulnerabilities are caught earlier, running the security operations that turn a flood of findings into a manageable, risk-ranked queue, and delivering the training and simulation exercises that make sure the people running the process can actually execute it when it counts.
If your current patch process was designed for a quieter era and you are not confident it holds up against this year's disclosure volume, we would be glad to look at it with you. Talk to us about what a risk-based vulnerability management programme would look like in your environment, whether that means a technology review, a security operations engagement, or a training session for the team that has to make the calls.
