top of page
Search

Patching Vulnerabilities in the Age of Frontier AI

  • Aug 19
  • 15 min read

Dave Lanagan | Solutions Director | Automiq

Author:

Dave Lanagan

Solutions Director



Frontier AI is not creating a new category of cyber risk. For most enterprises it is an accelerant: it weaponises the technical debt organisations have tolerated for years, and it compresses the window between a vulnerability being disclosed and being exploited from weeks to days – and, increasingly, to hours.


The obstacle to keeping pace is rarely a shortage of scanning or orchestration tools. It is two structural gaps:


  • The first is an integrity gap in the data used to decide what to patch: siloed discovery tools and systems of record that never quite agree, reconciled by hand in spreadsheets before anyone can say with confidence how exposed the organisation really is.

  • The second is an architecture gap: application platforms that can only absorb change on a release cadence measured in weeks.


Close the first gap and automation finally acts on the truth rather than amplifying a fiction. Close the second and patching becomes a routine, reversible non-event rather than a negotiated maintenance window. Leave either open and the organisation is, by definition, slower than an automated adversary – and speed is now the whole game.


This paper sets out both gaps, explains why more tooling is rarely the answer, describes what a defensible target state looks like, and shows how Automiq helps enterprises get there – in most cases using tooling they already own.


Contents


Key facts at a glance


  • Time-to-exploit has collapsed. Mandiant’s average time-to-exploit fell from 63 days in 2018–19 to just 5 days in 2023, and exploits have been the number-one initial infection vector in its investigations for four years running. [1]

  • Known is not the same as fixed. Verizon’s 2024 report found the use of vulnerability exploitation to initiate a breach grew by roughly 180% year-on-year; CISA maintains a Known Exploited Vulnerabilities (KEV) catalogue precisely because disclosed flaws stay unpatched. [2] [3]

  • Frontier AI is an accelerant, not a new category. Models such as Mythos compress the disclosed-to-exploited window further and chain individual weaknesses into complete attack paths – weaponising tolerated technical debt.

  • The real attack surface is a data-integrity gap. Run CrowdStrike, Tenable, Tanium and Qualys across one estate and you will get four different pictures – none of which fully match your CMDB, Azure, Arc or VMware. Every patch decision taken before reconciliation is taken on partial information.

  • Automation amplifies whatever you feed it. Without a trustworthy asset foundation, orchestration simply does the wrong thing faster, and the vulnerabilities stay hidden behind pretty dashboards.

  • Your exposure window is set by your slowest-moving application, not your fastest-moving attacker.


The premise: Frontier AI weaponises technical debt

Every week another model gets better at finding weaknesses faster than humans can find them, let alone fix them. Much of the public attention focuses on AI reading code to discover individual exploits, but that is only one avenue – and arguably not the most consequential. The greater shift is the ability of these models to poke around an estate and link and sequence vulnerabilities into a complex attack path that delivers maximum exposure and damage.


This is why frontier AI raises the stakes rather than inventing a new category of risk. As we set out in our analysis of Mythos, such models compress the gap between “vulnerability disclosed” and “vulnerability exploited” from weeks to days, sometimes hours. Attackers no longer need to be elite. They just need their target to be slow.


The independent data already shows the direction of travel, well before frontier AI is factored in. Mandiant’s tracking of vulnerabilities exploited in the wild puts the average time-to-exploit at 63 days in 2018–19, 32 days across 2021–22, and just 5 days in 2023. Its blunt conclusion stating that “attackers are able to move quickly enough to beat patching cycles.” Exploits have been the single most common initial infection vector in its incident-response engagements for four consecutive years. [1]


Regulators and defenders have reached the same conclusion from the other direction. Verizon’s 2024 Data Breach Investigations Report found the exploitation of vulnerabilities as a route into a breach grew by roughly 180% in a single year, and the US Cybersecurity and Infrastructure Security Agency (CISA) maintains a Known Exploited Vulnerabilities (KEV) catalogue – with mandated remediation deadlines – precisely because a patch released is not the same as a patch applied. [2] [3]


To combat this, we need to fix some basics we are still getting wrong. AI will ruthlessly exploit the same weaknesses organisations have tolerated for years: unpatched servers, storage, networks, firewalls, load balancers, and the middleware sitting quietly beneath every application. The uncomfortable truth is that the attack surface is not just the vulnerability. It is the integrity of the information used to decide what gets fixed, the speed of analysis, and the speed of execution. This is becoming an hours problem, not a days-or-weeks problem.

The shift in one line: Mythos and other Frontier AI models don’t introduce a new weakness – they reduce the time you used to have to fix the weaknesses you already knew about.

The real attack surface is a data-integrity gap



Here is the part that makes most leaders uncomfortable: it is highly likely your organisation cannot tell you, with 100% confidence, where those gaps are. Not because the tools are absent, but because they are siloed, not integrated, not sanitised and not reconciled.


Run CrowdStrike, Tenable, Tanium and Qualys across the same estate and you will get four different pictures of what is actually out there. None of them will fully match what sits in your CMDB, Azure, Arc, SolarWinds or VMware as the “official” record. Each tool is doing its job; the problem is that no one view is authoritative, and no two agree.


Reconciling those views is not a five-minute job. It is weeks of manual, error-prone cross-referencing – generally with our constant companion, Microsoft Excel – before anyone can say with a straight face how exposed the organisation really is, or in what order that exposure should be fixed. And every patching decision made before that reconciliation happens is a decision made on partial information.

This is the real attack surface: not a technical vulnerability, but an integrity gap in the data organisations use to decide what to fix first. It is invisible on every dashboard, because every dashboard is confidently reporting a different version of the truth.

This is also why a dependency-aware view of the estate matters as much as an accurate inventory. Knowing a server is unpatched is necessary; knowing which business services that server underpins is what lets you fix in the right order. We explore that discipline in depth in our article on service mapping.


The middleware blind spot

Middleware compounds the problem in a different way. .NET, Apache, IIS and the rest of the application stack rarely get patched on an infrastructure cadence. They get patched on an application team’s cadence, which usually means “whenever it doesn’t collide with a release.”


That is a rational call for a product team focused on shipping features. It is a dangerous one for the organisation, because it quietly hands ownership of a critical security control to the team least incentivised to enforce it. The result is middleware sitting exposed for months – not because anyone decided that was acceptable risk, but because nobody with the authority to say no was actually in the loop.


Fixing this is less of a technology problem, and more of an accountability one. Middleware patching needs to sit under a security- and infrastructure-owned standard with a hard SLA, not a courtesy request to application teams. That requires revisiting the operating model and the accountabilities within it, alongside enhancements to testing and release processes and a genuine mindset change in the development functions. This step is critical, and not without some pain.


The other half: application architecture that absorbs change in hours

Even a perfectly reconciled asset picture will not get a critical .NET, Apache or IIS patch out this week if the application team’s answer is “we can’t patch that until the next release.” That mindset was reasonable when release cycles were quarterly and exploit timelines were measured in weeks. It became much harder to defend the moment frontier AI compressed those timelines to hours. The fix is not a policy memo or an SLA change alone – it is an architecture change.


Currency must be a property of the pipeline, not a project

Teams shipping daily cannot treat patches as a periodic remediation sprint. Automated dependency management wired directly into CI pipelines lets patch-level updates to frameworks, libraries and runtimes land as routine pull requests – tested and merged like any other code change. If currency at the point of deployment is not the default, every release ships technical debt by design.


Automated testing is a security capability, not a delivery nicety

None of that is trustworthy without automated testing doing the real work. A patch that can only be validated by a human regression cycle is a patch that waits for the next scheduled cycle. Comprehensive automated unit, integration and security-regression suites – run in CI on every patch commit – are what let a team say yes to an emergency patch in hours instead of negotiating a maintenance window, with synthetic monitoring after deployment closing the loop. Too often, automated testing is treated as a delivery optimisation rather than a security capability, and board-level security discussions overlook one of the most important enablers of rapid remediation.


Architecture must assume continuous change

At the speed modern organisations need to operate, occasional failures are inevitable. The goal is not to eliminate them; it is to make deployments safe, reversible and operationally routine, so that patching becomes a non-event for availability and security teams no longer have to negotiate every critical update.


The capabilities to do this very likely exist in your environment today – but are usually reserved for a small subset of key applications:


  • Blue-green environments – fully patch the idle environment, run automated smoke tests against it, then cut traffic over at the load balancer. Rollback is instant: flip back.

  • Canary releases – route a small percentage of traffic to the patched instances, watch error rates and latency, and widen the rollout progressively, catching a bad patch before it reaches everyone.

  • Immutable infrastructure – never patch a running server or container in place; build a new image with the patch baked in and replace the old one. This removes config drift and turns “patching” into “deploying” – something the team already does daily.

  • Rolling updates with health and readiness probes – patch nodes or pods a batch at a time, with the orchestrator automatically pulling a batch out of rotation if health checks fail.

  • Feature flags and dark launches – decouple shipping a patched build from exposing new behaviour to users, so runtime and security patches can go out continuously without waiting on product readiness.

  • Connection draining and graceful shutdown – patch a node only once the load balancer has stopped routing it new traffic and in-flight requests have completed – the difference between a patch and an outage.


None of this is exotic, and in mature platform teams it already exists somewhere in the toolkit. What is missing is treating it as a patching capability rather than a deployment nicety. If application architecture can only tolerate patching on a monthly release train, the organisation’s exposure window is set by its slowest-moving application, not its fastest-moving attacker.

The two halves are one problem: infrastructure that can accurately identify what is exposed, and application platforms that can safely absorb change in hours. Fix one without the other and you are still too slow where it counts.

Why more automation alone will not save you

The market has responded to all this with a generation of highly advanced workflow-automation and orchestration platforms. They are genuinely capable. But their efficacy depends entirely on the data they are fed, and from where. Without clean data and proper integrations, your automation simply does the wrong thing faster, and the vulnerabilities remain concealed behind attractive dashboards.


This is the trap frontier AI springs. An organisation still spending its patch cycle manually reconciling four asset inventories before it can even prioritise is, by definition, slow. Automation layered on top of an untrustworthy asset foundation does not close that gap – it just adds speed to the wrong side of the equation.


The fix is therefore not even more orchestration tooling. In our experience, the capability already exists somewhere in most organisations’ tooling ecosystems. The fix is threefold:


  1. Reconcile vulnerability and discovery data against the systems of record as a standing discipline, not a one-off project

  2. Put middleware patching back under a security-owned standard with a hard SLA

  3. Treat asset-data integrity as the prerequisite for automation, not something automation will eventually get around to fixing on its own.


A word of caution on tooling...

Do not jump straight for the first home-grown tool your MSP offers as a silver bullet. Existing tools may do the job well enough with little effort – and retaining control of your workflows in-house, rather than locking them into a third party, is usually the stronger long-term position.


Why this is an opportunity, not just a threat

It would be easy to read all of this as another reason for fatalism. We see it differently. For years, the business case for the unglamorous work – integrating and reconciling asset data, retiring technical debt, putting middleware under proper ownership, modernising release architecture – has been hard to make on its own. The risk was understood and quietly accepted, and the spend never quite stacked up against more visible priorities.


Frontier AI changes that calculus. It makes the cost of tolerated technical debt concrete, urgent and, importantly, fundable. The reframing is powerful: rather than an open-ended security tax, this becomes a time-boxed opportunity to establish a single source of asset truth, close longstanding gaps, and emerge with an operation that is faster, cheaper to run and materially more resilient.

The organisations that seize this window – rather than doing the minimum – will not just weather the AI-enabled era; they will run better because of it.

What good looks like: a target state

A defensible target state for rapid remediation has a small number of non-negotiable characteristics:


  • A single, reconciled source of asset truth. Discovery and vulnerability data (CrowdStrike, Tenable, Tanium, Qualys) is integrated bi-directionally with the systems of record (CMDB, Azure, Arc, VMware) through a reconciliation engine, with enforced naming and tagging standards so duplication is designed out, not cleaned up after the fact.

  • Reconciliation as a standing discipline. The asset picture is kept current continuously, not rebuilt in a spreadsheet each quarter – with AI used to accelerate the clean-up to a compliant baseline as well as to maintain it.

  • Middleware under a security-owned standard. Patching of .NET, Apache, IIS and the wider stack is governed by a hard SLA owned by security and infrastructure, not left to release convenience.

  • Currency built into the pipeline. Dependency updates arrive as routine, automatically tested pull requests, so releases ship current by default.

  • Deployment patterns that make patching a non-event. Blue-green, canary, immutable infrastructure, rolling updates and feature flags are treated as patching capabilities and extended beyond a handful of flagship applications.

  • Automation on a trustworthy foundation, with control retained. Orchestration acts on reconciled data, using tooling the organisation already owns and controls wherever possible.


The acid test...

if a critical vulnerability were disclosed this afternoon, could you identify every affected system accurately by tonight, and safely patch the most exposed of them by tomorrow? If the honest answer is “not in hours”, the gap is now a live exposure, not a future project.


How Automiq can help

Getting on the front foot is less about buying access to the newest capability and more about doing the fundamentals exceptionally well, at pace – usually with tooling you already own. Our work maps directly onto the two halves of the problem.


1. Establish a single, reconciled source of asset truth

We drive bi-directional integration of data sources and a strong reconciliation engine, using AI to assist not only in the end result but in the clean-up activity that gets you to a compliant baseline faster. Careful mapping of the ecosystem – understanding metadata, and where to apply uni- versus bi-directional data flows – is critical to getting this right, alongside enforced naming and tagging standards.


2. Put ownership and process where the risk is

We help revise the accountabilities and operating model to drive appropriate security focus – bringing middleware patching under a security-owned standard – and redesign the testing and release processes (and the development mindset) needed to support currency by default.


3. Automate on a trustworthy foundation – and keep control

Orchestration and automation matter, but look carefully at your existing tooling ecosystem before buying more. Existing tools often do the job with little additional effort, and keeping workflows in-house avoids lock-in to third parties.


4. Underpinning the programme


The bottom line

Frontier AI is not waiting for organisations to get their data, or their mode of operation, right. It is already compressing the time between disclosure and exploitation to a point where manual reconciliation and release-cadence patching are simply too slow.


The good news is that the fix is largely within reach today. It is not another orchestration platform. It is the discipline of reconciling asset truth as standing practice, the accountability to own middleware patching properly, and the architecture to make patching a routine, reversible non-event. Get those three right and automation finally works for you rather than against you.


The attacker only needs you to be slow. Rapid remediation is not a tooling purchase – it is accurate asset data and application architecture that can absorb change in hours. Frontier AI isn’t waiting. Neither should you.


Frequently asked questions


How has frontier AI changed the patching problem?

It has compressed timelines. Independent data already shows the average time-to-exploit falling from around 63 days (2018–19) to 5 days (2023); frontier AI pushes this further and chains individual weaknesses into full attack paths. Patching cadences designed for a weeks-long window are now too slow. [1]


Isn’t this just a case of buying better vulnerability-management or orchestration tools?

Usually not. Most organisations already own capable tooling. The binding constraints are the integrity of the asset data those tools act on, and the ability of application platforms to absorb change quickly. Automation on top of unreconciled data just does the wrong thing faster.


What is the “data-integrity gap” in patching?

It is the gap between what your discovery and vulnerability tools report and what your systems of record hold. Different scanners produce different asset pictures, none of which fully agree with ServiceNow, Azure, Arc or VMware. Until those views are reconciled, every prioritisation decision is made on partial information.


Why is middleware patching such a blind spot?

Because .NET, Apache, IIS and similar components are typically patched on the application team’s release cadence rather than an infrastructure one. That hands a critical security control to the team least incentivised to enforce it, and middleware can sit exposed for months by default rather than by decision.


What does “currency as a property of the pipeline” mean?

It means dependency and runtime updates flow through CI as routine, automatically tested pull requests, so software ships current by default – rather than treating patching as a separate, periodic remediation project that always competes with feature work.


Do we need to replace our tooling to fix this?

Rarely. The capabilities usually already exist somewhere in the estate. The value is in integrating and reconciling them, assigning clear ownership, and extending safe-deployment patterns beyond a few flagship applications – and in resisting the urge to lock critical workflows into a third party’s bespoke tool.


What is a KEV, and how does it differ from a CVE?

A CVE (Common Vulnerabilities and Exposures) is a unique reference number assigned to a publicly disclosed vulnerability – it confirms a weakness exists, not that anyone is using it. A KEV (Known Exploited Vulnerability) is a CVE that CISA has confirmed is being actively exploited in the wild; its Known Exploited Vulnerabilities catalogue carries mandated remediation deadlines and is widely used as a de facto prioritisation benchmark. Every KEV started life as a CVE, but only a small fraction of CVEs ever become one – which is exactly why exploitation status, not just disclosure, should drive patching priority.


Which CMDB and asset-management platforms are affected by the data-integrity gap?

The gap is platform-agnostic. It shows up wherever discovery and vulnerability-scanning tools – CrowdStrike, Tenable, Tanium, Qualys – are reconciled CMDB and asset inventories such as ServiceNow, BMC Helix, Freshworks, Azure, Arc, VMware, and many others. Any CMDB or asset-of-record platform is exposed if its data is not integrated bi-directionally with the scanners generating vulnerability findings; the risk sits in the reconciliation process, not in any single vendor's product.


What is Mythos, and why does it matter for patching?

Mythos is one of the frontier AI models referenced throughout this paper as an accelerant to vulnerability exploitation. It can read code, probe an estate, and chain individual weaknesses into a complete attack path far faster than a human analyst. It does not invent a new category of risk; it compresses the time an organisation has to fix the weaknesses it already knew about. We cover this in more depth in our dedicated analysis of Mythos.

 

How quickly should an organisation be able to patch a critical vulnerability today?

Fast enough to close the gap frontier AI has opened: identify every affected system accurately within hours of disclosure, and safely patch the most exposed of them within a day. That is the target-state test set out in this paper – if the honest answer is “not in hours”, the exposure is already live, not a future project.


Sources & further reading


Automiq logo light
bottom of page