When finding bugs gets cheap, fixing becomes the bottleneck

Artificial intelligence (AI) systems find real vulnerabilities in old, heavily tested code, as our review of zero-days found by AI records. A bug that is cheap to find is cheap for everyone to find, so what decides risk is how long a flaw stays exploitable once someone has found it. That time is spent getting a fix onto machines, and this post looks at where it goes and how to cut it.

First principles

The exposure window of a vulnerability runs from the moment anyone discovers it to the moment the fix is running on every affected machine. Two parts of that definition matter.

The start is set by the first finder, not by you. If an attacker finds the bug first, the window opens before the vendor knows. Defenders can only shorten what follows.

The end is set by the last machine, not by the vendor. A fix in a source repository protects no one. Neither does a release nobody has installed.

Between those two points, a fix passes through six stages:

1. Triage. Reproduce the report, decide whether it is real, reachable and new, and rate it.
2. Fix. Write a change that removes the flaw without breaking anything.
3. Review and test. Check the change, because a bad update can do more damage than the bug.
4. Release. Put the fix in a version users can install.
5. Distribution. Carry it through every layer that repackages the code: libraries that bundle it, frameworks, operating system (OS) vendors, device makers.
6. Deployment. Install and activate it on each machine, which often means a restart.

Each stage is a queue. Three things follow when discovery gets cheap.

Queues grow. If a project receives 15 valid security reports a week and can close 10, its backlog grows by 5 a week and the wait for any one report has no ceiling. Cheaper discovery raises the arrival rate at the first stage without raising the service rate of any stage.

Rediscovery becomes likely. When a bug takes an agent an afternoon to find instead of an expert a month, several parties find the same one. Our earlier review documents several finders converging on the same flaws. The assumption that nobody else knows stops being safe while a fix is in progress.

A fix becomes a map. Once a fix is public, as a commit or as a binary that can be compared with the last version, it shows where the bug was. Until deployment, the flaw is known and users are exposed; a bug exploited then is called an n-day. Google Threat Intelligence Group (GTIG) has suggested that attackers may already use models to compare versions and patches to build n-day exploits faster.

So when discovery was expensive, risk was dominated by how long bugs stayed unfound, and few had an open window at all. When discovery is cheap, many windows are open at once, their length is set by the stages after discovery, and the slowest stage sets the pace.

Where the time goes

Shipping a fix takes weeks to months. Project Zero, Google’s vulnerability research team, gives vendors 90 days to fix what it reports, and 7 days when a bug is already being exploited. From 2019 to 2021, 93.4% of the 376 issues it reported were fixed. The average time from report to a shipped fix fell from 67 days in 2019 to 52 in 2021. Linux averaged 25 days over the period, Microsoft 83 and Oracle 109. The author noted that the sample is small and that Project Zero reports may get faster treatment than most.

Release often takes longer than the fix. The same analysis split browser timelines. Chrome took 5.3 days on average to land a public patch, then 24.6 days to ship it. WebKit took 11.6 days, then 61.1. Firefox deliberately delays committing security patches so that less is public before the release, which deals with the map problem at the release stage.

Distribution can take months. In 2022 Project Zero reported five bugs in the Arm Mali graphics processing unit (GPU) driver. Arm fixed them in July and August. In November, Project Zero wrote that the fixes had not reached downstream devices, including Pixel, Samsung, Xiaomi and Oppo phones, and that its own test devices were still vulnerable. It calls this delay the upstream patch gap, and in 2025 began a trial of naming the vendor and product about a week after each report so downstream projects can watch for the fix.

Deep dependencies take years. When the Log4j flaw appeared in December 2021, Google’s Open Source Insights team found 35,863 Maven Central artifacts depending on the affected code (a later correction, counting only the affected core package, gave over 17,000). For over 80% the dependency was more than one level deep, and each level needs its own fix and release. After less than a week, about 13% were fixed. Across earlier critical Maven advisories, only 48% of affected artifacts had ever been fixed.

Exploitation has moved earlier. Mandiant, part of Google, measures the average time from a patch’s release to first exploitation, which goes negative when attackers act before a patch exists. It was 63 days in 2018 and 2019, 32 in 2021 and 2022, and 5 in 2023 after excluding 15 outliers (47 with them). In 2023, 70% of the exploited vulnerabilities it tracked were used before any patch existed.

The fix itself is rarely the long pole. Release, distribution and deployment are, and in those stages the flaw is most likely to be public. Natalie Silvanovich of Project Zero puts it plainly: “Most vendors’ patch speed is limited by the testing and delivery stages.”

What shortens each stage

Triage: prove it, then rank it. A report that comes with an input that reproduces the bug is cheap to confirm. Reachability analysis then asks whether your code can call the vulnerable function at all. Go’s govulncheck reports a vulnerability only when your code transitively calls an affected function. A 2026 study of 34 million npm package versions found 68.28% of the impacts flagged by package-level analysis were noise, because the vulnerable code was never reached. A Vulnerability Exploitability eXchange (VEX) document is an attestation of whether a product is affected by a known vulnerability, so each customer does not redo that work.

Exploitation evidence ranks what is left. From 2021 to 2026, the Cybersecurity and Infrastructure Security Agency (CISA) gave United States federal agencies two weeks to fix flaws in its Known Exploited Vulnerabilities (KEV) catalog, or six months if the Common Vulnerabilities and Exposures (CVE) identifier was assigned before 2021. Its replacement, Binding Operational Directive (BOD) 26-04, sets deadlines from four questions: is the asset publicly exposed, is the flaw in KEV, can exploitation be automated, and does it give an attacker total control.

Fix and review: let models draft, keep people reviewing. Google DeepMind’s CodeMender upstreamed 72 security fixes to open-source projects in its first six months, each reviewed by a person before submission. Review is where cheaper fixing meets its limit: a team now hosted by the Open Source Security Foundation (OpenSSF) reviewed 630 AI-generated patches by hand and found 20 to 40% semantically wrong even though they passed all automated validation. Memory-safe code helps here too: Android reported in 2025 that, for medium and large changes, Rust is rolled back about four times less often than C++, and that Rust changes spend about 25% less time in code review.

Release: give security fixes their own clock. A monthly or quarterly bundle sets a floor on the window. Project Zero lists four ways to act faster in an emergency: feature flags that switch off a vulnerable path (Apple disabled Group FaceTime in 2019), filters on untrusted input, alternate update channels, and hotpatching. Each has to exist before the emergency.

Distribution: know what you ship, and make parts separately updatable. A software bill of materials (SBOM), which CISA describes as a nested inventory of the components in a product, turns the question of whether you are affected into a lookup instead of a search. Android’s Mainline lets some system components update through Google Play system updates, outside the normal Android release cycle. For upstream code, take whole releases: the Linux kernel’s documentation recommends taking all released stable changes, which are tested together, rather than cherry-picking fixes.

Deployment: default to automatic, remove the restart. Windows hotpatch updates install and take effect without a restart, with planned restarts only for quarterly baseline updates. Linux Livepatch replaces kernel functions in memory, though patches that change a structure shared between functions are sometimes not supported. Apple’s Background Security Improvements ship fixes for components such as Safari, WebKit and other system libraries between full releases, if the device is set to install them automatically. The Chrome team says the wait for a user to restart can be a significant contributor to n-day risk, and has made the browser restart itself on macOS when an update is pending and no windows are open.

Have less to fix. Code you do not ship, or do not expose, needs no patch, so disabling unused features and listeners is the cheapest fix there is. Memory-safe languages remove the bug class behind most of the AI-found vulnerabilities in our earlier review. Vulnerabilities decay with code age: from measured vulnerability lifetimes, Google estimates that five-year-old code has 3.4 to 7.4 times lower vulnerability density than new code. It ties the fall in the memory-safety share of Android vulnerabilities, from 76% in 2019 to 24% so far in 2024, to writing new code in memory-safe languages. Its conclusion is to stop adding unsafe code first.

A case from our own code

Troy, our Chromium browser that agents attach to over the Chrome DevTools Protocol (CDP), shows the distribution problem at small scale. It is built on Electron, which bundles Chromium. A Chromium security fix reaches a Troy user in four hops: Chromium ships it, Electron ships it in a supported release line, we rebuild and publish Troy, and the user installs it.

Electron ships a major version every eight weeks and supports the latest three. The oldest supported line gets security fixes only, and Electron’s guidance is to move to each new major version as quickly as possible. The last hop is ours, and it is manual: Troy has no auto-update. Users update through Homebrew or by hand; auto-update is planned, not built. Troy works inside the user’s signed-in session, so that hop matters most. Each layer can be quick and the total still slow.

The strongest counterargument

The case against this framing is that speed is the wrong target. Very few vulnerabilities are ever exploited (figures below). Rushing every fix spends scarce review time on bugs nobody would have used. Fast updates carry their own risk: in July 2024 one faulty CrowdStrike update affected 8.5 million Windows devices. Project Zero notes that testing exists to prevent bricked devices, and that any loss of function after a security update makes users less likely to install the next one. Cheap discovery also works before release: GTIG argues that standard pre-release AI code review could slow the growth in public disclosures, and a bug found before shipping has no exposure window at all.

This is right, and it changes the advice rather than overturning it. The goal is not to make every stage fast for every bug. It is to make the pipeline fast for the small set that is reachable, exposed and likely to be used, and to make deployment automatic so that speed does not depend on a person at each machine. Pre-release scanning shrinks future windows. It does nothing for code already deployed, which is where AI systems are finding bugs that are often more than a decade old.

What to do

1. Measure the window by stage. Record when each report arrived, was triaged, fixed, released, and what share of installs had it after 1, 7 and 30 days.
2. Triage on evidence. Require a reproducer, check reachability, rank by exposure, known exploitation, automation and impact, and publish VEX statements for flaws that do not affect you.
3. Separate security releases from feature releases and build an emergency path, such as a feature flag or a separately updatable component, before you need it.
4. Track what you bundle. If you ship Chromium, Electron, a kernel or a vendored library, subscribe to its security releases and set yourself a deadline to ship each one.
5. Make updates automatic by default and design for no restart, or a quiet one. Turn on hotpatching where it is offered.
6. Review AI-written patches as you would any other.
7. Shrink and change the code. Remove unused features and public exposure, and write new parsers of untrusted input in memory-safe languages.
8. After patching an exposed system, check for compromise. BOD 26-04 pairs some three-day cases with a forensic check for compromise, since a patch closes the hole but does not remove an attacker already inside.

As of 2026-10-25

What we could not verify

• BOD 26-04’s full table. The directive’s timeline table is an image. CISA’s text confirms the three-day tier and deferral. The 14-day and 60-day tiers come from an AI-assisted Cloud Security Alliance note and vendor summaries, which disagree on which cases need forensic triage.
• The Verizon figures. We could not open Verizon’s Data Breach Investigations Report itself. Verizon’s page confirms vulnerabilities as the leading way into breaches; the 43-day and 26% figures come from Help Net Security’s report of it.
• The minus 7 days. M-Trends gives no method on its public page, so we cannot say how outliers were handled. They moved Mandiant’s 2023 figure from 47 days to 5.
• Exploitation counts. GTIG and VulnCheck count only exploitation someone observed and reported.

Sources

Project Zero: Emergency patching, A walk through Project Zero metrics, Disclosure policy, Mind the gap, Reporting transparency.

Exploitation timing: Mandiant time-to-exploit 2023, M-Trends 2026, GTIG trends in the AI era, VulnCheck first half 2026, Verizon Data Breach Investigations Report, Help Net Security on the report, Anthropic disclosure dashboard.

Policy: BOD 22-01, BOD 26-04, Patch smarter, not harder, Cloud Security Alliance note, CISA SBOM.

Release and deployment: Chrome security, Firefox two-week cycle, Firefox calendar, Electron timelines, Electron schedule, Electron security, Windows hotpatch, Apple Background Security Improvements, Android Mainline, Linux kernel CVEs, CrowdStrike outage.

Dependencies and reachability: Log4j impact, govulncheck, npm reachability study, 2026.

Velofy: Troy documentation, Troy source.

Fixing and memory safety: CodeMender, OpenSSF on AI patches, Android memory safety 2024, Rust in Android 2025.

← All journal entries