“Do what’s best for the job seeker.” This has been Indeed’s guiding principle since the beginning. One way we put the job seeker first is by keeping their information safe and secure. We always consider the security of our systems as we develop the services that millions of people use every day. But someone will outsmart us. Hackers are always trying out new ways of bypassing security and gaining access to systems and information. Our challenge: to bring these security experts over to our side and benefit from their findings.
Image by stockarch – stockarch.com (Licensed by Creative Commons)
Our answer to this challenge is, well, money. Actually, money and fame. Indeed offers security testers a legitimate route to reporting their findings, and we award them for their time with cold, hard cash and recognition. Through our bug bounty program we have awarded over 300 submissions in the past year and a half, with payouts as high as $5,000 for the most severe bugs. Our most successful participants (looking at you, Angrylogic, Avlidienbrunn, and Mongo) have earned cash while building their reputations as highly regarded testers for Indeed.
| Reward amount per submissions in the last 18 months | ||
| Criticality | Reward Amount | Relative Submission Counts |
| CRITICAL | Up to $5000 | 0.7% |
| HIGH | Up to $1800 | 4% |
| MEDIUM | Up to $600 | 31% |
| LOW | Up to $100 | 64% |
Why create this program?
Prior to our bug bounty program, we occasionally received messages that sounded like blackmail. An anonymous person would contact us, insisting that we pay them, or they would publicly release the details of an unspecified, but totally serious, security bug. These individuals expected payment up front, with no guarantee that they even had a bug to expose. While we’re happy to compensate researchers for helping us improve our services, we didn’t want to encourage this coercive behavior. It felt wrong.
To solve the mutual distrust, we started using Bugcrowd.com as an impartial arbiter. On Bugcrowd, security researchers are more willing to provide evidence up front, giving us the chance to fairly assess the bug’s severity. Indeed can now provide rewards without abuse, and everyone lives happily ever after…
Theory vs practice
“Happily ever after…” is more difficult in practice. Since the program started, we have received almost 2,500 submissions, each issue potentially taking hours to validate. Every time we advertise our bounty program or raise our payouts, we see a large spike in submissions. To an outsider, it might look like we’re dragging our feet, but in reality, it’s all hands on deck to reply to these submissions. This blog post alone will generate several more hours worth of bug validation thanks to the increased visibility of the program.
We initially struggled to quickly respond to testers’ submissions, creating a backlog. This backlog grew because we received more submissions than we had time to process. We ended up doubling down on our efforts over a painful couple of weeks and then implementing a new standard for response time. Since then, response times have been under control.
Sum of open Ticket Days over Time
| Note: The value of Ticket Days is the sum of days that every ticket is open on a particular date. For example, on a given date, one ticket open for 3 days + one ticket open for 2 days = 5 Ticket Days. |
Communicating clearly with the researchers is also important, so that they don’t think we are trying to take advantage of them. We keep in mind that they don’t have as much visibility into the process as we do. One common issue is handling duplicates. Paying for an issue the first time you hear about it makes sense, but how should we handle a duplicate submission from another researcher? The second submission doesn’t add any additional value, but from the tester’s point of view, they found a real bug. Clearly communicating why you are marking a ticket a duplicate and quickly fixing identified issues helps minimize this concern. In some cases, we decide to pay for the duplicate if it has great reproduction steps and a proof of concept.
Finally, we’re working on balancing the time we spend finding new bugs and fixing known bugs. Building and managing a popular bounty program leads to lots of good submissions, but that all falls to pieces if we don’t also spend the time fixing the bugs. At Indeed, the benefits of investing time improving our bug bounty program can’t be overstated.
Our successes so far
It seems we’re doing something right. Bugcrowd recently asked their security researchers which company’s program was their favorite, and you’ll never guess who won!
…Tesla won (we blame those fabulous Teslas). But we took runner up, with 8% of all votes, racing against over 35 other programs. Many of the specific responses for our program referenced our fair payout practices, great communication, and permissive scope. While we know that we can still rev up the experience, we are happy for the validation that we are headed down the right road.