Going beyond vulnerability rewards(googleonlinesecurity.blogspot.ca)
googleonlinesecurity.blogspot.ca
Going beyond vulnerability rewards
http://googleonlinesecurity.blogspot.ca/2013/10/going-beyond-vulnerability-rewards.html
6 comments
What's really cool about this, is that it looks like it applies to more than just security fixes i.e. Qualifying submissions - Any patch that has a demonstrable, significant, and proactive impact on the security of one of the in-scope projects will be considered for a reward. Examples include:
[1] https://www.google.com/about/appsecurity/patch-rewards/
Improvements to privilege separation,
Memory allocator hardening,
Cleanups of integer arithmetics,
Systematic fixes for various types of race conditions,
Elimination of error-prone design patterns or library calls.
[1] https://www.google.com/about/appsecurity/patch-rewards/
I suppose these are likely to be security fixes, but it's really nice to see a change in attitude. You can have fixed a security bug before anyone knows it exists by fixing up areas of code likely to contain bugs.
This also widens the group of people who can submit fixes, since you can fix something that looks a bit dodgy without having to prove there is a particular exploit.
This also widens the group of people who can submit fixes, since you can fix something that looks a bit dodgy without having to prove there is a particular exploit.
It's a very nice program and can only lead to good things, but the relatively modest rewards aren't exactly likely to bring openssh 0days into the light :)
Earlier discussion (of the same post): https://news.ycombinator.com/item?id=6523434
Ah, the wonders of multiple country-code TLDs for the same blogspot page (also submitted under Australia)
Ah, the wonders of multiple country-code TLDs for the same blogspot page (also submitted under Australia)
I didn't see the earlier post.
Google's going to pay for GCC toolchain improvements?
Good for them.
But a normal company would go broke doing these kinds of things.
Good for them.
But a normal company would go broke doing these kinds of things.
Maybe. They've got a lot riding on these things being secure, a bit of money now is probably a lot better than lots of money later. A lot of companies probably have the same risk/reward, but can't place it neatly in a budget.
This may also be part of reaching out to developers, and gaining some trust back. They've probably taken quite a hit recently, and I think they've somewhat relied on being the cool place to work.
This may also be part of reaching out to developers, and gaining some trust back. They've probably taken quite a hit recently, and I think they've somewhat relied on being the cool place to work.
Aren't they worried that people will inject open-source vulnerabilities for free, then have Google to pay them when they are "found" and "fixed"?
According to the page, fixing individual vulnerabilities won't typically be rewarded. This seems like it's for more systemic fixes, like improving privilege separation, security at the memory allocation level, etc.
It would be great if they could add Django, RoR, and Node/Express.js to improve their security proactively. They can definitely use that :-)
I love that the Max reward is $3133.7 dollars. Made me chuckle.
It would be very surprising if this didn't lead to a few new BIND and ISC DHCPD bugs coming out in the near future.