Interesting experiment. We (the mozilla bounty evaluation team) have paid, on a case by case basis, for vulnerabilities outside the mozilla code for things affecting any dependencies we have for Firefox 3rd party libraries, or our core development application or services websites for some time.

It might be time to make this more explicit.

The one idea that is new here is the idea about paying developers for fixing vulnerabilities in the code they work on. That could create the wrong incentives if not managed and tracked properly, setting up the possibility of writing code that's insecure, then getting paid to patch or improve that code later on.

-chofmann

On 10/10/13 3:01 AM, Gervase Markham wrote:
http://googleonlinesecurity.blogspot.co.uk/2013/10/going-beyond-vulnerability-rewards.html

Google are now paying people, retrospectively, for any patch that
improves the security of OpenSSH, BIND, ISC DHCP, libjpeg,
libjpeg-turbo, libpng, giflib, Chromium, Blink, OpenSSL, zlib and
commonly used components of the Linux kernel (including KVM).

Soon, they will also cover Apache httpd, lighttpd, nginx, Sendmail,
Postfix, Exim, GCC, binutils, llvm and OpenVPN.

This includes the core developers of those projects!

Some of this work (e.g. on libjpeg or zlib) will benefit us directly.
Other work (e.g. on OpenSSH) will benefit us indirectly, as we use those
tools and want them to be secure. However, the inclusion of
Chromium/Blink means that this program may steal potential security
contributors from Mozilla and attract them to those projects.

Can we and should we attempt to do anything about that?

Gerv
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to