How do you start a bug bounty at your organization? People are always asking me, so I thought I’d share what went into creating Stanford’s Bug Bounty Program.
Private vs. Public
We limited participation to students, faculty, and staff to engage the community while enhancing our security posture in a controlled way. This is considered an internal or private bug bounty program as opposed to a public program which would be open to anyone.
If the goal is to test the waters, I recommend starting with a limited number of participants. An internal program has the benefit of being easier to provision accounts and fewer submissions to handle.
If the goal is to maximize the number of reports and you’re ready for it, a public program may be the way to go.
Your necessary budget will depend on your reward amounts and attack surface. For 13 subdomains over 8 months with a reward range of $50-$1000 we paid out over $13k as you can see below. $30k/yr reward budget is a good rough estimate for a program of similar size.
We went straight for the core applications that dealt with highly sensitive data. These applications will usually be the ones that would benefit the most from this level of testing. I also recommend choosing domains that have had vulnerability scan results remediated at the very least to avoid wasting bug bounty on low-hanging fruit.
This is also the time to decide what’s not in scope. There is a standard list amongst most programs for out of scope security issues that are a good starting point as shown below. This includes activities like social engineering and denial of service (DOS).
You’ll want a reward structure that reflects the types of vulnerabilities you want to see. In our case we heavily prioritized critical vulnerabilities that could directly lead to large amounts of high risk data being leaked, so the reward levels curve up sharply.
The total range should depend on your goal for participation and budget. I recommend not paying any lower than $50 and paying at least $500 for a critical vulnerability. This will give you a large ROI, while being fair to researchers. The higher the rewards, the more participation, especially from highly skilled
As far as severity levels, ours are pretty standard for most bug bounty programs and a great detailed resource for this is BugCrowd’s open source vulnerability rating taxonomy.
Bug bounty is a relationship between your organization and those who choose to participate as bug bounty hunters. While you need to consider the risks to your own organization, you also need to consider the safety of participants. Some assurance that they aren’t putting themselves at undue risk will increase the participation, especially amongst experienced bug bounty hunters.
Take the leap! Publish your bug bounty program and get ready for those reports. There’s a myth that the existence of a bug bounty program increases the amount of bad behavior against your assets, but we never experienced this during the 8 months after launching our program.
You may also want to consider a launch event to jump start excitement and participation.
You’ll need a few people versed in web application security (or whatever your scope includes) to triage bugs as they come through. This includes validating that the bug is reproducible, determining impact, informing developers, and communicating with bug hunters.
The overall process will look something like this:
Bug submitted -> Triage -> Request fix & start payment process -> Close
Once your targets become hardened and the program has proven it’s value, you’ll naturally want to expand. You can do this by increasing scope, increasing rewards, expanding the researcher pool, community engagement, or a combination. Earlier this month we chose to double the scope of the Stanford Bug Bounty program.
I hope these tips and shared experiences will help you to start your own bug bounty program. Start small, consult your peers and internal teams (legal, HR, engineering, etc), and go for it. Bug bounty is rapidly becoming a mainstay for good reason, so start taking advantage of crowdsourced security with these tips to get you started. Feel free to reach out to me by commenting, Twitter, or LinkedIn if you’re looking to start a bug bounty program and have questions.