Now there is nothing to hax.
You should ask them to apply it retroactively.
GitHub Security Bug Bounty
31–38 of 38 posts
Re: GitHub Security Bug Bounty
#32Isn'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.
No, it is probably not. People have weird ideas about how much random web bugs are worth. Big ticket bugs are easily monetizable, and/or attack a huge install base with a very slow patch cycle. People hear about 5-6 figure bugs, but those are typically reliable browser clientside RCEs.
Re: GitHub Security Bug Bounty
#33Hey githubbers, could you please stop repeating the tired "responsible disclosure" meme? Full disclosure is not irresponsible and attempts to frame it as such are bordering on malicious toward the exact community in which you are attempting to engender goodwill.
Software development is hard. Most projects are developed by teams- not single contributors. Consequently, part of reporting bugs is enduring the back and forth of communications with teams. Reporting bugs is not an all-or-nothing game.
Re: GitHub Security Bug Bounty
#34Isn'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.
I argue that bug bounties are a pressure release valve for people who know that there's a problem, but are unsure if they're at risk of getting lawyer'd or prosecute'd for disclosing vulns.
No private entity can compete with nation states for vulnerability rewards.
Re: GitHub Security Bug Bounty
#35Hey githubbers, could you please stop repeating the tired "responsible disclosure" meme? Full disclosure is not irresponsible and attempts to frame it as such are bordering on malicious toward the exact community in which you are attempting to engender goodwill.
I disagree that "responsible disclosure" is tired, nor a meme. Software development is hard. Most projects are developed by teams- not single contributors. Consequently, part of reporting bugs is enduring the back and forth of communications with teams. Reporting bugs is not an all-or-nothing game.
However by any reasonable definition [1] it is a meme, being a "unit for carrying cultural [...] practices that can be transmitted [...] through writing [or] speech." Remember that memes existed as a concept long before LOLcats and formulaic GIF images with amusing text macros on the Internets...
[0] http://www.wiretrip.net/p/libwhisker.html
[1] https://en.wikipedia.org/wiki/MemeRe: GitHub Security Bug Bounty
#36Earlier quoted context omitted.
I disagree that "responsible disclosure" is tired, nor a meme. Software development is hard. Most projects are developed by teams- not single contributors. Consequently, part of reporting bugs is enduring the back and forth of communications with teams. Reporting bugs is not an all-or-nothing game.
It certainly isn't tired, and "responsible disclosure" policies are absolutely preferred over any sort of free-for-all distribution and posting of PoC code to the world before the vendor. I think most professional security researchers have always subscribed to the general idea of responsible disclosure of vulnerabilities, even before things like RFPolicy [0] brought the concept to a wider audience. However by any rea…
The problem is that use of the phrase "responsible disclosure" FRAMES anything that does not conform to that narrow definition as "irresponsible disclosure", when in reality it simply is not. (It is not irresponsible to pull a @homakov, for instance.)
It's "framing": a way that use of language shapes our thinking about the world and events therein, sometimes and usually without our explicit conscious consent to such bias.
Please stop using the term. "Advance developer/vendor notification" is a suitable replacement if you wish.
Re: GitHub Security Bug Bounty
#37Earlier quoted context omitted.
It certainly isn't tired, and "responsible disclosure" policies are absolutely preferred over any sort of free-for-all distribution and posting of PoC code to the world before the vendor. I think most professional security researchers have always subscribed to the general idea of responsible disclosure of vulnerabilities, even before things like RFPolicy [0] brought the concept to a wider audience. However by any rea…
My problem is not with companies preferring advance notice, or with people who abide by what is called "responsible disclosure". Indeed, it is often the Right Thing To Do. The problem is that use of the phrase "responsible disclosure" FRAMES anything that does not conform to that narrow definition as "irresponsible disclosure", when in reality it simply is not. (It is not irresponsible to pull a @homakov, for instanc…
On the one hand, I concede your point. I think your phrasing is certainly more accurate. However it isn't quite as expressive to the layman.
On the other hand, there are so few people out there who truly can grasp the nuances that you're focusing on, I am wary of propogating your valid point.
I still think "responsible disclosure" is a better (albeit damaged) descriptor.
Re: GitHub Security Bug Bounty
#38Great news. I'm happy to see this program in "public mode" now. GitHub launched this program already as private beta in May 2013. https://twitter.com/totally_unknown/status/42899282447475916... Don't expect to earn easy cash here. :)
I wonder if the reward values have changed since the beta? I'm sure it is much harder to find anything now than it would have been back then, assuming they got a good turnout from really experienced people and 7-8 months of headstart.
"We are using a simple severity ranking scheme: Low - Medium - High - Critical. Rewards range from $100 up to $5000 and are determined at our discretion based on a number of factors. For example, if you find a reflected XSS that is only possible in Opera, and Opera is only 1.64% of our traffic, then the severity and reward will be lower. But a persistent XSS that works in Chrome, at 59.53% of our traffic, will earn a much larger reward."