proposal: A security response policy for Go

[jbuberel]

As the use of Go in security-sensitive applications grows, I believe it is time that Go had a more formal policy on how security problems are handled.

We could start with the creation of a 'security@golang.org' email address that would be used to report suspected security issues. Those messages would be reviewed by a small group ("Go security review team") with a commitment to a 24-hour initial triage and review.

Based on the assessed severity of the report, the security review team would assign it to one of these categories:

• Not a security problem, and the reporter will be asked to submit a regular bug report instead.
• A security problem that should be fixed, but is not being actively exploited.
• A security problem that is being actively exploited and must be addressed immediately.

The standard Google policy, which Go would be minimally obligated to adhere to is:

• 90-days to fix regular security issues before the details can be made public
• 7-days to fix actively exploits before details can be made public

[adg]

FYI, the security@golang.org email address already exists.

It's mentioned here and in the main repo's CONTRIBUTING.md file.

[josharian]

A security problem that is being actively exploited and must be addressed immediately.

Would an actively exploited security problem in the standard library or gc toolchain thus automatically trigger a point release? Releases, even minor ones, are a fair amount of work. At the very least, I think we'd want to say something about severity here, which is orthogonal to active exploitation.

[rsc]

I think if it's not worth issuing a point release for, then it's "not a security problem" aka bullet 1.

[jbuberel]

Also note that I've omitted any mention of "early partner disclosure". This means the policy would not allow for notification of packagers or binary distributions. Based on my discussions with the security teams that put together the Chrome, Android, Dart and Angular security policies, these advanced disclosures have a very high chance of becoming public and causing more damage.

Their recommendation was simple to issue a statement, upon receipt of the security issue, that "We are planning to release version x.y.z on date YYYY-MM-DD. We recommend that all users upgrade to this release when it becomes available."

[jbuberel]

@josharian I agree that severity and urgency should be treated separately.

Perhaps something along the lines of:

Security issues will be ranked according to their severity [S1-S3]
S1 - Would allow remote execution of code or privilege escalation via running Go programs
S2
S3 - Requires modification to source to be exploited

Urgency [U1-U3]
U1 - Is being actively exploited
U2
U3 - No known exploits in the wild

Along with a guideline that a point release would normally be made for issues with either S1 or U1, or S2 and U2.

[reedloden]

See also http://www.rust-lang.org/security.html, as well as the back discussion in https://internals.rust-lang.org/t/proposed-security-disclosure-policy/2024

sparklemotion/nokogiri#1191 also has some other useful info.

[jbuberel]

Thanks for the links - give me a bit to review.

[jbuberel]

@reedloden - I definitely like the Rust policy - http://www.rust-lang.org/security.html

The python equivalent - https://www.python.org/news/security/ - is a little too glib for my liking. The WebKit policy - https://www.webkit.org/security/ - includes a process for becoming a member of the security review team, which is interesting, but probably too much for our needs (IMO).

The Xen Project - http://www.xenproject.org/security-policy.html - also contains an official embargo process, which I would prefer to avoid.

Are there others that we should be evaluating? I'm inclined to start with the Rust policy as a template, and customize slightly for Go.

[jbuberel]

@adg - could I get your arbiter stamp of approval to proceed with a first draft of a policy, based on Rust, that would eventually be hosted at:

http://golang.org/security

[reedloden]

@jbuberel, there's also http://rubyonrails.org/security/ (text seems mostly the same as some of the others [includes EOL info], though they use https://hackerone.com for submissions rather than a security@ address).

Glad to see you guys getting a policy in place. :)

[jbuberel]

@reedloden I did take a look through the hackerone.com product. I've never used it before and it does look interesting. But given that the Go project doesn't exactly have budget for bug bounties, it seems like a bit more than we need. Thoughts?

[adg]

@jbuberel LGTM for a policy based on the Rust one.

On 30 July 2015 at 11:59, Jason Buberel notifications@github.com wrote:

@reedloden https://github.com/reedloden I did take a look through the
hackerone.com product. I've never used it before and it does look
interesting. But given that the Go project doesn't exactly have budget for
bug bounties, it seems like a bit more than we need. Thoughts?

—
Reply to this email directly or view it on GitHub
#11502 (comment).

[reedloden]

@jbuberel -- HackerOne isn't just for bug bounties (seems to be a common misconception), and plenty of open source projects use the platform (for free) without paying any bounties at all. It's just a great way to manage incoming reports, interact with the researcher(s), and handle public disclosure in the end. I've always felt that security@ mailboxes are terrible, as it just makes it so difficult to keep up with things, see the current status of issues, and make sure everybody is on the same page. IMHO, the platform speaks for itself, so just take a look at some of the publicly disclosed reports on https://hackerone.com/rails to see how it works in action.

Disclaimer: I lead security for HackerOne. Doing my best not to be sales-y at all here (I truly feel the platform works great for dealing with incoming security reports). However, the main thing is just to have a defined process that works for everybody and is followed. Whether that's just some private e-mail address or use of some platform or whatever in the end.

Happy to help in any way I can... As I said, security is my full-time job, so used to dealing with this stuff and helping out other companies and OSS projects figure out something that works for them.