Bug bounty programs have emerged over the last 5 years as a vital tool for identifying and mitigating vulnerabilities.
Many enterprises have accepted the value of having bug bounty programs in their quiver of offensive security practices, and lately, startups and scaleups are joining in as well.
This is great as I genuinely believe that bug bounty is one of the most important things an organization can do to uplift its cybersecurity maturity. However, the effectiveness of these programs can be significantly hindered if they are kept private and secretive.
Here’s why.
Vulnerabilities Are Everywhere, You Just Have to Look
As a security researcher who frequently encounters bugs in the wild, I know experientially that these vulnerabilities are everywhere. Whether discovered during a pentest, a vulnerability assessment, or even via casual use of an application, bugs are a constant presence. A few months ago, my wife pointed out a bug she had run across in an eCommerce platform she was using and I verified it was indeed a security vulnerability and alerted their team to the issue.
The reality is, bugs are omnipresent, and identifying them is just a matter of looking in the right places.
The Researcher’s Dilemma
Once I verify that something is really a bug, and not just my own faulty testing, I want to let the company know ASAP. I have always been like this: When I find a problem I want to let the affected company know. Why? Because if the roles were reversed I would want to know. We owe it to our paying customers to take this stuff seriously, so I go out of my way to follow up.
The first step I take is to check if the company has a bug bounty program. I do thorough research, looking for programs on platforms like Bugcrowd, HackerOne, Intigriti or YesWeHack. If I find no reference to a bug bounty program, I then scour the company’s main domain for a security page or a security.txt file. I even reach out to security employees via LinkedIn or email, asking, “Heya, do you have a bug bounty program?”
Public vs Private Programs
Now here’s the thing, there are two types of bug bounty programs. Companies can have public programs which anyone can hack on, and most importantly for this blog post, you can typically find public programs simply by googling the name of the company and adding “bug bounty”
However, if your bug bounty program is private and secretive, security researchers like me won’t find it. This means I won’t be able to report the vulnerability, leaving it unaddressed. If your employees don’t respond to my inquiries, the bug remains in the wild, posing a risk to your organization and, more importantly, to your customers.
Luckily, according to HackerOne data, while private programs are still the majority of programs overall, their percentage has been going down over time. In 2019 private bug bounty programs made up 79% of all bug bounty programs on HackerOne, down from 88% in 2017 and 92% in 2016 calendar years, meaning more programs are going public on HackerOne.
Why Do Some Companies Choose Private Programs?
I reached out to people I know who manage private bug bounty programs and asked them why their organization chose that model. Here are some of the things I heard:
- “We don’t know what’s going to happen” Some orgs want to limit the number of findings while they “tune” the program. This is pretty common and I’ve heard this before. If the org is new to bug bounty, they don’t know what’s going to happen so want to control things by starting with a smaller, private, pool of researchers.
- “We want to limit cost” The company is focused on controlling costs and wants to cap its spend on the program. They do that by limiting the number of people hacking on the program.
- “We don’t have the risk appetite” ie., management is less likely to fund something when there is a risk of anyone jumping in and breaking things. An invited group or vetted testers are less risky.
- “We aren’t staffed correctly/Too much noise” Some orgs don’t feel like they have the staff available to triage a large number of findings, so its better to have a smaller number of hackers working on it so that the number of findings is smaller.
- “We don’t want to encourage hackers”. The organization thinks that a public bug bounty program will steer malicious hackers towards them, so they keep their program private so no one knows about their assets.
I think some of those concerns are legitimate, especially when a company is getting started with their first bug bounty program. In particular, the need to control costs and employee resources spent on the program are important parameters to control. However, once your program has been running for 3 to 6 months, you should better understand how your program is functioning and you can tweak the knobs that you have: How big is your scope? What are you paying? And whos going to manage triage?
Lack of Maturity Is Obvious
One huge red flag for me is if an org says “We don’t want to encourage malicious hackers” when they are talking about a bug bounty program. If I hear someone say this, i know that the organization’s cybersecurity maturity is really low. Malicious actors aren’t waiting to find assets in public bug bounty programs to go and hack, so anyone who says that clearly doesn’t know what they are talking about.
Unfortunately, I have heard this sentiment a LOT in Australia.
The Importance of Transparency
The lack of transparency in a private bug bounty program creates a significant barrier for researchers who are trying to do the right thing. If your employees are not allowed to disclose the existence of a bug bounty program, the chances of it being discovered by an external researcher are slim. This is a common frustration among researchers who are genuinely interested in helping organizations improve their security posture.
Why Keep It Private?
The critical question to ask is: Why is your bug bounty program private? If there’s a legitimate reason, it’s worth discussing with your team to ensure that it doesn’t hinder the reporting of vulnerabilities. A possible solution could be to allow employees to introduce researchers to the program manager, who can then decide whether to provide an invite to the private program.
Best Way to Run a Private Program
If you have valid reasons to run a private bug bounty program, then there are several things you can do to let security researchers know about your program:
- Invite-only doesn’t mean secret: If your org insists on having a private program to control costs, or employee resources, remove the secrecy component. In other words, you can have a private, invite-only program without it being a complete secret to the world. Your org continues to gatekeep who is allowed to hack on your program and to see your scope, but meanwhile people that are trying to disclose bugs know where to go.
- Publish your disclosure policy: Make sure your website has a specific page that says something along the lines of “If you find a vulnerability that you believe would qualify for a bounty, please reach out to us at disclosure@company.com with your Bugcrowd/HackerOne/Intigriti/YesWeHack account username”. Your team can then vet the emails sent to that address and if the vulnerability found looks legit you can then vet the researcher on whatever platform they are on and see if they should be added to your private program.
- Add security.txt: Create a security.txt and host it on the root domain of your main website and include the same description listed above: “If you find a vulnerability that you believe…”
- Private programs are temporary: It makes some sense to start a brand new program invite-only, but then after 3 to 6 months all programs should move to be public programs. If your program stays private for longer than 6 months, it’s a signal to the world that your program lacks maturity (and commitment).
- Empower your team: Talk to your security team and let them know if someone approaches them with what looks like a legit issue, that they can point them to the security webpage or even better, give your team the ability to add researchers to your private program.
Let’s bring this home…
In the ever-evolving landscape of cybersecurity, openness and collaboration are key. Private bug bounty programs, while well-intentioned, can inadvertently make organizations less secure by creating barriers to vulnerability reporting. By fostering a culture of transparency and responsiveness, organizations can leverage the collective expertise of the security community to enhance their security measures, ultimately safeguarding their assets and their customers.
