Live data from Hacker News

GitHub Security Bug Bounty

github.com

11–20 of 38 posts

Re: GitHub Security Bug Bounty

#11
post #5

Isn't $5000 ridiculously low compared to the black market value of a GitHub exploit, or the time required to develop it? Assuming a company thinks it's pretty secure, putting real money on the line (the same money you'd normally pay an expert to pentest your system) would get some more prolific minds involved.

Someone on the black market will almost always pay more than a company. The real value in responsible disclosure is typically from a consulting contract that may follow the report. Their leaderboard list also seems like a good way to build credibility in the community as well.

I think an ideal balance point (for all companies, not just GH) is one where someone can make a very comfortable living finding and reporting security flaws. You simply don't do that with $100-$5k bounties. GitHub, more than nearly every company out there, is entrusted with trade secrets that are the livelihood of their customers. Paying top money to get security bugs found is not an option, but something that should be regarded as a "cost of doing business".

Re: GitHub Security Bug Bounty

#12
post #9

The one obvious flaw is the "email us for our PGP key" - distributing the public key in private and over an insecure channel makes it vulnerable to replacement. Has anyone written a "best practices" guide for designing a security page ?

In theory, PGP public keys shouldn't depend on being sent over a more-secure medium like SSL, because they're signed. One of the main points of PGP's design is that you can't spoof a public key, because you can't spoof its signatures.

That being said, in practice, I don't know that everyone is diligent about checking signatures of public keys they receive. An attacker could create a spoofed key, sign it with several other identities controlled by the attacker, and hope those signatures are enough to fool the unweary.

Re: GitHub Security Bug Bounty

#13
post #7
post #3

Earlier quoted context omitted.

Bug bounties are rarely competitive with their black-market value. I think in most cases they're intended more as a "thanks!" than a "please don't hack us".

You're sort of just re-stating the question. I think everyone understands that's the way things are. The OP is saying that the way things are doesn't make much sense. My guess is that the thinking goes something like this: White hats aren't going to hack us anyway, and will be fine with the tiny rewards we give them. So there's no reason to increase the rewards for them. Black hats probably aren't going to be dissuad…

I doubt it. Why wouldn't github want to pay more so that black hats also sell them bugs? Indeed, these are the very bugs that are going to be exploited, so it makes perfect sense for them to pay whatever it costs.

The real reason is probably: because nobody else does. I think it is doubtful black hats would sell their bugs to github unless github was paying 2-3 times the market rate, since the black hat can sell the same bug to multiple people.

Re: GitHub Security Bug Bounty

#14
Great to see Github recognizing processes for security researchers between the ages of 13-18 in the FAQ. In the new age of crowdsourced skills, it's good to see age not playing a part as a barrier.

Re: GitHub Security Bug Bounty

#15
post #9

The one obvious flaw is the "email us for our PGP key" - distributing the public key in private and over an insecure channel makes it vulnerable to replacement. Has anyone written a "best practices" guide for designing a security page ?

Why don't they just publish the key on the site?

Re: GitHub Security Bug Bounty

#18
post #9

The one obvious flaw is the "email us for our PGP key" - distributing the public key in private and over an insecure channel makes it vulnerable to replacement. Has anyone written a "best practices" guide for designing a security page ?

Why don't they just publish the key on the site?

They should.

Re: GitHub Security Bug Bounty

#20
post #9

The one obvious flaw is the "email us for our PGP key" - distributing the public key in private and over an insecure channel makes it vulnerable to replacement. Has anyone written a "best practices" guide for designing a security page ?

Why don't they just publish the key on the site?

Probably because security@ emails are routed through their normal helpdesk system which doesn't handle PGP properly.
Post reply on HN