Google today is out with a lengthy post describing the role of AI and LLMs in Chrome security.

While it takes Google 1-2 days to triage, fix, test, and release a patch, the “time spent waiting for the user to restart Chrome can be a significant contributor to N-day exploitation risk,” or the patch gap.

Acknowledging the burden of having to restart, Google is investing in “dynamic matching” to “eliminate the need for a full browser restart in most cases.” It works by replacing “background child processes (like the Renderer and GPU) with updated binaries on the fly.” This approach leverages Chrome’s multi-process architecture.

The Chrome team is still researching and developing this feature. Google is also “exploring ways to ensure a seamless session restore even in complex cases, by saving more state locally.” This will become more important when Chrome moves to its two-week update cycle later this year.

Until then, Google is looking for “opportune moments to restart automatically, when we can guarantee a seamless session restore.” In Chrome 150 for Mac, Google will restart the browser automatically when there’s a pending update and no open user windows. 

For example, in Chrome 150, we rolled out a change to take advantage of the unique application state on macOS where applications typically continue running in the background even after all windows are closed.

Google also discussed its latest use of LLMs to find bugs, with the process starting in 2023. Earlier this year, it created an agent harness that uses Gemini and other models to “find vulnerabilities across the broader Chrome codebase with higher efficiency and lower false positives.” One notable find was a bug that had been in the codebase for 13 years. 

In terms of safety, some interesting process details were shared:

• “Our AI analyzes source code strictly at rest, operating on locked-down machines that lack general internet access.”
• “We also utilize a dedicated setup for these internal scans that intercepts all network requests, employing strict allowlists based on the initiating application and destination, blocking any suspicious model activity.”
• “Furthermore, we never run models in an unrestricted mode, and we strictly limit our subagents from modifying the local system or accessing files outside of designated source code directories.”
• “We have partnered closely with Google DeepMind and Project Zero for years, including on BigSleep and CodeMender. These tools are natively integrated into our continuous integration (CI) system, running every 24 hours across all CLs to proactively detect security bugs. This integration has yielded significant results: in May alone, we blocked over 20 vulnerabilities from reaching production, including a critical S1+ issue.”

To fix vulnerabilities, there’s now a multi-agent workflow, with LLMs generating candidate fixes for most of them:

1. After initial build steps that bring in context from a specific issue, we run a fixing agent that returns multiple candidate fixes.
2. A critic agent then evaluates which would be the best fit, producing other relevant artifacts for developers to evaluate the fix.
3. The fixing and critic agents work in a loop that mimics a typical code review process to ensure that code is functional and compliant with Chromium and Google style guidelines, as well as other local code conventions.
4. Test-writing agents help write tests for fixes. These agents can ensure that tests work across the full array of Chrome supported platforms and configurations before a developer reviews the fix, saving up to weeks of developer time.

This process has resulted in a dramatic increase in security fixes:

In the last two milestones, Chrome 149 and 150, we have fixed 1072 security bugs, surpassing the total number of security bugs fixed across the prior 23 milestones combined.