Everything About Launching and Managing Your Bug Bounty Program (From a Former Triager)

Bug bounty has been a hot topic in security for many years. While some may think it’s over-hyped, I believe it’s even underrated. Many companies still don’t realize the value they can derive from it. As a former triager for HackerOne, a part-time bounty hunter, and a bug bounty program manager, I’ve seen many massive data leaks prevented thanks to bug bounty programs.

Companies often spend significant amounts on vulnerability scanners and other security software. While these tools can be useful, they sometimes fail to find anything useful or become difficult to maintain. As a result, you might not receive any value for your investment. However, this isn’t the case with bug bounties. They represent a unique area in security where you always get value for what you pay for.

Some might disagree with me. Perhaps you didn’t find any value in your bug bounty program, or you exhausted a lot of money quickly. This can happen if you’re unsure of what you’re doing. I’ve seen such cases too. I’ve prepared this document to give some pro tips to maximize the benefits of your program.

Why Do We Need a Bug Bounty Program if We Already Have Penetration Tests?

This is a common question I encounter often. While penetration testing can be useful and is sometimes mandatory for compliance purposes, I must admit that it is not as beneficial as a bug bounty program. The reasons for this are not entirely clear to me. There could be sociological factors at play, but here are my thoughts:

Firstly, penetration testing is not a continuous action. It is typically carried out every six months or yearly. If a vulnerability is introduced during that period, it may be overlooked.

Secondly, bug bounty hunters often find more better vulnerabilities than regular penetration testers. It can be surprising how a 16 years old kid can find better vulnerabilities than an experienced security professional. The answer isn’t straightforward. Firstly, penetration testing is similar to football. Younger people typically have more dedication and energy than a highly experienced 35-year-old.

Moreover, many bug hunters are living in developing countries. For instance, the minimum wage in Turkey is $550. A bug hunter can earn this amount by finding just two XSS issues. Imagine the level of dedication that would inspire. However, a penetration tester’s salary remains the same, regardless of the vulnerabilities they find.

And the last thing could be: penetration testers have limited time to work on an application. But bug bounty hunter practically have unlimited time.

Before Starting Your Bug Bounty Program

Before you start your bug bounty program, you need to make sure that your organization is mature enough. What does it mean? Some hackers will use automation to find low hanging fruit vulnerabilities while others will dig deep into your applications to find more complex vulnerabilities. You have to make sure that you are eliminating low hanging fruits by yourself. You may ask “If I will do all my security work, why the hell I’m paying for a bug bounty program”. Actually, you are not wrong if you have a massive budget for your program. But usually this is not the case. If you don’t want to deplete your budget within two weeks, you need to some basic hygiene checks.

How will you do it? Actually, it’s not hard thing to do. You need to use the same tools that hackers use on their automation.

Reconnaissance and Inventory Creating

Title may scare you. You can say that “I have to talk with 10 different teams for that”. However, you’re still thinking with a corporate mindset. We will adopt the approach of hackers in order to simplify our tasks.

If all your domains and subdomains are housed in a single location like Cloudflare or AWS, retrieve them and store them in a location of your choice. This could be a DynamoDB or a simple text file. To enumerate more subdomains, use the subfinder tool. There might be subdomains you aren’t aware of just hanging out there.

Run the httpx tool against these subdomains to determine which ones are active. The httpx tool also provides useful information about websites, such as their titles. Examine the active hosts and assess whether they need to be public or serve any purpose. You might discover things that should be private or some test applications. Remove any subdomain that doesn’t need to be there.

Use the Naabu port scanner to find open ports for these applications. You can also perform a port scan for your IPs that don’t use a domain name. Ideally, any port other than 80 or 443 should not be public. Review the open ports, identify if you are exposing any unnecessary ports, and close them.

Vulnerability Scan

nuclei is the holy grail of bug bounty world. Even it’s a free and open source scanner, in most cases it finds better vulnerabilities than paid solutions. It almost doesn’t produce false positives. Nuclei is regularly updated with various rules contributed by the community. However, it should not be confused with a web application scanner like Burp Suite or Invicti. Nuclei won’t identify custom vulnerabilities in your unique applications but will use its signatures to detect known CVEs.

Another advantage of Nuclei is its ability to spot configuration errors such as forgotten backup files, exposed git repositories, or subdomains vulnerable to takeover. It’s recommended to run Nuclei weekly to identify and address high and critical vulnerabilities. Even if it doesn’t detect any high or critical severity issues, it can still provide valuable insights about your hygiene through medium severity issues.

Dynamic Application Scan (DAST)

It’s crucial to scan your important applications with a DAST solution to identify common vulnerabilities like XSS or SQL Injections. While enterprise DAST solutions such as Burp Suite Enterprise or Invicti can be quite costly, don’t worry if you lack the budget for them. You can still purchase a single license of Burp Suite Pro for $450 and scan applications from your laptop. If you have zero budget, you could use the open-source scanner ZAP , although I don’t recommend it. If spending $450 is not feasible, you might want to reconsider starting your bug bounty program.

Optional: Threat Intelligence

Malwares are capable of stealing your employee credentials, and a company called Intelx collects these malware logs, allowing you to search them. This means that hackers can potentially find your employees’ exposed credentials. Additionally, bug bounty hunters use this service to dig deeper into your organization. You can input “@yourcompany.com” in their search engine to check. If you find any masked credentials, you can view them for $2500 (annual license fee). While this is optional, it’s recommended. The cost is not too much and could prevent a breach or the need to pay bounties.

Note: Using exposed credentials is typically considered an out-of-scope action for most bounty programs (we’ll discuss scoping later). However, if a hacker can use an exposed credential to access your production database, they arguably deserve a bounty. It’s rude to dismiss their method as “out-of-scope”, considering the value they’re providing. Nevertheless, as the title suggests, this Intelx thing is optional.

Choosing a Bug Bounty Platform

Now that we have gained some maturity, we can move to the next step: choosing the right bug bounty platform. There are lots of different platforms available, so consider the following when making your choice:

• The profile of hackers on the platform — are they skilled?
• The competence of the triage team in handling reports and communicating with hackers
• The efficiency of their support team
• Your budget, as the cost can vary significantly between platforms

Although I am familiar with many platforms, I won’t discuss each one individually. However, as a former HackerOne employee and a program manager for my previous company, I can confidently say that HackerOne is the Apple of this field. It attracts many talented hackers who find bugs on its platform. The triage team is skilled (at least they were three years ago when I worked there), and their support team is very professional. This is not a sponsored endorsement; it’s a well-known fact in the industry.

Bug Bounty Program vs. Vulnerability Disclosure Program (VDP)

A bug bounty is a program where hackers are paid for their findings. On the other hand, a Vulnerability Disclosure Program (VDP) simply thanks them without monetary rewards. So, which program should we use? The answer is both.

A good strategy is to start your bug bounty program privately with a limited number of invited hackers, say 10. Run the program for a few weeks to see what vulnerabilities are being discovered. Identify your weak areas and strengthen them. After that, invite 10 more hackers. Assess the situation for a few more weeks and then invite additional hackers.

If you launch your bug bounty program publicly from day one, you might exhaust your budget in the first two weeks, and potentially have hundreds of pending reports. This situation would be unfavorable for everyone.

However, our VDP is public, so anyone who randomly discovers a vulnerability in your organization can report it. If you appreciate their report, you can invite them to participate in your bug bounty program.

After about a year, when you feel your program is mature enough, you might consider making your bug bounty program public.

Defining Bounty Amounts

This is totally up to your budget. But if you set the amount too low, good hackers might skip your program. I recommend starting with at least $100 for low severity issues, $300 for medium severity, $1000 for high severity, and $3000 for critical severity issues. If these amounts are too high, feel free to reduce them.

Defining Your Scope

Scope refers to the domains, subdomains, or IP addresses where we allow hackers to find vulnerabilities. Some companies only permit this on their base application. However, I wouldn’t fully recommend such an approach. A forgotten subdomain can lead to a data breach, and our objective is to prevent such breaches. Since anything could potentially cause a breach, we shouldn’t unnecessarily restrict hackers.

The key to saving money here is assigning different values to each scope asset. As a result, we will pay varying amounts of bounties for them. For example:

yourcompany.com — This is our base application and have High value (means: we will pay the full bounty amount)

store.yourcompany.com — This application doesn’t contain any PII data so it has Medium value (means: we will pay the less bounty amount)

*.yourcompany.com — Any other subdomains have Low value (means: we will pay even less bounty amount)

Including every subdomain on your scope might be scary. But we will have some extra magic to save money on the next section.

Writing Rules and Scope Exclusions

Platforms offers a generic scope exclusion list for you. You can check examples here: https://hackerone.com/directory/programs . It’s usually something like this:

• Man-in-the-middle attacks (eg. using Burp Suite to intercept and transform responses)
• Clickjacking on pages with no sensitive actions
• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
• Attacks requiring MITM or physical access to a user’s device
• Previously known vulnerable libraries without a working Proof of Concept
• Comma Separated Values (CSV) injection without demonstrating a vulnerability
• Missing best practices in SSL/TLS configuration
• Any activity that could lead to the disruption of our service (DoS), including but not limited to, inundating support services with invalid requests.
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Bruteforce oracle attacks against unauthenticated endpoints
• Missing best practices in Content Security Policy
• Missing HttpOnly or Secure flags on cookies
• Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
• Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g., stack traces, application or server errors)
• Tabnabbing
• Issues that require unlikely user interaction by the victim

This is a good baseline. Protecting us from paying bounties for unexploitable and unnecessary things. But I can suggest you to add these as well:

• Open redirection: Include it in your Vulnerability Disclosure Program (VDP) but do not pay a bounty in your bug bounty program. This typically does not pose a significant risk to your application, but it could deplete your budget.
• Broken link hijacking: Sometimes, a social media link on your website remains active even after you’ve deleted the related social media account. Hackers can exploit this vulnerability by claiming that profile. The risk is that attackers could use your website for fraudulent purposes. Reports of this vulnerability have increased after I released my socialhunter scanner to identify such issues. However, it’s not as risky as it might seem, so don’t spend your budget on this
• XSS issues discovered in non-primary applications will be classified as low severity: XSS issues are mainly dangerous if there is a user system on the application. However, hackers may still find numerous XSS issues, even on your static subdomains. Since these are not typically risky, instead of paying them a medium bounty, we will allocate a low bounty.
• Subdomain takeovers will be considered ‘Medium’ or ‘Low’ (the choice is yours), unless they are combined with other vulnerabilities: The nuclei scanner can identify potential subdomain takeovers. However, hackers often use real-time automation and may discover these vulnerabilities faster than you. Although subdomain takeovers can harm your brand reputation, I think they don’t worth high severity bounty due to their ease of detection. Therefore, it’s recommended to assign them a low or medium severity rating.

Relationship With Hackers

Some hackers may be greedy, demanding more money for a report that may not worth it. However, they are generally beneficial to us, so maintaining a good relationship is important, especially with those who are dedicated to your program. While some hackers work on many different programs, others concentrate on a select few. If a hacker is dedicated to your program, it’s crucial to keep them happy. Avoid arguing over small amounts like $100. Instead, consider it an investment. They will likely come with more valuable contributions.

Sometimes hackers can be really rude and annoying. In this case, avoid arguing with them and leave the communication to the triager. You can write an internal message to the triager outlining your desired outcome. For example, you may express that you don’t want to accept this report. The triager will then communicate this, taking on the role of the ‘bad guy’. While this might sound unfavorable, remember that triagers are professionals who understand how to not take things personally. This approach helps to protect your brand value as hackers often engage in public disputes on platforms such as Twitter.

If hackers is really annoying, you can remove them from your program. It’s your right after all.

Some Random Tips

• You may use the same code base across different regions or subdomains. Hackers might submit unique reports for each of these. However, if the vulnerability originates from the same code, you don’t need to pay for each report. You can simply pay once.
• If a subdomain points to a CNAME that you don’t control, you’re not required to pay bounties for it. It’s not considered your asset.
• If you already know about a vulnerability, you usually don’t need to pay for it. However, it’s important to be honest and not to abuse this. Provide proof, such as a screenshot of your Jira ticket, to the hacker.

Conclusion

We’ve discussed nearly all aspects of a bug bounty program. I hope this information is helpful. Feel free to leave comments if you have additional suggestions or questions.