skip to Main Content
This website use cookies which are necessary to its functioning and required to achieve the purposes illustrated in the privacy policy. To learn more or withdraw consent please click on Learn More. By continued use of this website you are consenting to our use of cookies.

Evolving Bugcrowd’s Bounty Program

Evolving Bugcrowd’s Bounty Program

This post is written by Bugcrowd engineers, Paul Friedman and Daniel Trauner.

Bugcrowd is the pioneer and innovator of managed bug bounty programs, and nothing makes that more obvious than the success of our own program, which is celebrating its fifth birthday later this year.

Since our program’s launch in September 2013, we’ve received over 2,500 submissions, including almost 300 valid, rewardable vulnerabilities. Researchers have helped us identify and resolve everything from a P1 account takeover to P5 open redirects, making Bugcrowd safer for the crowd and customers. Over the past year, we’ve strived to give researchers the best experience of any program on our platform, and have since reduced our average triage, payout and remediation times to under a week. We couldn’t be more grateful for the work of the over 1,100 of you who have contributed to keeping Bugcrowd secure by participating in our program.

As our program matures, we’re taking steps to help researchers uncover even more. Today we’re rolling out the first of these improvements: a completely revamped program brief. A lot goes into writing an effective program brief, but we’ve focused on three key areas in our update to direct your attention to the things that matter and improve your overall Bugcrowd experience.

Transparent priority ratings

Even before its public launch in 2016, we’ve used our Vulnerability Rating Taxonomy as a baseline for judging the severity of the submissions we receive. While we do occasionally upgrade priority ratings for exceptionally cool or critical findings, we avoid assigning priority rating lower than the VRT’s suggestion, as the VRT should always reflect an appropriate minimum. If we find that that’s not the case, we will propose changing the categorization at our weekly Vulnerability Roundtable meeting, and gather feedback from the community on our GitHub repository.

Since we adhere so closely to the VRT, we’ve decided to call this out specifically at the top of our brief, to direct newbies and veterans to this useful resource and ensure that there are no surprises at triage time. When a researcher finds a unique, reproducible, in-scope vulnerability and submits it to us, we’ll assess its priority with the VRT and reward accordingly, or adjust the VRT itself.

And, as always, if a submission leads to us making a code or configuration change, we will always reward the researcher for their work, regardless of the VRT’s suggested priority. “Touch the code, pay the bug.”

Clearer scope

As a rapidly growing company, we rely on several third-party vendors to help us with communicating with customers, sending emails, hosting documentation, and everything in between. While we would love to accept submissions relating to these services—some of them are even Bugcrowd customers!—we’re not able to authorize testing against third-party systems, nor are we able to remediate the root cause of any such findings.

The Targets section on our new brief explicitly calls out these third parties and directs researchers to places where they can learn about their testing policies and responsibly disclose any findings. If you’re unable to contact one of these vendors about a potential vulnerability, we promise to help you get in touch with someone who can help. Of course, we are happy to consider rewarding any vulnerabilities resulting from our own misuse or misconfiguration of third-party services.

Additionally, we’ve finally formalized our long-standing policy of rewarding submissions against targets not explicitly listed in the program brief, but that you can demonstrate belong to Bugcrowd. If you find a potential vulnerability on a target that you think belongs to Bugcrowd but that target is not listed as in- or out-of-scope on our brief, you can safely report it to us for a potential reward, without any risk of losing points. If appropriate, we’ll also amend our program scope to reflect how we’ll handle future similar submissions.

Increased rewards

Finally, as an added incentive to hack on Bugcrowd, we’ve decided to increase our reward levels across the board, including new minimum rewards of $300 for P4 (low) and $10,000 for P1 (critical) vulnerabilities. We take our responsibility as stewards of our customers’ data seriously, and we think that our new reward levels reflect the seriousness of our commitment to protecting this information.

As our platform has become increasingly resilient against the more common classes of vulnerabilities, we’ve grown even more interested in seeing how creative the crowd can be. Historically, we’ve rewarded bonuses to researchers who send us especially interesting or critical findings. We’re now formalizing this practice on the brief, offering discretionary bonuses of up to 100% of the original reward for exceptional submissions.Thanks again to the entire researcher community for making Bugcrowd possible, and making our bounty program a huge success. This is just our first step towards further engaging the hacking community, and we’re excited to see what you can find. Get started hacking on Bugcrowd!

Back To Top