Transparency between hackers and security teams is vital to a successful bug bounty program. The “front door” for hackers to any bug bounty program is the security page, which commonly contains your disclosure policy, rules of engagement, scope, and other important information. Twitter, Uber, Snapchat, Coinbase, and Mail.ru (among many others!) have great security pages that incorporate elements outlined in this guide.
Benefits of having a rock solid security page include:
- …steering hackers towards the scope and vulnerabilities you care most about
- …setting clear expectations around bounty pricing and timelines
- …garnering more trust (and participation!) from top hackers
Rule #1 – Have a well-defined scope!
The lack of a well-defined scope is one of the biggest sources of fallouts in bug bounty programs. Outlining a crystal clear scope helps hackers know what is (and is not!) going to net them a bounty. “Scope,” in this context, is defined as the various web sites, APIs, mobile apps, etc. that you’d like people to hack on (or explicitly avoid!).
For a moment, let’s imagine things from the hacker’s perspective. It’s Sunday, you’ve spent 8-10 hours hacking on a site, uncovered 12 XSS bugs, taken the time to write them all up as separate reports with repro steps, screenshots, etc. On Monday afternoon, you get 12 emails telling you every single XSS is on a site which is out of scope for the program, and do not qualify for a bounty. Imagine how that feels! It’d be like a punch in the gut; you wasted an entire day trying to help improve someone’s security and are expecting bounties for your hard work, but you get nothing. Nada. And the fact that this site wasn’t in scope wasn’t even listed on the company’s security page! I’d be pretty upset; wouldn’t you?
Fortunately, these types of situations can be easily avoided by defining your scope on your security page. We highly recommend outlining both what is in scope, as well as what is explicitly out of scope. Uber does a great job of defining what’s in scope, as well as defining what vulnerabilities they care about most in each (more on that in rule #2 below), in their Treasure Map.
In terms of outlining what’s out of scope, that’ll depend greatly on your organization.
For example, did you recently acquire a company that has their own attack surface, but didn’t have a bug bounty program (or maybe even a security team)? You’ll likely want some time to get your house in order before opening up the bug bounty floodgates. Before adding an acquisition to your scope, you should ensure there’s a vulnerability management process in place for it, and that you’ve had a chance to take care of any obvious security issues that you’d find through your normal processes.
Be proactive! Add language to your security page that states “recent acquisitions will be considered out of scope for a period of X months from the date of the acquisition” to give yourself some breathing room, get the acquisition “bug bounty ready,” and then introduce them into the scope of your bounty program. If you’re able to, explicitly list any new scope that came along with the recent acquisition in your “out of scope” section, perhaps even indicating the date and time at which these properties will come into scope. Transparency is key!
Rule #2 – Where’s the money at?
Okay – now that you’ve communicated what is fair game for hackers to look for bugs in, you need to figure out how much these various bugs are worth to you. It is important to clearly communicate this on your security page. Money talks! Determining what criteria you’ll use to help inform bounty decisions is vital to demonstrating to hackers what bug reports will be most valuable to you. In other words, telling hackers “I’ll pay a super high amount for XSS on websites that maintain state and house sensitive functionality” and “I’ll pay very little (or nothing!) for clickjacking on a website with only static content” is your way of ensuring hackers can most efficiently and effectively allocate the time they spend on your program, and that you’ll see more reports coming in on the areas that matters the most to you. Clearly communicating your bounty pricing model is a win for everyone! Twitter does an excellent job of this by detailing minimum expected bounties based on vulnerability type and what part of their infrastructure is affected.
Alright, so how do you actually go about doing this? Your first step should be take some time and review the scope you’ve already sketched out to identify which properties are the most important to you. What houses the most sensitive data and functionality? Second, you’ll want to juxtapose this across various common vulnerability types and figure out which vuln types are the most impactful depending on the context of each property. Clickjacking on a static marketing website… meh. Clickjacking on your account settings page? That’s a whole ‘nother story. Third, you’ll want to decide if any other criteria will feed into your bounty decisions (e.g. ease of exploitability, particularly interesting or clever finds, etc.). Last, clearly describe how all of these criteria play into your bounty decisions on your security page. A simple bounty table to graphically display this to hackers, along with some text describing your bounty pricing criteria, is highly recommended. “Bounty pricing criteria” varies from organization to organization, but in general you should try to be as transparent as possible on the process you use for determining how much various reports will be worth. See Uber’s “Rewards” section for a great example of explaining rationale behind how their bounties are determined.
Rule #3 – To vuln, or not to vuln, that is the question
Alright, so really this is almost a subset of rule #2 (where’s the money at?)… but in addition to highlighting the types of vulns that are really important to you by attaching cash amounts to them, it’s best practice to explicitly outline the types of vulnerabilities that will (and will not!) qualify for your program. There may be some types of vulnerabilities you explicitly do not want hackers to go after. Having a section for qualifying vulnerability types gives you another chance to outline the types of vulns you care most about, as well as give hackers a laundry list of what they should be targeting during their research. Having a section for non-qualifying vulnerabilities helps hackers not waste time on things you don’t care about, or things you may already be aware of, but are so low risk that you consider it as a known issue not worth fixing.
Especially for new programs, a non-qualifying section can be a huge saving grace when it comes to replying to reports which may not be important to you. Proactive hackers will see this and avoid submitting these types of reports in the first place, resulting in noise reduction for your program. For hackers that submit these types of reports anyway, being able to point to your non-qualifying vulnerabilities section on your security page makes it easier to rationalize why you are closing the report.
Word of warning: I highly recommend not using “non-qualifying vulnerabilities” to “outlaw” any issues that have a readily apparent security impact. For example, I wouldn’t ban XSS submissions across an entire program if it has websites that store session info and have state-changing functionality. Unless a solid explanation is giving as to why legit vulns are not in scope, it will look like the organization is turning a blind eye to them. If you’re in a spot where you’re getting tons of legitimate reports on a certain vuln type and can’t keep up with the volume, there are other ways to better handle this than banning the vuln type; feel free to reach out to support@hackerone.com for advice.
Rule #4 – Service Level Agreements
As weird as it may sound, having a bug bounty program is akin to offering a service. You’re claiming that you will acknowledge reports that come in, review them to determine if they have a legitimate security impact, provide compensation accordingly, and take action to fix reported issues. As with any service, it’s important to set the tone of the conversation by proactively describing at what level you’ll be able to provide this service, and under what circumstances. In other words, you should communicate to hackers what they can expect when using your “service”. Again, it’s helpful to consider this from the hacker’s perspective:
- If I send a bug report in, when can I expect an initial response by? Even if it’s just “thanks, we’ll look into this”?
- How long does it normally take the team to let me know if a report will be taken into consideration for the program, or is a complete non-issue or out of scope?
- If it qualifies, when will I get my bounty, and what will the amount be?
- Cool, I’ve got a bounty… but when will the issue be fixed? Can I blog about the bug I reported? When?
So to answer these questions, you have a few options:
- Wait until hackers ask your security team, then answer one by one (and potentially even provide an inconsistent answer depending on who replies!)
- Do nothing, then find out after the fact that a hacker blogged about a vuln because they felt one week was too long to wait with no response
- Proactively answer all of these questions to the best of your ability in your security page and avoid these types of situations
I don’t know about you, but my money is on #3. Proactively addressing these questions in your security page is the best way to ensure hackers know what to expect when interacting with your bug bounty program, resulting in less mismatched expectations and potential conflicts. Here’s an example of how you could outline these expectations in your security page:
Explicitly setting guidelines for your security team around response times not only helps build trust with hackers (resulting in more participation from top talent!), but it also establishes clear goals for your team to commit to in order to keep your bounty program humming along smoothly, as well as to keep yourselves honest. HackerOne offers program metrics that automatically display data on your security page around response efficiency (average time to first response, average time to resolution, and average time to bounty). Clearly stating your SLAs on the same page which displays your actual stats is great incentive to “stick to it,” and shows hackers that you are publicly committing to your SLAs.
You may also want to include text around when the bounty will be paid. Paying the bounty as soon as you’ve validated the issue is highly preferred, as it doesn’t “block” the hacker from receiving payment for their contribution based on your remediation timeline, which is outside of their control. HackerOne recommends paying out as soon as you validate the report based upon the maximum impact. At a later time (e.g. while fixing the bug) you realize that the bug was even higher impact than initially thought, you can always go back into the report and award an additional bounty to make up the difference. While this seems like a small step, this is greatly appreciated by hackers and helps bring your program from “meh” to “AWESOME,” resulting in happier hackers and better participation.
Rule #5 – Eligibility
You’ve set some expectations for yourself, it’s only fair that you can set some expectations for the hackers participating in your program as well :). Eligibility is a fairly broad term, and there’s a lot you could put in here, but there’s a balance to be struck between how strict you are vs. how likely it is you’ll get consistent participation from a wide variety of top notch hackers. On one hand, having no section outlining requirements for eligibility to participate in your program may result in a wild west situation. On the flip side, having incredibly strict eligibility requirements may result in little to no reports coming in. Ultimately, how you structure this section is up to you, but here is an example with some common elements that may work to your benefit:
Depending on the nature of your company, you may have more (or less!) requirements, but again, please remember the balance of “too strict / less participation” vs. “not strict enough / too much participation of the wrong type”. Whatever you do, remember to be transparent by clearly explaining all eligibility requirements. Additionally, publicly disclosing resolved reports is a great way to highlight examples of hackers who “got everything right” by abiding by the various eligibility requirements. You can even link to some real example reports in this section to give hackers an idea of what you’re looking for.
Wrapping it up
Hopefully these “rules” helped you spin up a brand new, rock solid security page, or perhaps helped you make a few tweaks to an existing one. Following these tips will greatly increase the quality of your security page, helping increase transparency with hackers, which will result in smoother relationships and higher quality reports.
Do you have other tips or examples of great security pages? If so, let us know by emailing us at feedback@hackerone.com!
Adam Bacchus
HackerOne is the #1 hacker-powered security platform, helping organizations find and fix critical vulnerabilities before they can be criminally exploited. As the contemporary alternative to traditional penetration testing, our bug bounty program solutions encompass vulnerability assessment, crowdsourced testing and responsible disclosure management. Discover more about our security testing solutions or Contact Us today.