Each major Go release is supported until there are two newer major releases. Critical fixes, including security fixes, ship as minor revisions for supported releases. In practice that means you should be on one of the two newest majors, and you have about one release cycle of slack after a new one ships.
The rule from the release page
The Go release history page states the policy directly: each major Go release is supported until there are two newer major releases. It gives the example that Go 1.5 was supported until the Go 1.7 release. Critical problems, including critical security problems, are fixed in supported releases as needed through minor revisions such as 1.6.1.
The page lists each current release with its date and minor revisions. Read it for the newest version numbers, since they change.
What the rule implies
With two newer majors needed before a release lapses, the supported set is always two releases. When a new major arrives, the older of the two drops out, and the one before it becomes the oldest supported.
| Moment | Supported set |
|---|---|
| Before a new major | Newest and one before it |
| The day a new major ships | New one and the previous one; the oldest drops |
So the question for any service is simple: is my version one of the newest two? If not, security fixes are no longer being issued for it.
Why this matters more for compiled languages
A Go binary carries its standard library with it. A vulnerability fixed in the standard library only reaches you when you rebuild with a fixed toolchain. Updating the base image or the OS packages does nothing for a statically linked binary. That makes the toolchain version a real part of your security posture, and a thing to record.
Record it in two places: the go directive in your module file, and the toolchain used by your CI builds. Treat a mismatch as a bug.
A cadence that keeps you supported
- Pick a target of the newest release, or one behind it if you need a soak period.
- Run a CI matrix over the minimum version you support and the newest. Libraries should test both. Services only need their one production version.
- When a new major ships, upgrade the CI toolchain first and look for new vet or test failures.
- Move the service in a small pull request that changes only the toolchain, with the release notes linked.
- Roll out through your normal stages and then watch error rates.
- After a minor revision with a security fix, rebuild and redeploy, even when no source changed.
That last step is the one teams miss. If the fix is in the toolchain, your repo has no diff and your scanner may have nothing to say about source. Your build must pick the fix up.
Libraries versus services
A library author chooses the oldest Go version they will support and tells users. Choosing only the newest two is a clean policy that matches the project. Choosing older versions widens reach but means you cannot use newer language features and may ship against toolchains that no longer get fixes. State the choice in your readme.
Quick check
Is the previous Go release still supported when a new one ships?
Yes. The release is supported until two newer major releases exist, so the previous one remains supported until the next one arrives.
Do OS updates fix a Go standard library vulnerability in my binary?
No. The standard library is built into the binary, so you need to rebuild with a fixed toolchain.
Safeguard scans dependencies and builds SBOMs so you can see which toolchain and modules each service shipped with. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
