Bug Bounty Program (BBP)

A bug bounty program (BBP) is a sponsored, organized effort that compensates security researchers for surfacing and reporting otherwise unknown network and software security vulnerabilities, thereby enabling the digitally connected business to manage and reduce their cybersecurity risks. The phrase “Bug Bounty” was initially coined in early 1995 by a Netscape technical support engineer.” Several months later, on October 10, 1995, Netscape launched the first technology bug bounty program for the Netscape Navigator 2.0 Beta browser.

Bug bounty programs have continued to grow in scope and popularity. In addition, the use of Crowd security at large has gained popularity, in part, due to current security resource models and cost. Modern crowdsourced security platforms close the gap between security and development.

Crowdsourced security organizes otherwise unconnected individuals to work towards a common goal of surfacing otherwise unknown vulnerabilities. BBP requires a platform that connects these resources and then manages them effectively. Vulnerabilities must be submitted and tracked, errors and noise in the process must be filtered out and reduced, and the process must integrate with the software development lifecycle for effective and rapid remediation.

Bug bounty has often been used synonymously with the term “crowdsourced
security.” These terms now represent more distinct and different capabilities. For example, crowd resources are now leveraged by other security initiatives such as pen testing and attack surface management. Crowdsourced security is a resourcing model, while BBP represents engaging and incentivizing those resources to encourage testing for a potential reward.

BBPs use a competitive model that encourages testing by offering a reward. If security researchers are the first to find a vulnerability within the scope of the BBP, they are rewarded with payments tied to validation and impact.

In context, two researchers may uncover different types of vulnerabilities. The one involving higher potential impact would command a higher bounty. This model reduces the average cost per vulnerability and helps ensure that customers are truly only paying for value received. BBPs roughly the same process:

Scope definition:

• What assets should be tested?
• How many web applications are involved?
• Are there both desktop and mobile versions?
• Are there any application program interfaces (APIs)?
• Should we test in the development environment, the production environment, or possibly both?
• What sort of credentials and authentication are required?

All of these questions should be answered before you can start the BBP.

Researcher engagement:
The best platforms match resources based on skill sets, performance, certifications, and many other factors that can potentially influence program success. Some organizations maintain full time employees. In this case the availability of any specific individual depends on scheduling factors and ongoing work assignments. Matching methodology, especially as implemented in software, can make an important difference in identifying and engaging the right researchers.

Vulnerability submission:
Incoming submissions may be validated and prioritized according to severity if a BBP program offers triage services. Triage services cut down on the clutter and help prioritize submissions and direct remediation.

SDLC Integration:
Integrations into important developer workflow tools like JIRA, GitHub, ServiceNow, and IBM Resilient are critical to rapid vulnerability resolution. Integrations into Slack and Trello can also improve communications. Integrations with vulnerability management tools like Qualys can help add context to further prioritize vulnerabilities.

Payment:
Discovered and approved vulnerabilities are rewarded from a set-aside sum of money known as the “bounty pool.” By allowing an intermediary to manage BBP payments, organizations avoid the pitfalls and problems associated with tax procedures that differ by local government and state.