필사 모드: How AI Found Two Years' Worth of Chrome Bugs in a Single Month — Reading the Number 1,072 Correctly

• Introduction — 1,072 vs. 1,036
• A Lineage — From 2023's Fuzz Target Generation to 2026's Agent Harness
• Why, of All Things, Memory-Safety Bugs in a Massive C++ Codebase
• What This Number Tells Us — and What It Doesn't
• The Bottleneck Has Moved from Discovery to Deployment
• What Teams Without Chrome's Scale Can Actually Copy
• Conclusion — Finding a Lot Means It Was There the Whole Time
• References

Introduction — 1,072 vs. 1,036

On July 30, 2026, Google published a security blog post titled Stronger with every update. Two numbers anchor it. Chrome 149 and 150, the two milestones released in June, fixed 1,072 security bugs. The 23 milestones over the two years before that fixed 1,036.

One of those fixes closed a sandbox escape that let a compromised renderer trick the browser into reading local files — a bug that had lived in the codebase for more than 13 years. Doug Turner, Chrome's engineering director, told TechCrunch that the team is "applying models like Gemini to proactively fix vulnerabilities and stay ahead of attackers."

Numbers like this tend to provoke two wrong reactions: taking them at face value and concluding "AI solved security," or dismissing them as marketing. Neither leaves you with anything usable. This post tries to do three things instead — lay out the mechanism that's actually running, separate what this number does and doesn't say about code quality, and identify what a team without Chrome's scale can actually copy.

A Lineage — From 2023's Fuzz Target Generation to 2026's Agent Harness

This result didn't appear out of nowhere; it's four years of accumulation. Following the order laid out in Google's own post:

2023, writing fuzz targets. Chrome's security team starts using LLMs to widen fuzzing coverage. The idea is simple: fuzzing's yield is determined not by the fuzzer but by the harness, and hand-writing harnesses is tedious and different for every project — so hand it to an LLM. The public results from OSS-Fuzz are concrete: applied across more than 300 C/C++ projects, coverage grew 30 percent, more than 370,000 new lines were covered across 272 projects, and 26 bugs turned up that could not have been found without the LLM-generated targets. One of them was OpenSSL's CVE-2024-9143, an out-of-bounds read/write that had survived hundreds of thousands of hours of fuzzing over 20 years.

The loop at this stage is publicly documented as four steps, and it's directly reusable: write a draft harness, compile it and have the model fix compile errors, run it and fix runtime issues, and keep it running while the model triages the crashes.

2024, Naptime. Together with Project Zero, the effort shifts toward handing an LLM the tools of vulnerability research — a debugger, a code browser, an execution environment. This is the "read the code and reason about it" side.

2025, Big Sleep. A collaboration between DeepMind and Project Zero that actually finds bugs in the V8 JavaScript engine and the graphics stack.

Early 2026, the Gemini agent harness. A harness goes in that sweeps the entire Chrome codebase while focusing on cutting false positives. The design described in the announcement is worth noting: it analyzes code in a purely static state, runs on an isolated machine with the internet blocked, and intercepts network requests through a strict allowlist. The model's non-determinism is offset by scanning the same codebase multiple times, and the entire history of past CVEs and git commits is attached as a knowledge base so the model can reference "what bugs in this project have tended to look like." A separate critic agent, working in its own context, then evaluates the findings.

What happens after discovery is automated too. Triage runs in four stages: filter out spam and duplicates to confirm security relevance, reproduce with a proof of concept, fill in metadata like introduction point and severity, and auto-assign to the owning component's owner. The fix stage also runs a loop where a fixer agent and a critic agent mimic code review, and a test-writing agent attaches cross-platform tests before a developer ever reviews the change. Google estimates that triage automation alone saved hundreds of developer-hours per month, while itself noting the caveat that "this is difficult to measure precisely."

Why, of All Things, Memory-Safety Bugs in a Massive C++ Codebase

To judge whether this result is reproducible, you have to look at the nature of the problem itself. Hunting for memory-safety bugs happens to have four conditions that are unusually favorable to LLMs.

First, the verdict is mechanical. When a crash report comes out of a binary instrumented with ASan, MSan, UBSan, or LeakSanitizer, that's an indisputable bug. No human judgment is required. This matters decisively because the biggest weakness of LLM-based automation is self-grading its own output. A sanitizer is a judge that sits outside the model, and no amount of plausible-sounding argument from the model can change the verdict.

Second, reproduction cases are cheap. In fuzzing, the evidence for a bug is a single byte string. It can be saved, minimized automatically, and attached as-is as a regression test. There's no need to narrate a logic bug's "when a specific account made a specific request in a specific order at a specific time."

Third, the shape of the bug is local and repetitive. A missing bounds check, a use-after-free, a type confusion — these are patterns identifiable within a handful of lines of code. And Chrome has 20 years of CVE and commit history, meaning training material for "what bugs of this class tend to look like in this project" is already accumulated. That's why Google fed the entire history of past CVEs and git commits into the knowledge base.

Fourth, the attack surface is enormous. Chrome parses every kind of untrusted input the world produces — images, fonts, video codecs, network protocols, JavaScript. More parsers means more surface where fuzzing pays off.

The flip side is that the same approach doesn't work nearly as well in domains lacking these four conditions. Missing authorization checks, business-rule violations, race conditions of the kind sanitizers can't catch, design-level flaws — none of these have a machine oracle. So reading this announcement as "AI automated security" is wrong. The accurate sentence is: the cost of search collapsed for the classes of vulnerability a machine can grade.

What This Number Tells Us — and What It Doesn't

1,072 is a real number, and it means something. Every bug found and fixed is one less foothold left for an attacker. But we need to be precise about what this number is actually a metric of. It is a discovery-rate metric, not a defect-density metric.

The right column of this table lines up almost exactly with the criticism raised in the Hacker News discussion. The most repeated question was "how many of the auto-generated fixes got reverted, and how many introduced new bugs" — one comment summarized the announcement as counting "everything that went right and nothing that could go wrong." No Chrome team engineer replied in that thread.

I want to add one more methodological caution of my own. The unit of comparison is the milestone, and the length of a milestone is changing. The 23 milestones over the prior two years ran on roughly a monthly cadence; June alone produced two. And in the very same announcement, Google said it's moving major releases to a two-week cadence, shipping weekly security updates, and piloting security releases twice a week. As releases get more frequent, the denominator behind "fixes per milestone" keeps shifting. A time-series comparison needs a figure normalized per unit time, and that figure isn't in the announcement.

And the single most important interpretation: finding a lot of bugs means those bugs were there the whole time. The 13-year-old sandbox escape is the proof. This announcement isn't evidence that Chrome's code got better in June — it's closer to evidence of how much we had failed to find until now. And the same tools are available to attackers, too.

The Bottleneck Has Moved from Discovery to Deployment

The most useful part of this announcement for practitioners isn't actually the number 1,072 — it's what Google changed next.

When the cost of finding vulnerabilities drops, the bottleneck immediately shifts downstream. Discovery speed outpaces fix speed, and fix speed outpaces deployment speed. In Chrome, it takes weeks for a fix to flow from the main tree to the stable branch. If discovery gets 10x faster but this stretch stays the same, the moment users actually get protected barely moves.

That's why Google's response is concentrated on the release pipeline — shortening the major cadence to two weeks, weekly security updates, piloting twice-weekly security releases, automating CVE and release-note generation (which tells you human hands were the bottleneck there), and researching dynamic patching that swaps background processes without a full restart. Google itself flags that last item as still being at the research stage.

Structural defenses keep advancing in parallel: the spanification effort, under which 97 percent of first-party Chrome code now compiles with strict unsafe-buffer warnings on; checked math applied to allocation calculations; heap partitioning that separates pointers from non-pointers; MiraclePtr and MiracleObject, which neutralize use-after-free; and a plan to selectively deploy Rust in high-bug-density areas like parsers, codecs, and fonts. There's one sentence here that Google states plainly: runtime mitigations are expected to hit diminishing returns within a few years. Which is why the shift toward language-level solutions is underway.

What Teams Without Chrome's Scale Can Actually Copy

You can't imitate Google's resources, but there are pieces of this pipeline that are cheap and portable. The order matters.

1. Sanitizers come before LLMs. The precondition for all of this is a machine oracle. If you have a C/C++ project, adding an ASan and UBSan build to CI comes before attaching any AI tool. Bolt an agent on without a judge, and you'll catch nothing while false positives pile up.

# Start with the oracle. Without it, nothing else here matters.
cmake -B build-asan -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DCMAKE_C_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" \
  -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer"
cmake --build build-asan -j

# Just running your existing tests through the sanitizer build usually turns something up
ASAN_OPTIONS=detect_leaks=1 UBSAN_OPTIONS=print_stacktrace=1 ctest --test-dir build-asan

2. Don't have the model hunt for bugs — have it write harnesses. This is what Google actually did in 2023, and it's the point with the best payoff relative to cost. List out the "functions that take a byte string" — parsers, decoders, serialization code — generate a draft harness for each, and run the four-step loop where the model fixes compile and runtime errors. Here the model's output is immediately validated by the compiler and the fuzzer, so hallucinations don't survive.

3. Automate triage before fixes. This is where Google saw its biggest time savings. Deduplication, reproduction, severity estimation, and owner assignment have clear grading criteria, so the damage from an automation failure is small. Auto-generating patches, on the other hand, becomes a new bug when it goes wrong — so that's the piece to bolt on later.

4. Require regression tests on every automated patch. This is the role Chrome's test-writing agent plays in its pipeline. Bundle the patch and the test into the same change, and add a mechanical check that the test fails without the patch. Without this, there's no way to tell a "patch that claims to have fixed it" from a "patch that actually fixed it."

5. Keep the critic in a separate context. Letting the same session grade its own output leaves confirmation bias fully intact. Google does this, and so do the large-scale migration cases covered earlier — the same structure shows up in both.

6. Don't set your metric as raw discovery count. Watch revert rate, false-positive rate, time from discovery to deployment, and the severity breakdown instead. Discovery counts will spike the first month you turn a tool on, and will fall afterward without fail. Report that curve as your outcome, and you'll have nothing to explain in month two.

7. Fix your deployment path at the same time. This is the real lesson of the Chrome case. Multiply discovery by 10x and leave the release cadence untouched, and what grows isn't security — it's the backlog of undeployed patches.

Conclusion — Finding a Lot Means It Was There the Whole Time

1,072 is evidence that Chrome got safer in June, and it's evidence that all of those bugs were alive the entire time before that. The 13-year-old sandbox escape summarizes that sentence best. And the tooling that drove down the cost of discovery isn't exclusive to defenders.

Cut down to three lines of what to carry forward:

• This result holds not because the model is smart, but because the machine-verifiable oracle called a sanitizer was already sitting there. The same method doesn't transfer to vulnerability classes without an oracle.
• The cheapest piece to copy isn't bug detection — it's harness generation and triage automation. Both have output that's immediately machine-verified.
• When discovery gets cheaper, the bottleneck moves down to deployment. That's why Google is pulling its release cadence to two weeks and researching dynamic patching, and that's the most practically useful part of this announcement.

The moment you make bug count your success metric, that metric only looks good in the month you turned the tool on. If you want it to hold up over time, you're better off counting revert rate and time-to-deployment instead.

References

• Stronger with every update — Google's original Chrome security announcement (2026-07-30)
• TechCrunch — Google says it fixed more Chrome bugs in June than over the past two years (2026-07-30)
• BleepingComputer — a rundown of the 1,072 fixes and the tooling lineage
• OSS-Fuzz — Fuzz target generation using LLMs (30 percent coverage increase, the four-step loop)
• Hacker News — the skeptical discussion of the announcement
• A field guide to moving a codebase with AI — critic agents and machine-verifiable structure (related post)