Cyber Teams
How to launch a bug bounty program (a security leader’s guide)
The A-Z of creating a bug bounty program from scratch. Learn how to get started, structure your program, and judge whether or not you need to implement one.
CyberMnemosyne,
Jun 04
2024
Table of Contents
The more lines of code your application has, the more space for bugs to hide in.
Bug bounty programs enlist the help of a large number of skilled cybersecurity researchers to find “hidden” bugs lurking in your app. These programs can be an effective way to supplement more targeted security testing, like penetration testing.
In this post, we’ll cover how you can set up, run, and evaluate a bug bounty program to improve your app’s security posture.
How bug bounties support application security
A bug bounty provides an optimized way to crowd-source an application’s security review.
In a bug bounty program, your company announces that it is soliciting reports of security vulnerabilities related to a specific application. In return for accepted bugs, the company may pay a reward, or “bounty” to the person who found it.
The goal is to enlist the experience and skills of a worldwide group of security researchers, without having to pay for their time if they do not find anything of value.
Some third-party companies, such as Synack, HackerOne, or Bugcrowd, can manage the bug bounty program on a company’s behalf. While this does decrease the overheads required to run the bounty, it also includes an increased up-front cost to pay them.
If the vulnerability is accepted, the bug hunter may be rewarded financially, and in some cases will be updated once the vulnerability has been remediated.
Overall, a bug bounty program is one control in your organization’s overall risk management strategy. It does not replace other controls that are in place to mitigate the security risk of an application or asset.
Build your team’s web app security skills
The Bug Bounty Hunter Job Role Path on HTB Academy is ideal for training your IT or security team to conduct internal web app security assessments.
Your team will learn best practices for securing web apps, common web service & API attacks, and how to identify and submit vulnerability reports.
Should you run a bug bounty program?
Whether your organization should run a bug bounty depends on the organization’s overall level of security maturity. To judge this, the cybersecurity-focused teams should ask themselves a few key questions:
-
Does your organization operate a risk management strategy and use this as the basis for all decisions on security measures?
-
Does your organization operate a secure development process?
-
Are your developers and security engineers sufficiently skilled, and maintaining their skills?
-
Are you recording, reporting, and analyzing security performance metrics to drive process and security improvement?
If the answer to all these questions is “yes”, then you could consider a bug bounty as an additional measure to find and fix security flaws.
If the answer is no, then your organization is better off investing resources into establishing secure coding practices, training developers, and optimizing risk management strategies instead.
Setting up a bug bounty program
Bug bounties start with the company announcing the target and scope of the exercise:
-
Clearly identify the target(s) by using specific URLs/locations.
-
Specify the category or target e.g. Website, API, mobile application, IoT, etc.
-
List all assets that are out of scope.
-
List all functionality in the target that may be out of scope.
Ideally, the testing is done on a sandbox version of the application. If you invite testing of a live system, share strict conditions that testers do not interfere with legitimate users.
Bug hunters will be told what types of vulnerabilities will—and will not—be accepted, how to submit bugs, and how the company will respond.
Planning for a bug bounty
Even though a bug bounty uses a worldwide talent pool, it requires internal staff to set up and manage it.
So the program will require a budget that includes staff time and operation costs, as well as the funding for any bounties paid for accepted bugs.
The amount you set for a bounty should be in line with other comparable bounties. If the amount is too low, bounty hunters may pass the opportunity up for more lucrative targets.
The CISO will be responsible for their team creating a project proposal that:
-
States how the bug bounty fits into the overall risk management of the application.
-
Outlines a budget for establishing, running, monitoring, and reviewing the costs of the bug bounty program.
-
Includes input from legal counsel, communications, public relations, IT (for operational issues), and development team (for dealing with unplanned fixes), and a project team (for running the bug bounty program itself).
-
Plans the design, development, and monitoring of the bounty program.
As a bug bounty can involve many different departments, the CEO may also need to sign off on the overall strategy.
Establishing the program structure
With approvals and buy-in from the necessary stakeholders, it’s time to appoint the bug bounty team and get to work. The next steps are to:
Appoint a bug bounty team
Define and assign the roles of the bug bounty team and how much time they will need for these roles. The bug bounty team needs someone assigned to each of the following tasks:
-
Planning and producing project plan for bug bounty.
-
Deciding on the level of payment for accepted bugs.
-
Producing and disseminating communications about the bug bounty to the security community.
-
Review of submitted bugs, communication with the submitter, liaison with the development team, and communication with other teams as required (legal, communications, security, development, IT).
-
Reviewing and paying for completed bug bounties.
Define the scope
Define the exact scope of functionality that needs to be tested. More importantly, describe what is out-of-scope. This will help cut down on bug bounty claims for low-risk issues. For example, Sophos has a list of examples of what they call “Beg Bounty” claims.
Create a test instance or prepare the live app
Decide whether a test instance of the application will be used for the bounty project or whether to use the live system. The pros and cons between the two are:
|
Live system |
Test system |
|
Less costly. |
More costly to set up. |
|
Does not require time or effort from dev ops to set up. |
Requires effort to duplicate live especially if dummy data replaces production data. |
|
Will be kept up-to-date with the latest version and patches as part of the normal production process. |
Requires ongoing patching and updates to mirror the live environment. |
|
Risks live data and users being affected by the testing process. |
Still may not protect the live environment as bug bounty hunters may still target that system. |
Track and manage bugs
The bug bounty process for handling bug submissions is typically different from a normal internal bug-tracking process. So you’ll need to integrate bug bounty submissions with an existing reporting system or create a separate process unique to bug bounties.
Once a bug submission is received, it will be triaged to assess its validity, relevance, and criticality. If a submission is accepted, it can follow your team’s normal bug resolution process.
For each accepted bug, the team needs to track and manage the resolution and update of production code. Once done, the security team and developers should conduct a post-mortem for lessons learned and identify similar issues in the code that need resolving.
Reporting on the success of a bug bounty program
Metrics to assess the overall performance of the bug bounty can be obtained from the bug bounty tracking process. These metrics include:
-
Number of bugs submitted and accepted.
-
The severity of vulnerabilities found.
-
Vulnerabilities resolved.
To evaluate the value of the bug bounty program, you should examine the details of the vulnerabilities found and fixed.
Although qualitative risk analysis is common in most companies because of its relative simplicity, a better approach that allows more quantitative analysis of the benefits of a bug bounty program is quantitative risk analysis.
Quantitative risk analysis helps you calculate a value for each vulnerability to work out what it may have cost the organization if an attacker had exploited the vulnerability.
Quantitative models, such as the one used by the FAIR Institute, use a loss event frequency and loss event magnitude to determine the percentage likelihood of the loss as a result of the vulnerability being exploited.
This way, you can communicate potential savings to the organization from discovering and fixing vulnerabilities.
Build your team’s testing abilities with the CTF marketplace
From guided courses on secure coding to hands-on lab environments and CTF challenges, Hack The Box (HTB) is a perfect match for teams wanting to learn, improve, or certify their skills in bug bounty hunting or web app testing.
HTB team CTF packages for web app security
Web Application Security Level 0:
Explore fundamental concepts in web application security, including credential exposure, SQL injection, command injection and cross-site scripting (XSS).
Web Application Security Level 1:
Dive into advanced web application security topics, including insecure direct object references (IDOR), token forgery, Server-Side Request Forgery (SSRF), and more.
Web Application Security Level 2:
Challenge your expertise in web application security with complex topics like template injection, sophisticated session tampering techniques, deserialization vulnerabilities and more.
