Chrome and Chromium Release History: Channels, Cadence and Security

Google launched Chrome and the open source Chromium project on 2 September 2008. Chrome shipped a new milestone roughly every six weeks from 2010, every four weeks from Chrome 94 in 2021, and every two weeks today, with an eight week Extended Stable option. Each era added a security layer: the sandbox, site isolation, HTTPS defaults and memory safety work.

Every date below comes from Google's own records; the second half turns the history into steps for keeping a fleet, and the Chromium inside desktop apps, up to date.

Key takeaways

• Chrome and Chromium launched together on 2 September 2008. Chromium is the open source project under a BSD license; Chrome is Google's browser built from it, and many other browsers and desktop frameworks are built from Chromium too.
• The first stable release, 1.0.154.36, shipped on 11 December 2008. Six week releases were announced in July 2010; four week milestones and Extended Stable started with Chrome 94 on 21 September 2021.
• Chrome now ships a new milestone to Stable every two weeks, starting with Chrome 153 on 8 September 2026. Extended Stable still moves every eight weeks.
• Security layers arrived in eras: a sandboxed multi process design at launch, desktop site isolation in Chrome 67, "Not secure" for HTTP in Chrome 68, the Chrome Root Store in Chrome 105, the V8 sandbox around Chrome 123 and "Ask before HTTP" by default in Chrome 154.
• Security fixes also ship as weekly Stable refreshes. Chrome 156 alone, on 20 October 2026, listed 353 security fixes.
• Enterprises can pin, roll back and choose channels, but Google's own help pages warn that pinning should be temporary and rollback exposes users to known security issues.
• Chromium also ships inside desktop applications. Those copies update only when the application vendor ships a new build, so they belong in your inventory and your SBOMs.

Chromium, Chrome and the browsers built from it

On 2 September 2008 the Chromium team posted on its new blog that Google had launched a browser called Google Chrome and, at the same time, released all of the code as open source under a permissive BSD license. The project took the name Chromium, after the metal used to make chrome. The post said the goal was to help drive the web forward and to let other projects reuse the code.

A 2018 Chromium blog retrospective adds that the team started work in 2006, as heavy web applications strained older browser designs, and that the mantra was simplicity, speed, security and stability. The multi process design served stability and security at once: a hung tab did not take down the browser, and the process boundary gave the sandbox a home.

The early releases were labelled Beta. The Chrome Releases blog recorded beta builds such as 0.2.149.29 on 8 September 2008, then on 11 December 2008 announced that Google Chrome was "officially out of Beta" with version 1.0.154.36.

The relationship between the three layers is worth stating plainly, because it drives how fixes reach you:

The last two rows are why one Chromium fix can reach different users days or months apart. Chrome Releases posts say bug details may stay restricted until most users have the fix, and longer if the bug sits in a third party library other projects have not yet fixed.

How the release cadence changed

2008 to 2010: from ad hoc releases to the six week train

Early Chrome had no fixed rhythm. When a feature missed a deadline, the Chromium blog later wrote, engineers rushed, the release slipped, or the feature waited about three months. On 22 July 2010 the blog announced a stable version "about once every six weeks", roughly twice as often as before, run like trains on a timetable: a feature that misses one train rides the next. That rhythm lasted more than a decade, until Chrome 93.

2021: four weeks from Chrome 94, plus Extended Stable

On 4 March 2021 the Chromium blog announced a new milestone every four weeks, starting with Chrome 94, crediting better testing and the earlier move to bi weekly security updates that had shortened Chrome's "patch gap".

The same post introduced Extended Stable: milestone updates every eight weeks, aimed at enterprise administrators and Chromium embedders who need more time. It was explicit about the trade: Extended Stable gets security updates every two weeks for important issues, but not every security fix the faster channel receives. Chrome 94 reached Stable on 21 September 2021.

2026: two week milestones

Chromium's release cycle documentation now opens with a different number: Chrome ships a new milestone to the Stable channel every two weeks. The calendar shows when the switch happened. Chrome 150, 151 and 152 reached Stable four weeks apart (30 June, 28 July and 25 August 2026). Chrome 153 followed two weeks later on 8 September, then 154 on 22 September, 155 on 6 October and 156 on 20 October. Chrome 157 is scheduled for 3 November 2026.

The Chrome Enterprise help page on release channels says the same thing in administrator terms: Stable "is updated every 2 weeks for major releases", Extended Stable every eight weeks.

How a milestone moves through the cycle today

The release cycle document breaks each milestone into steps:

1. Development on main. A milestone is developed for two weeks, starting at the previous milestone's branch point.
2. Branch point. The day's Canary build becomes the milestone branch. Features that are not code complete get pushed to the next milestone.
3. Beta promotion. Shortly after branch, the milestone goes to the Beta channel, where it spends two weeks being stabilised.
4. Early Stable. The milestone ships to a small percentage of Stable users first. The Chrome Releases blog labels these posts "Early Stable Update", as it did for Chrome 157.0.8103.15 on 22 October 2026.
5. Stable promotion. Three weeks after branch point the milestone is promoted to Stable, and it generally reaches all users within one to two weeks.
6. Stable refresh. Stable and Extended Stable are refreshed every week, to deploy security fixes and keep the patch gap short.

Extended Stable works by keeping every fourth milestone branch alive for six more weeks with backported security fixes. For the first two weeks of such a milestone, Stable and Extended Stable ship identical builds; after that they diverge. There is no separate Extended Beta, so Google tells enterprises on Extended Stable to keep running some Beta users to catch problems early.

The channels

Chrome Enterprise help lists five channels and how Google recommends using them:

Timeline: milestones and the security features each era added

The table lists only features whose milestone or date we could confirm on a Google page. Stable dates come from the Chromium release calendar unless the row says otherwise.

A few notes on reading this table. "On by default" dates are when a feature reached Stable, and Chrome rolls changes out gradually. Some features sat behind flags or policies earlier. We left out milestones we could not tie to a Google page rather than guess.

Era one, 2008 to 2017: the sandbox and the release train

The founding security decision was architectural. The Chromium blog's 10 September 2008 security architecture post describes two modules. The browser process has the user's full access, so the team kept it simple: it does not parse HTML or run JavaScript. The rendering engine does that work inside a sandbox and must ask the browser process for anything touching the disk or network. The post was honest about limits: the sandbox does not stop phishing or cross site scripting. It backed the design with data: about 70% of the most serious browser vulnerabilities the team reviewed were in the rendering engine.

Two changes in 2010 shaped everything after. The Chromium Security Reward program began paying researchers, and by July 2010 the top single reward rose to $3,133.70, which the team said reflected how the sandbox made critical bugs harder to find. And the six week train meant a fix or a new defence never waited months for a release.

Era two, 2018 to 2020: HTTPS everywhere and site isolation

On 8 February 2018 the Chromium blog announced that from Chrome 68, in July 2018, every HTTP page would show "Not secure". At the time over 68% of Chrome traffic on Android and Windows, and over 78% on ChromeOS and Mac, already used HTTPS. In October 2019 the team moved on to mixed content, insecure pieces loaded by HTTPS pages: Chrome 79 added a per site setting, Chrome 80 upgraded or blocked mixed audio and video, and mixed image upgrading slipped from Chrome 81 to at least Chrome 84. From 13 January 2020, Chrome 79 and later also flagged sites on TLS 1.0 or 1.1 as "Not secure". Site isolation, covered below, arrived in the same years.

Era three, 2021 to 2025: faster releases and deeper hardening

Chrome 89 moved the whole codebase to PartitionAlloc, Chromium's own allocator, on Windows 64 bit and Android, which the Chromium blog said made MiraclePtr possible. HTTPS moved from warning to upgrading: Chrome 94 offered opt in HTTPS-First Mode, the August 2023 "Towards HTTPS by default" post set out automatic upgrades and insecure download warnings, and Chrome Platform Status lists HTTPS Upgrades on by default from Chrome 115.

Certificate trust got its own program. The Chromium blog announced the Chrome Root Program in September 2022 and said the Chrome Root Store and Certificate Verifier began rolling out on Windows and macOS in Chrome 105. Chrome's Certificate Transparency policy sets when a certificate counts as "CT Compliant", based on signed timestamps from distinct logs and log operators; our certificate transparency explainer covers the logs themselves.

Extensions changed platform: Manifest V3 arrived with Chrome 88, and the Manifest V2 phase out began in June 2024 with an enterprise policy exemption until June 2025. See Manifest V3 security and the Manifest V2 shutdown. The era closed with the V8 sandbox leaving experimental status around Chrome 123 and Chrome 124 turning on X25519Kyber768 for TLS on desktop, which Chrome Platform Status says protects traffic from decryption by a future quantum computer when the server supports it too.

Era four, 2026: two week milestones and HTTPS by default

Milestones now ship every two weeks, which halves how long any milestone stays current. And Chrome 154 turned "Ask before HTTP" on by default, with the HttpsOnlyMode policy for administrators. That completes the arc the Chromium blog started in 2018 with "Not secure" labels.

How the Chromium sandbox works

The Chromium sandbox is a set of operating system restrictions placed on processes that handle untrusted content, chiefly renderers. Chromium's sandbox design document describes the Windows implementation in detail and points to separate Linux and macOS documents.

On Windows, the sandbox is user mode only and has two roles. The broker is always the browser process. It sets the policy for each sandboxed process, starts those processes, and performs any action the policy allows on their behalf. The target is the sandboxed process. It runs with a restricted token, inside a Windows job object, on an alternate desktop, at a low integrity level and with process mitigation policies applied. When a target needs something it cannot do itself, a small set of Windows API calls are forwarded over the sandbox's own IPC to the broker, which checks them against policy and returns the result.

The consequence for defenders: a renderer bug alone should give an attacker code execution inside a process that, in the 2008 post's words, is meant to be kept from installing software or reading confidential files. Real damage takes a second bug, a sandbox escape. That is why the reward program raised its top payout in 2010, citing the sandbox, and why our browser sandbox escape history treats the sandbox as a boundary that raised the price of attacks rather than ended them.

How site isolation works and what changed after Spectre

The idea

The sandbox protects the computer from the web. Site isolation protects websites from each other. Chromium's site isolation documentation says the browser should assume determined attackers will eventually compromise a renderer, and cites 10 potentially exploitable renderer bugs in Chrome 69, 5 in 70, 13 in 71, 13 in 72 and 15 in 73.

Before site isolation, one renderer process could hold pages, and frames, from several sites. A compromised renderer, or a bug that broke the same origin policy inside it, could read data from another site in the same process. Site isolation makes the operating system process the boundary. Chromium's documentation says cross site documents always go into a different process, whether the navigation happens in the current tab, a new tab or an iframe. On desktop, security checks in the browser process can detect a misbehaving renderer and terminate it.

Spectre changed the threat model

Chromium's documentation says side channel attacks like Spectre make reading arbitrary renderer memory possible even without bugs in Chrome. The dependable answer was to keep sensitive cross site data out of the attacker's process in the first place.

So Chrome 67 turned site isolation on by default for all sites on Windows, Mac, Linux and ChromeOS. In Chrome 77 the desktop protection grew to cover fully compromised renderers and universal cross site scripting bugs. In Chrome 92 extensions were isolated from each other, and in Chrome 110 site isolation came to webview tags.

Android, and the cost

Android devices have less memory, so the Android version is selective. From Chrome 77, on devices with at least 2 GB of RAM, Chrome isolates sites where users log in with a password, and Chrome 92 added sites that use third party login providers. Chromium's documentation gives the costs: about 10 to 13% more memory on desktop in Chrome 67 with many tabs open, and about 3 to 5% on Android in Chrome 77. Site isolation is not yet supported in Android WebView or on Chrome for Android devices with less than 2 GB of RAM. Administrators can widen coverage on Android with the SitePerProcessAndroid or IsolateOriginsAndroid policies.

What sites still need to do

A March 2021 Chromium blog post added that browsers cannot do this alone, and asked developers to use Cross-Origin-Resource-Policy, framing protections, Cross-Origin-Opener-Policy, correct Content-Type headers and nosniff so sensitive responses never load into an attacker's process.

What the V8 sandbox is and why it matters

V8 is the JavaScript and WebAssembly engine inside Chromium. The V8 team's April 2024 post gives the motivation: every Chrome exploit caught in the wild from 2021 to 2023 started with a memory corruption bug in a renderer process that was used for remote code execution. The post adds that modern JavaScript engines tend to contain subtle, second order logic bugs, especially in just in time compilers, rather than classic memory errors, and those logic bugs can then be turned into memory corruption.

The V8 sandbox is a lightweight, in process sandbox, implemented purely in software because no suitable hardware feature exists today. Only the V8 heap sits inside it; the stack cannot, because it must hold real pointers such as return addresses. Inside the sandbox, objects refer to each other with offsets from the sandbox base (a 40 bit offset for a 1 TB sandbox) instead of full pointers. References to anything outside go through a pointer table, which the post compares to a Unix file descriptor table. The result is that corrupted heap data cannot simply "reach out" into the rest of the process. A typical V8 bug then corrupts only memory inside the sandbox, and the attacker needs a second, separate bug to escape it, before even reaching the process sandbox.

The timeline, from the V8 team's own post:

• The initial design document came almost three years before April 2024.
• The sandbox had already been on by default in 64 bit Chrome on Android, ChromeOS, Linux, macOS and Windows for roughly two years by then.
• On 4 April 2024 the team said the sandbox was no longer an experimental feature and added it to Chrome's Vulnerability Reward Program, calling Chrome 123 a kind of "beta" release for it.
• The post said a number of issues remained before it would be a strong security boundary.

That is the honest summary: the V8 sandbox turns many single bug exploits into two bug exploits, but it is not a guarantee.

Memory safety work: PartitionAlloc, MiraclePtr and safer languages

Chromium's memory safety page states the problem directly: around 70% of the project's high severity security bugs are memory safety problems, meaning mistakes with C and C++ pointers. The work to address that runs in parallel tracks.

PartitionAlloc. Chromium's own allocator separates objects into partitions and size buckets, never reuses address space across them, guards some metadata with inaccessible pages and encodes free list entries to detect corruption. From Chrome 89 it replaced the system allocator everywhere on Windows 64 bit and Android.

MiraclePtr. Use after free bugs happen when code keeps using memory after it was released. Chromium's raw_ptr documentation says raw_ptr<T> is part of the MiraclePtr project and implements the BackupRefPtr algorithm, which can prevent a significant share of use after free bugs from being exploitable. Per that document, the protection is on by default in all non renderer processes on Android (including WebView), Windows, ChromeOS, macOS, Linux and Fuchsia, but not yet on iOS. It has a runtime cost, because the pointer has to maintain a reference count.

Safer languages. The memory safety page lists Java, Kotlin, JavaScript, Rust and Swift as options where they fit, and the Chromium team published notes in August 2020 on Rust and C++ interoperability, saying engineers were experimenting with Rust and that any Rust would need to fit around C++. We did not find a Google page tying Rust adoption to a specific milestone, so we give no version here.

For how these defences combine, see our post on layered defences for memory bugs in Chromium and Android and the memory safety explainer.

How security fixes ship

Milestones, refreshes and early Stable

Fixes reach Chrome users in three main ways.

1. A new milestone. Every two weeks a new major version reaches Stable carrying every fix merged on main during its development. The Chrome 156 Stable post on 20 October 2026 said the update included 353 security fixes.
2. Stable refreshes. Between milestones, Chromium's release cycle docs say Stable and Extended Stable are refreshed every week to deploy security fixes. These appear on the Chrome Releases blog as "Stable Channel Update for Desktop" posts with a new build number and a list of fixed issues.
3. Component updates. Some parts of Chrome update separately from the browser. Google's Windows update guide says that even if you turn off Chrome browser updates, components such as Widevine DRM keep updating unless you also disable the ComponentUpdatesEnabled policy, which itself exempts some components.

Early Stable adds a wrinkle. A few days before a milestone's full promotion, a small share of Stable users receive it. On 22 October 2026, for example, the Chrome Releases blog posted Chrome 157.0.8103.15 for Windows as an early Stable release, while the main Stable release was still Chrome 156. Version lookups can therefore return a higher number than most of your fleet will see that week.

Reading a Chrome Releases post

Each Stable post lists the version per platform, a change log link, then a "Security Fixes and Rewards" section with each issue's severity, CVE identifier, component and reporter. Our guide on following Chrome security fixes from the Chrome Releases blog covers the format line by line. Read the platform lines first: the 22 October early Stable post, for example, shipped Windows first with Mac "coming shortly".

How a fleet should track them

• Watch the Chrome Releases blog for Stable and Extended Stable desktop posts, and the separate Android and iOS posts.
• Pull the current version for each platform and channel from the VersionHistory API rather than scraping pages.
• Compare installed versions against the current milestone and its latest refresh, not just the major number.
• Track restart compliance. Chrome downloads updates in the background, but a running browser keeps the old version until relaunch; Google's help center lists a policy to notify users to restart.
• Keep a list of every other Chromium based product and embedded Chromium in use, with the Chromium version each one carries.

How enterprises control versions, and the risks

On Windows, Chrome's update levers are Google Update group policies, visible at chrome://policy.

Two details from Google's guide are easy to miss. First, pinning to a milestone with the trailing dot syntax still delivers that milestone's security refreshes, as long as that milestone is the current Stable major. Once Stable moves on, the pinned devices stop getting fixes. With two week milestones that happens fast. Second, rollback depends on user data snapshots. Chrome keeps the three most recent by default; if you set the snapshot limit to zero, a rollback deletes local browsing data unless sync or roaming profiles are on.

The planning consequence: a milestone pin that once covered six weeks, then four, now covers two. Extended Stable is the supported way to slow down; a long pin on Stable is not.

Step by step: check, compare, read, verify

These steps are read only. They do not change any browser or policy.

Step 1: read the installed version

On any desktop, open chrome://version or chrome://settings/help. From a terminal:

# Linux
google-chrome --version

# macOS
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --version

# Windows: read the version from a system wide install (per user installs live under LOCALAPPDATA)
(Get-Item "$env:ProgramFiles\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion

Step 2: get the current version for your platform and channel

Google's VersionHistory API is public and documented on developer.chrome.com:

# Current Stable build for 64 bit Windows
curl -s "https://versionhistory.googleapis.com/v1/chrome/platforms/win64/channels/stable/versions?pageSize=1"

# Current Extended Stable build for 64 bit Windows
curl -s "https://versionhistory.googleapis.com/v1/chrome/platforms/win64/channels/extended/versions?pageSize=1"

# List every valid platform and channel pair
curl -s "https://versionhistory.googleapis.com/v1/chrome/platforms/all/channels"

Remember early Stable. In the week we checked, the Windows Stable entry already showed 157.0.8103.15 from the early Stable rollout, while the Stable desktop post still named 156 as the main release. Treat "one milestone behind during an early Stable week" as normal; two or more is a gap.

Step 3: check the schedule

The Chromium release calendar has a JSON endpoint for each milestone:

curl -s "https://chromiumdash.appspot.com/fetch_milestone_schedule?mstone=157"

The response includes the branch point, earliest Beta, final Beta and Stable dates. Use it to plan Beta testing windows two weeks ahead.

Step 4: read the release post

Open the newest "Stable Channel Update for Desktop" post on the Chrome Releases blog. Check the build numbers per platform, then the count and severity of security fixes. If a post mentions an issue known to be exploited, treat the update as urgent and push a restart.

Step 5: verify managed update policy

Open chrome://policy on a managed machine and look for the Google Update policies and Chrome policies above. On Windows you can also read the policy keys without changing them:

# Read only: list Google Update and Chrome policies set on this machine
reg query "HKLM\SOFTWARE\Policies\Google\Update"
reg query "HKLM\SOFTWARE\Policies\Google\Chrome"

Look for update overrides set to disabled, a target version prefix, rollback settings, a target channel, a suppression window and ComponentUpdatesEnabled. Any pin should have an owner and an end date.

Step 6: confirm security defaults and record the result

Still in chrome://policy, check that nothing weakens defaults you rely on, such as the HttpsOnlyMode, SitePerProcess or IsolateOrigins policies. Record version, channel, policy state and date in your inventory, and repeat on a two week rhythm.

Embedded Chromium: the copies your fleet forgets

The harder part is Chromium you did not install as a browser:

• Other Chromium based browsers. Each vendor merges Chromium changes and ships on its own timeline, so do not assume a Chrome fix reached them the same day. Check each vendor's own release notes.
• Desktop applications built on embedded Chromium frameworks. A chat client, code editor or internal tool may carry a full Chromium runtime. It updates only when the app ships a new build, and an app that is not updated keeps the Chromium it was built with. Our posts on how old the Chromium inside an Electron app can be, Electron app supply chain security and recent Electron advisories and Chromium backports go into the details.
• Headless Chromium in CI and containers. Test runners, PDF renderers and scraping jobs often download or bundle a specific Chromium build. These live in build images and lockfiles, not on desktops.
• Android WebView. Apps that show web content on Android use WebView, which Chromium's site isolation docs note does not yet get site isolation.

The practical fix is inventory. If your SBOM for a desktop application or container image does not list the Chromium or framework version inside it, you cannot answer "are we exposed" when the next Stable post lands.

Common mistakes

• Pinning too long. A milestone pin keeps working only while that milestone is current Stable. With two week milestones, a pin forgotten for a month means no fixes at all. Use Extended Stable if you need a slower pace.
• Pinning an exact build. Google's guide warns that exact build pins can land you on a version that is not the latest or has known bugs.
• Assuming a downloaded update is installed. Chrome applies updates on relaunch. Without restart nudges, a fully "updated" fleet can still run old code.
• Ignoring embedded Chromium. Other Chromium based browsers, desktop apps and headless test tools carry their own Chromium on their own schedules. Chrome's updater does not touch them.
• Treating Extended Stable as "the same fixes, later". Google's announcement says Extended Stable does not receive all the security fixes that Stable gets.
• Turning off component updates to "freeze" a build. Components carry their own fixes, and Google exempts some from the policy anyway.
• Rolling back without a data plan. Rollback can delete local browsing data when snapshots are disabled and sync is off.

FAQ

When was Google Chrome first released?

Google released Chrome as a beta and open sourced Chromium on 2 September 2008. The first stable release, version 1.0.154.36, followed on 11 December 2008.

What is the difference between Chrome and Chromium?

Chromium is the open source browser project under a BSD license. Google Chrome is Google's browser built from Chromium plus Google's own additions, such as its update system. Other browsers and desktop frameworks are also built from Chromium.

How often does Chrome release a new version?

Chromium's release cycle documentation says a new milestone reaches the Stable channel every two weeks, with weekly security refreshes in between. That started with Chrome 153 on 8 September 2026. From Chrome 94 in 2021 until then the cadence was four weeks, and from 2010 it was about six weeks.

What is Chrome Extended Stable?

It is one of five channels (with Canary, Dev, Beta and Stable), for organisations that need more time. It ships a new milestone every eight weeks by keeping every fourth milestone alive longer with backported security fixes, and it receives fewer security fixes than Stable.

When did Chrome add site isolation?

Site isolation was turned on by default for all sites on Windows, Mac, Linux and ChromeOS in Chrome 67 in 2018, as a defence against Spectre style attacks. Android got it for sites where users log in from Chrome 77.

What is the V8 sandbox?

It is a lightweight, in process sandbox around the V8 JavaScript engine's memory, so that a typical engine bug corrupts only memory inside the sandbox. The V8 team said in April 2024 that it was no longer experimental and added it to Chrome's reward program.

Does Chrome block HTTP sites by default?

Since Chrome 154 (22 September 2026), Chrome asks before connecting to a site over plain HTTP by default. Administrators can control this with the HttpsOnlyMode policy. Earlier, Chrome 115 started upgrading navigations to HTTPS automatically with fallback.

How do I check which version of Chrome I have?

Open chrome://settings/help or chrome://version. On Linux run google-chrome --version. Compare the result with the current Stable version from Google's VersionHistory API or the Chrome Releases blog.

Can I roll back Chrome to an older version in a company?

On Windows, Google Update's Rollback to Target version policy, used with Target version prefix override, can roll back to one of the three latest major releases. Google warns this exposes users to known security issues and should be temporary.

Why software supply chain hygiene still matters here

Chrome's own updates come from Google, and nothing below replaces them. But Chromium is also a dependency: it ships inside desktop frameworks, headless test tools and container images that your teams build, and those copies only move when someone updates the dependency and rebuilds.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

To be plain about the fit: Safeguard does not manage browsers, push Chrome updates, read Chrome policies or replace the Chrome Releases blog. Google ships Chrome's fixes, and the steps above are how you confirm they arrived. Where Safeguard helps is the code your teams build: it scans repositories, container images and SBOM files for dependencies, matches them against vulnerability data, and shows which projects contain a given component and version. That includes the embedded Chromium frameworks and headless browser packages pulled in through npm, pip or a base image.

The first demo is a real CLI session. Asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies when a desktop app's framework or a test project's headless browser package is behind: the assistant proposes the version change in the manifest and runs your tests, and you decide what ships.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. That is the route for scanning a desktop application repository or a CI image that bundles Chromium on the machine where it is built, so the dependency list in your SBOM comes from the same place as the release.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For a team that already works in Claude, it is a way to ask which of your own projects carry a given framework or package version on the day a Chrome Releases post lands, with tool permissions you set.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Chromium blog: Welcome to Chromium (2 September 2008)
• Chromium blog: Security Architecture (10 September 2008)
• Chrome Releases: Stable release, Google Chrome is out of Beta (11 December 2008)
• Chromium blog: How we designed Chrome 10 years ago
• Chromium blog: Celebrating six months of Chromium Security Rewards
• Chromium blog: Release Early, Release Often (22 July 2010)
• Chromium blog: Speeding up Chrome's release cycle (4 March 2021)
• Chromium Docs: Chrome Release Cycle
• Chromium Dash release calendar
• Chrome Enterprise and Education Help: Chrome browser release channels
• Chrome Enterprise and Education Help: Manage Chrome updates (Windows)
• Chrome for Developers: VersionHistory API guide
• Chrome Releases: Stable Channel Update for Desktop, Chrome 156 (20 October 2026)
• Chrome Releases: Extended Stable Update for Desktop (15 October 2026)
• Chrome Releases: Early Stable Update for Desktop (22 October 2026)
• Chromium Security: Site Isolation
• Chromium blog: Recent Site Isolation improvements (October 2019)
• Chromium blog: Mitigating Side-Channel Attacks (March 2021)
• Chromium Docs: Sandbox
• V8 blog: The V8 Sandbox (4 April 2024)
• Chromium Security: Memory safety
• Chromium Security: Rust and C++ interoperability
• Chromium Docs: raw_ptr and MiraclePtr
• Chromium blog: Efficient And Safe Allocations Everywhere (PartitionAlloc, April 2021)
• Chromium blog: A secure web is here to stay (February 2018)
• Chromium blog: No More Mixed Messages About HTTPS (October 2019)
• Chromium blog: Chrome UI for Deprecating Legacy TLS Versions
• Chromium blog: Increasing HTTPS adoption (July 2021)
• Chromium blog: Towards HTTPS by default (August 2023)
• Chrome Platform Status: HTTPS Upgrades
• Chrome release notes: Chrome 154
• Chromium blog: Announcing the Launch of the Chrome Root Program (September 2022)
• Chrome Certificate Transparency Policy
• Chrome Platform Status: X25519Kyber768 key encapsulation for TLS
• Chromium blog: Manifest V3 now available on M88 Beta (December 2020)
• Chromium blog: Manifest V2 phase-out begins (May 2024)
• Chromium blog: Faster and more efficient phishing detection in M92
• Chromium blog: Optimizing Safe Browsing checks in Chrome (February 2024)

Last reviewed: 25 October 2026. Chrome versions change every week; check the Chrome Releases blog and the Chromium release calendar for the latest.