Go sorts security issues into three tracks. Low impact or already known issues go on the PUBLIC track and are fixed in the open with no pre-announcement. More serious ones take the PRIVATE track with a pre-announcement. The most severe take the URGENT track and may have none.
The three tracks
The Go security policy defines them as follows.
| Track | What it covers | How it ships | Warning to users |
|---|---|---|---|
| PUBLIC | Niche configurations, very limited impact, or already widely known | Fixed in public, backported to the next scheduled minor releases, which occur about monthly | Release announcement includes details, no pre-announcement |
| PRIVATE | Violations of committed security properties | Fixed in the next scheduled minor releases, kept private until then | Pre-announcement to golang-announce three to seven days before |
| URGENT | Issues actively exploited in the wild leading to severe damage | Fixed in private, immediate dedicated security release | Possibly no pre-announcement |
Public issues carry a label in the tracker and are discussed through the proposal review process, per the policy. That is why you may see a fix land in a public issue before any release exists.
What it means for your process
You cannot assume a warning will come. Plan for three rhythms:
- Monthly: scheduled minor releases carry both PUBLIC and PRIVATE fixes. Build a monthly habit of reading the release announcement and upgrading the toolchain.
- Pre-announced: when a notice appears, follow the steps in our post on what to do when a security release is pre-announced.
- Urgent: keep the ability to upgrade and redeploy within a day. That means build pipelines that work and a way to find every binary built with a given toolchain version.
The toolchain question
Go releases cover the standard library and the toolchain, and the pre-announcement says which are affected. A compiled Go binary includes the standard library from the toolchain used to build it. So a fix in the standard library means you need to rebuild, not just update a dependency file. Keep an inventory of which toolchain version built each service.
Reading a public issue
If you spot a security labelled issue in the tracker:
- Read what is affected and the stated impact.
- Check whether your code uses the affected package or function.
- Note the milestone or release where the fix is planned.
- Decide whether to wait for the monthly release or apply a workaround.
Because these are public, so is the information an attacker needs. That is the reason the track is for low impact or already known issues.
What the policy does not promise
The policy describes the project's process. It does not guarantee that an issue fits neatly into one track, or that no unlisted issue exists. Use it as a model of expected behaviour and keep independent scanning for what you build.
Where Safeguard fits
Safeguard's SBOM and dependency scanning records the versions you build with, so a standard library advisory maps back to services that need a rebuild. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a fresh disclosure is mapped to affected inventory without a pre-announcement.
Quick check
Does every Go security fix get a pre-announcement?
No. The policy says PUBLIC track issues have none, and URGENT issues may have none.
How often are scheduled Go minor releases?
The policy describes them as occurring about monthly.
Sources
Last reviewed: 19 October 2026.
