Go sorts reported security issues into three tracks by impact. Public track issues have niche or limited impact and are fixed openly. Private track issues violate committed security properties and are fixed quietly, with a pre-announcement three to seven days before the scheduled release. A third, urgent track exists for the most serious cases.
The model
The Go Security Policy explains how the team handles reports. All reports go to a security email address, are acknowledged within seven days, and are fixed or made public within 90 days after the initial acknowledgement. Each issue is then categorised as PUBLIC, PRIVATE or URGENT, and all security issues receive CVE numbers.
| Track | What qualifies | How it is handled |
|---|---|---|
| Public | Niche configurations, very limited impact, or already widely known | Labelled, discussed and fixed in public, backported to the next scheduled minor releases, details in the release announcement, no pre-announcement |
| Private | Violations of committed security properties | Fixed in the next scheduled minor releases, kept private until then, pre-announcement 3 to 7 days before release |
| Urgent | Most serious cases | Described in the policy as the third category; read it for details |
The pre-announcement for private issues goes to the project's announcement list. It says there are security fixes in the upcoming releases, whether they affect the standard library, the toolchain or both, and gives reserved CVE IDs.
Why this helps downstream users
Two things stand out. First, the pre-announcement gives consumers a heads up that a release matters, so they can arrange to rebuild and deploy quickly. Second, the policy states that the categories signal how severe or wide reaching the team believes an issue to be, even without a conventional severity label.
How a small project can adapt it
You do not need three tracks and a mailing list. A short version works.
- Decide what counts as a promise your software makes, such as isolation of untrusted input or memory safety. A break in a promise is private track.
- Decide what counts as low impact or already known. That is public track, handled in the open to save effort.
- Choose a release cadence for ordinary fixes, and say it in your policy.
- For private fixes, set a short window and tell users in advance that a security release is coming, without details.
- Always request an identifier for fixes you ship, so tools can match them.
- Document an urgent path for cases that cannot wait for the schedule.
What consumers should do
Watch the project's announcement list for pre-announcements. When you see one, schedule the rebuild and redeploy for the release day. Do not wait for a scanner to flag it.
Try it yourself
Click through it at your own pace, or open it full screen. Step through the exploitability question and compare it with the idea that a project's own track tells you something about impact.
Quick check
How fast does the Go team acknowledge reports?
Within seven days, according to the policy.
Do public track issues get a pre-announcement?
No. They are in the release announcement without a pre-announcement.
Do all issues get CVE numbers?
The policy says all security issues are issued CVE numbers.
How Safeguard helps
Safeguard's zero-day discovery and dependency scanning watch for newly published issues in the components you actually use, and reachability analysis helps you judge whether your code touches the affected path. Policies and gates can hold a risky version out of a release. Autonomous remediation can open fix pull requests; it is off by default, with every category on Manual. Start with the free scan.
Sources
- The Go Project, Go Security Policy: reporting, timelines and tracks. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
