The AI Exploit Gap: Why Patch Speed Is Engineering’s Problem

The AI exploit gap is the distance between a vulnerability becoming known and a fix reaching production, and engineering teams control most of it. Michael Hill makes that case in a recent article, and this piece extends one claim from it: leaders should agree a deadline for critical patches before the next exploit arrives.

The AI exploit gap is a delivery problem that security cannot close alone

Hill reports on a survey commissioned by Chainguard and run by Wakefield Research. It asked 1,300 security leaders at director level or above, at companies with 500 or more employees, about AI-driven threats. Of those leaders, 77% expect an attacker to exploit a software vulnerability at their organization within 12 months, and 54% say their companies knowingly leave high or critical vulnerabilities unpatched at least sometimes. The rate is 66% at companies with $1 billion or more in revenue and 27% at companies under $250 million. Larger companies cite disruption to operations (48%) and revenue-generating work taking priority (46%). Smaller companies cite difficulty testing patches (59%).

Hill concludes that fixing vulnerabilities is now the bottleneck, and that tools alone do not close the gap. Of the leaders surveyed, 39% have bought tools they have not rolled out, and among the 22% who rate their tools very effective, 77% still expect an exploit this year. His summary is "Security sees the risk. Engineering owns the fix." He suggests leaders ask how long a critical patch takes to reach production and who decides when it jumps the roadmap.

Disclosure-to-exploit windows have shrunk from months to days

Hill’s question about how long a patch takes matters because the time available to answer it has been falling. Mandiant published an analysis on the Google Cloud blog on 15 October 2024 covering 138 vulnerabilities disclosed in 2023 that it tracked as exploited in the wild. The average time from disclosure to first exploitation was 63 days in 2018 and 2019, 44 days from 2020 to the start of 2021, 32 days in 2021 and 2022, and 5 days in 2023. The 5-day figure excludes 15 outliers. With them included, the 2023 average is 47 days. The authors call their figures conservative, because first exploitation dates are often undisclosed or vague.

The data has limits that matter for this argument. It covers only vulnerabilities known to be exploited, and 97 of the 138 were exploited as zero-days, before a patch existed. A faster patch process cannot help with those. The patch queue matters for the 41 n-day cases. The authors also write that the 2023 shift appears to be influenced more by increased zero-day use and detection than by a drop in n-day use. I found no primary dataset showing that AI shortens these windows. The AI link in this piece rests on a forecast: the Chainguard release reports that more than half of respondents expect AI-powered vulnerability discovery to routinely outpace their teams within a year. Nobody has measured that yet in the sources I checked.

A patch clock agreed in advance beats a faster patch process

CISA offers a design to borrow. It maintains the Known Exploited Vulnerabilities catalog, which it describes as the authoritative source of vulnerabilities that have been exploited in the wild, and it strongly recommends that all organizations prioritize the listed vulnerabilities. Under Binding Operational Directive 22-01, federal civilian agencies must remediate them within prescribed timeframes. Other organizations are not bound by the directive, and CISA encourages them to adopt the same practice. The design has three parts: a trigger that is defined in advance, a deadline attached to the trigger, and no ticket-by-ticket negotiation on the day.

A private company can copy that shape. I call it a patch clock, and the name is mine. First, leaders agree which classes of vulnerability start the clock, for example a flaw on a public exploited-vulnerability list or a flaw on an internet-facing system. Second, each class gets a maximum number of days from fix available to fix in production. Third, one named executive may pre-empt roadmap work when a clock runs out, and every override is logged. Each quarter the engineering leader reports the median and the slowest time to production for each class.

This answers both of the obstacles Hill reports. Revenue work taking priority is settled by a rule agreed before the pressure arrives. Difficulty testing patches becomes a funded project, an automated test suite for the upgrade path, with a clear business reason behind it.

A patch clock has limits that leaders should state up front

The survey is self-reported by security leaders and was commissioned by Chainguard, so its numbers describe what respondents say, and Hill cautions that it cannot show cause. Disruption is a real cost. Nearly half of the large-company respondents cite it, and a rushed patch can break production, so each clock needs a tested rollback path. A clock attached to every vulnerability would flood teams and teach them to ignore it, so the triggers need to stay narrow. Some fixes do not exist yet, which is why the 47% of respondents cutting third-party dependencies are working on the right problem: fewer dependencies means fewer items in the queue.

Why This Matters for Engineering Leadership

Today the decision to leave a known critical vulnerability unpatched is usually made by backlog order, and nobody signs it. Fifty-four percent of surveyed security leaders say their companies do this knowingly at least sometimes. From an AI governance view, a known exposure with no named owner and no deadline is an accountability gap. A patch clock turns an implicit choice into a recorded one. Leaders can start with three questions: how many days a critical patch takes to reach production today, who may move it ahead of roadmap work, and where that decision is written down.

FAQ