Charter: A bug bounty program free open source software.

Internet Bug Bounty Charter

Internet Bug Bounty Charter

Our collective safety is only possible when public security research is allowed to flourish. Some of the most critical vulnerabilities in the internet's history have been resolved thanks to efforts of hackers fueled entirely by curiosity and altruism. We owe these individuals an enormous debt and believe it is our duty to do everything in our power to cultivate a safe, rewarding environment for past, present, and future hackers.

The Internet Bug Bounty (IBB) program was established to recognize and reward security research that improves critical Internet infrastructure.

The program is made possible through generous sponsorships by several organizations who understand the importance of a safe and secure Internet. The program itself is administered by an independent panel of security experts from the community.

Panel Structure

The Panel is responsible for defining the rules of the program, allocating bounties to where additional security research is needed most, and mediating any disagreements that might arise.

Any Panelist may propose a change to the structure of the program or the Panel through a submitted proposal. Unless otherwise specified, all proposals are decided through a majority vote. Votes must be registered within three (3) business days of the submission of a proposal. In the event of a tie, the proposal does not pass.

Additions to the Panel require a nomination from an existing Panelist. Each Panelist is granted full veto rights over any Panel nomination. Removals from the Panel are by majority vote.

Panel members agree to disclose in a timely manner, e.g. after determining the issue's severity, any vulnerabilities that they uncover in a personal capacity to the organization responsible for fixing the issue, or resign their position. Panelists do not undertake employment for organizations that engage in selling vulnerability technical details that have not also been shared with the organization responsible for fixing the issue.

The Panel will organize a monthly meeting via conference call. Panelists will register new agenda topics ahead of time in the IBB Panel Meeting Minutes document.

To ensure sustainable and successful operation of the Internet Bug Bounty, all Panel members agree to adhere to a set of minimum expectations. The set of minimum expectations for each Panel member is as follows:

  1. Each Panel member must participate in the scoping and bounty pricing processes defined below.
  2. Each Panel member must agree to vote on reward amounts (or no reward as applicable) on at least 80% of the reports sent to the IBB.
  3. Each Panel member agrees to participate in a monthly meeting. Panel members must attend at least ten out of twelve meetings per calendar year.
If a member of the Panel does not meet these expectations and does not self-nominate to leave the Panel, they become subject to removal from the Panel by majority vote. The Panel will provide warning to the inactive member that they will be removed from the Panel unless they resume expected activity within two weeks.

Finances

The Internet Bug Bounty program is sponsored by individuals and organizations who genuinely care about our collective security. Their contributions directly fund the bounties paid to finders with no portion going to the Panel or administration: 100% goes to finders. Sponsors do not have any special access or rights to vulnerability data.

The Internet Bug Bounty is incorporated as a not-for-profit organization, but is still in the process of applying for federal tax-exempt status under IRS 501(c)(3). As such, donations to the IBB are not tax deductible at this time.

The Panel has authority over the acceptance of all funding sources.

Scoping Process

The Internet Bug Bounty is comprised of individual scopes representing specific classes of security vulnerabilities. In most cases, this is either a specific software project (e.g., OpenSSL vulnerabilities) or a specific class of vulnerabilities (e.g., sandbox escapes). The Panel has final authority over which individual scopes are included in the program.

For the scopes within the Internet Bug Bounty, the Panel will:

  1. Define the qualifying criteria for security vulnerabilities.
  2. Define the bounty payment structure.
  3. Determine the bounty eligibility of each vulnerability.
  4. Defer these responsibilities whenever a capable Security Team is identified as being capable and willing to take over.
The following sections outline in detail the process the Panel uses to determine what is eligible to be in scope for the Internet Bounty.

Periodic review

The Panel will review this process, at a minimum, on an annual basis to determine if any adjustments need to be made. Adjustments to this process will require a majority panel vote. In addition to review of the process itself, the Panel will also, at least annually, review the criteria used to determine what software should be in scope (see “Scoping Criteria,” below).

Scoping criteria

The following criteria and processes will be used to help identify which software will be considered in scope for the Internet Bug Bounty.

Introducing New Software Into Scope

Any new software to be introduced into the IBB’s scope must be nominated by a member of the Panel, and the Panel must agree by majority vote to put the software into the IBB’s scope. If a vote to introduce new software into scope fails, the software cannot be nominated again for a 30 day “cooling period” from the date it was nominated.

Panelists must consider the following guidelines when considering if a software should be in the IBB’s scope.

Widespread Use

To be in scope for the IBB, the software must be widely used. This is in order to best focus the IBB’s resources on software that may have the most widespread impact. “Widely used” is defined as software that, if affected by a vulnerability, would impact a significant number of users. For example, widely used software that supports commonly used technology like encryption, mobile devices, browsers, web applications, and email could be good candidates.

Mind the Gap

In order to most efficiently allocate funds, the Panel should be cognizant of what software is already covered by other efforts, and how. For example, if another organization rewards for providing patches to open source projects or funds secure development, the IBB should not duplicate this effort, but instead serve in a complementary fashion by rewarding researchers that identify and disclose vulnerabilities to the maintainers. The IBB should proactively identify software that has a gap in rewards for vulnerability research; in conjunction with other criteria, this is a good indicator that the software should be moved into scope.

Active Security Team

Software must be maintained by an active development or security team capable of adhering to a documented vulnerability handling and disclosure process. The software maintainer should also be on board with their software being introduced into the scope of the IBB; it is the IBB’s responsibility to reach out to and coordinate with software maintainers to ensure they adhere to proper vulnerability handling and disclosure processes.

Moving Software out of Scope

For any software to be moved out of the IBB’s scope, the software already in scope must be nominated by a member of the Panel for removal, and the panel must agree by majority vote to remove the software from the IBB’s scope. If a vote to introduce new software into scope fails, the software cannot be nominated again for a 30 day “cooling period” from the date it was nominated.

Panelists must consider the following guidelines when considering if a software should be in the IBB’s scope.

Dwindling Use

If a software that was in scope is no longer widely used, leaving it in scope for the IBB may not provide much value. Given that the IBB is a volunteer-driven effort with limited resources, removing software that is no longer widely used from scope frees up resources to focus on strategic efforts to improve how the IBB is structured and run, as well as to spend time on any new software which is brought into scope.

Dual Coverage

If paying bounties for vulnerabilities identified in a software in scope for the IBB begins to be covered by another organization that does so in a fashion similar to how the IBB would handle it, this may be a good indication that the software should be removed from scope. To most efficiently allocate the IBB’s resources and not duplicate work, the IBB should avoid “dual coverage” of software provided by another organization. In these situations, the IBB should collaborate with the organization providing dual coverage to determine what makes the most sense (e.g. should the other organization move the software out of scope; does the other organization want to work together with the IBB; should the IBB move the software out of scope; etc.).

Bounty Pricing Process

The following sections outline in detail the process the IBB uses to determine bounty pricing for all programs within the IBB.

Periodic review

The Panel will review this process, at a minimum, on an annual basis to determine if any adjustments need to be made. Adjustments to the IBB bounty pricing process will require a majority panel vote. In addition to review of the process itself, the IBB will also, at least quarterly, review the bounty pricing criteria guidelines to determine if any changes need to be made in current bounty pricing.

Bounty pricing criteria

The following criteria and processes will be used to help identify if and how bounty pricing should be adjusted for software currently in scope of the IBB. This criteria will also be used to determine bounty pricing for new software as it is introduced into the scope of the IBB.

Infrequent reports

If a particular software within the scope of the IBB is not getting much traction in terms of little to no reports being submitted, this may warrant increasing the bounty amounts for that software to encourage hackers to focus efforts on it.

Lack of high impact reports

If there have not been reports of high quality or impact to a particular software, assuming the program for said software has a tiered reward system, it may make sense to increase the reward amounts for the higher tiers. For example, the OpenSSL program has a well-defined, tiered system of rewards based on severity levels issued by the maintainers. If the OpenSSL program had a noticeable drop in the frequency of Critical reports, that may warrant increasing the bounty amount for Critical reports.

Frequent low impact reports

If a program has a tiered reward system and is receiving frequent low impact reports that are on the border of the lowest tier / being ineligible, it may be worth reducing the bounty pricing of the lowest tier to help incentivize hackers to refocus efforts on higher impact issues.

Total available budget

The IBB is working within the constraints of the IBB’s total available budget, and need to balance a fair distribution of funds across all in scope projects. When defining bounty pricing, particularly for new programs introduced into the scope of the IBB, total available budget must be considered. Inversely, data analysis around bounty payout trends will help inform the IBB on estimated required budget for fundraising purposes.

If you have any questions or feedback on the IBB's charter,
please let us know.