This document explains the Go Security team's process for handling issues reported and what to expect in return.
All security bugs in the Go distribution should be reported by email to security@golang.org. This mail is delivered to the Go Security team.
To ensure your report is not marked as spam, please include the word “vulnerability” anywhere in your email. Please use a descriptive subject line for your report email.
Your email will be acknowledged within 7 days, and you'll be kept up to date with the progress until resolution. Your issue will be fixed or made public within 90 days.
If you have not received a reply to your email within 7 days, please follow up with the Go Security team again at security@golang.org. Please make sure the word vulnerability is in your email.
If after 3 more days you have still not received an acknowledgement of your report, it is possible that your email might have been marked as spam. In that case, please file an issue here. Select “I want to report a technical security or an abuse risk related bug in a Google product (SQLi, XSS, etc.)”, and list “Go” as the affected product.
Depending on the nature of your issue, it will be categorized by the Go Security team as an issue in the PUBLIC, PRIVATE, or URGENT track. All security issues will be issued CVE numbers.
The Go Security team does not assign traditional fine-grained severity labels (e.g CRITICAL, HIGH, MEDIUM, LOW) to security issues because severity depends highly on how a user is using the affected API or functionality.
For example, the impact of a resource exhaustion issue in the encoding/json parser depends on what is being parsed. If the user is parsing trusted JSON files from their local filesystem, the impact is likely to be low. If the user is parsing untrusted arbitrary JSON from an HTTP request body, the impact may be much higher.
That said, the following issue tracks do signal how severe and/or wide-reaching the Security team believes an issue to be. For example, an issue with medium to significant impact for many users is a PRIVATE track issue in this policy, and an issue with negligible to minor impact, or which affects only a small subset of users, is a PUBLIC track issue.
Issues in the PUBLIC track affect niche configurations, have very limited impact, or are already widely known.
PUBLIC track issues are labeled with Proposal-Security, discussed through the Go proposal review process fixed in public, and get backported to the next scheduled minor releases (which occur ~monthly). The release announcement includes details of these issues, but there is no pre-announcement.
Examples of past PUBLIC issues include:
Issues in the PRIVATE track are violations of committed security properties.
PRIVATE track issues are fixed in the next scheduled minor releases, and are kept private until then.
Three to seven days before the release, a pre-announcement is sent to golang-announce, announcing the presence of one or more security fixes in the upcoming releases, and whether the issues affect the standard library, the toolchain, or both, as well as reserved CVE IDs for each of the fixes.
Some examples of past PRIVATE issues include:
URGENT track issues are a threat to the Go ecosystem’s integrity, or are being actively exploited in the wild leading to severe damage. There are no recent examples, but they would include remote code execution in net/http, or practical key recovery in crypto/tls.
URGENT track issues are fixed in private, and trigger an immediate dedicated security release, possibly with no pre-announcement.
If you believe that an existing issue is security-related, we ask that you send an email to security@golang.org. The email should include the issue ID and a short description of why it should be handled according to this security policy.
The Go project uses the following disclosure process:
Once the security report is received it is assigned a primary handler. This person coordinates the fix and release process.
The issue is confirmed and a list of affected software is determined.
Code is audited to find any potential similar problems.
If it is determined, in consultation with the submitter, that a CVE number is required, the primary handler will obtain one.
Fixes are prepared for the two most recent major releases and the head/master revision. Fixes are prepared for the two most recent major releases and merged to head/master.
On the date that the fixes are applied, announcements are sent to golang-announce, golang-dev, and golang-nuts.
This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however it's important that we follow the process described above to ensure that disclosures are handled consistently.
For security issues that include the assignment of a CVE number, the issue is listed publicly under the “Golang” product on the CVEDetails website as well as the National Vulnerability Disclosure site.
The best way to receive security announcements is to subscribe to the golang-announce mailing list. Any messages pertaining to a security issue will be prefixed with [security].
If you have any suggestions to improve this policy, please file an issue for discussion.