How we’re making Chrome and the web safer in the AI Era

Our long-term vision is a browser that is always up-to-date – continuously and dynamically patched, and automatically restarted during opportune periods of minimal disruption. While we’re working on this, you can keep your Chrome up to date by clicking on the update message in the top right corner.

For enterprise customers looking to keep Chrome up to date, we recommend that IT admins:

• Apply the RelaunchNotification policy which prompts users to restart Chrome to apply a pending update, escalating from a gentle reminder to a forced restart over a set timeframe.
• Utilize the Chrome Extended Stable Channel for highly sensitive environments where software changes must be vetted.
• Leverage the OS-agnostic dashboard provided by Chrome Enterprise Core or Premium to track fleet-wide browser versions and manage updates at a more granular level.

Prevention is better than cure

Beyond fixing individual security bugs, we’re also investing in the mitigation and elimination of entire classes of security bugs, as well as in preventing them from landing in the first place. With AI coding advancements, we believe there are exciting opportunities to accelerate projects that would have previously taken years, or never happened.

Memory safety mitigations

Chrome is executing on a two-layered memory safety strategy: hardening our runtime environment to neutralize legacy C++ vulnerabilities, while shifting to memory-safe languages for long-term architectural resilience.

The vast majority of the Chromium codebase remains in C++, making immediate toolchain and runtime mitigations our critical first line of defense. We have long prioritized memory-safety engineering at scale, deploying hardened standard template libraries and pioneering technologies like the MiraclePtr family to neutralize Use-After-Free (UAF) vulnerabilities. AI-powered vulnerability detection only reaffirms the need for such technology.

Our C++ defensive roadmap is focused on three pillars:

• MiraclePtr & MiracleObject Expansion. Having already driven a major reduction in UAF bugs via MiraclePtr, we are expanding this paradigm to more libraries such as Skia, ANGLE, Dawn, C++ iterators and std:: containers. We are also actively deploying MiracleObject with the aim of neutralizing up to 90% of UAF vulnerabilities on the GPU main thread, deliberately trading localized runtime performance for temporal safety.
• Spanification. To systematically eliminate Out-of-Bounds (OOB) spatial safety errors, Chrome has undertaken a massive “spanification” effort, migrating legacy pointer-and-size constructs to compiler-enforced std::span types. Currently, 97% of first-party Chrome code compiles cleanly with strict unsafe-buffer warnings. We are now pushing these requirements downstream, expanding spanification into foundational codebases like Skia, ANGLE, and Dawn.
• Structural & Allocation Hardening. We are working on integrating checked math for calculations tied to memory allocations to block integer overflow avenues. Concurrently, Chrome is implementing an additional level of heap partitioning to strictly segregate pointer-containing types from non-pointer types to make it harder to exploit UAF bugs.

While C++ safety enhancements provide an immediate shield, we believe that runtime mitigations will hit diminishing marginal returns within the next few years. Runtime checks are inherently more expensive than compile-time guarantees, and even a heavily mitigated C++ binary requires rigid, performance-throttling sandboxing to comply with the Rule of Two.

The long-term solution is shifting the codebase towards memory-safe languages like Rust, focusing on the following core tenets:

• Rust flywheel. Developers cannot be expected to entirely absorb the velocity friction of engineering in a new language ecosystem. As such, we are building a centralized Rust SDK that exposes foundational Chromium APIs and tooling directly to Rust. Our aim is to turn Rust into a routine, frictionless engineering choice for new components.
• Targeted “bug nest” eradication. Rust is being deployed strategically to replace code segments that exhibit high historical bug density (such as complex data parsers, image codecs, and font stacks).
• Enabling high-privilege modularization. By writing new modular components in Rust, Chrome can safely execute complex features inside high-privilege processes (like the browser process) without the performance penalties of sandboxing, breaking the constraints of traditional C++ architecture.

In addition to Rust, we are also exploring options like implementing the browser’s top-level user interface using HTML, CSS, and TypeScript to further reduce dependencies on traditional C++ frameworks.

Catching security bugs before they land

Bulk scanning of a code base cannot keep pace with Chrome’s high-traffic development velocity. To account for this, we’re also deploying AI-powered bug-finding capabilities to identify and prevent bugs as close to code submit-time as possible. Part of Chrome’s continuous integration (CI) and commit queue (CQ) pipeline, these defensive models automatically scan diffs to prevent new vulnerabilities by performing actions like suggesting spanification fixes, flagging dangling pointers, and enforcing numeric safety.

Additionally, a major challenge in large-scale software engineering is the “latent security issue.” Code that is safe and robust in isolation can be transformed into a critical vulnerability by an entirely unrelated, minor logic change elsewhere in the tree. By utilizing continuous, LLM-powered semantic analysis within the CQ, Chrome can intercept these compound risks before they land in the tree, catching the subtle or complex interactions that traditional static analysis misses.

Securing the internet

Keeping the web safe involves more than just securing Chrome. Google has been a long-standing supporter of open source projects and communities to ensure better security outcomes for all users. Most recently, Google joined others in donating $12.5M to the Alpha-Omega project in support of enabling maintainers to have access to the tools and support they will need in order to respond quickly to vulnerability reports. Google was also a founding member of the Akrites project, which aims to lower the burden on upstream maintainers by providing a centralized clearinghouse for vulnerability reports and a security incident response team.

On the Chrome team, we feel this responsibility acutely — the Chromium Project is the largest open source project on the planet. To put the sheer scale of this challenge into perspective, Chrome has more than 2,300 third-party dependencies across Chromium and satellite projects like the V8 JavaScript engine, the BoringSSL cryptography library, and foundational graphics components like Skia, ANGLE, and Dawn. About 1,700 of those are shipped to users in some capacity, woven into a wide spectrum of products from Android devices to edge computing platforms and massive cloud enterprise stacks.

To keep these dependencies patched, we rely on automated vulnerability scanning pipelines. These pipelines ingest data from Google’s internal feeds as well as several external monitoring feeds, including the U.S. government’s National Vulnerability Database (NVD) and the open-source focused Open Source Vulnerabilities (OSV) database.

Now more than ever, relying on reactive monitoring alone can leave a dangerous risk gap. Since the best way to stay on top of vulnerabilities and their patches is to keep third-party dependencies fresh, this year, we are starting to move all Chrome third-party dependencies onto automated update pipelines that proactively roll them to their latest upstream versions. Automation always requires guardrails, so we will also be using safety signals from projects such as Google’s Open Source Security Intelligence Platform (GOSSIP) to ensure that we are accounting for other risks in the third-party open source software ecosystem.

Moving forward

While this dramatic change in software security brought about by LLMs might be startling, an increase in bugs found and fixed is not a sign of failure. Every bug found and fixed is one less foothold for an attacker. But discovering and fixing a bug is only half the battle — we must also ship the fix and apply the update for users faster than adversaries can exploit the bug, and invest in projects that mitigate or eliminate classes of bugs through accelerated release cadences, dynamic patching, and opportune restarts, we are driving toward a browser that is continuously protected without disrupting the user.

The AI era has undeniably intensified the software security threat landscape, but by combining rapid deployment mechanisms with deep structural defenses, we are ensuring the advantage remains firmly with defenders. With this, Chrome and the broader web become safer with every update.