Bug Bounty Program

Terminology:

BB – Bug Bounty

WH – White Hat

DS – Discord

Flow:

1. Bug bounty announcement & terms ⇒ Apply to participate (make sure you join DS + share your DS + share your GitHub account details)
2. Bug Bounty channel on DS (secret channel for selected devs)
3. Access details & bug submission form published to the secret chat
4. Winners announced

Help Needed for Bug Classification and Reward Types, Organized in a Hackathon Format (3 Winners in Different Categories)

For bug classification, we’ll need assistance with the types of vulnerabilities and rewards. I suggest using the Common Vulnerability Scoring System (CVSS), which is used to capture the key characteristics of vulnerabilities and provide a quantitative score reflecting their severity. The quantitative score can then be translated into a qualitative representation (e.g., low, medium, high, and critical) to help assess and prioritize vulnerability management and remediation processes. While it might be comprehensive, it will cover the necessary description of vulnerability characteristics and assessment for bug bounties, which will alleviate many of the questions that WH (White Hat) individuals may have when searching for these vulnerabilities.

However, the framework and classification options will depend on the chosen platform for conducting the BB (Bug Bounty). For instance, BugCrowd mandates using their vulnerability rating system – Bugcrowd’s Vulnerability Rating Taxonomy – for conducting BB on their platform, while Immunefi optionally offers their own system – Immunefi Vulnerability Severity Classification System.

Implementation Options

1. Custom Bug Bounty Page

This option is mainly used by large companies or companies with specific testing conditions and atypical vulnerability classification. Therefore, other than having their own Bug Bounty page on their website, there are no other alternatives.

Security Center

Security Vulnerability Policy

Meta Bug Bounty Program Info

Pros include having a unique design, and the Bug Bounty page can have any appearance without being tied to the standards inherent in aggregators or template solutions.

📢 Conclusion: In our case, this method can be used as an additional option to No. 2. Designing a Bug Bounty page for the audience coming to the site, while collecting and analyzing applications on more specialized platforms, will be more relevant in terms of time and resource efficiency for processing applications.

2. Aggregators of Various Bug Bounties

Projects create standard pages with information about Bug Bounty procedures, internal and external conditions, and participants submit their vulnerability reports directly on the same platform.

Two types of aggregators are identified:

• General-purpose aggregators

These aggregators are used by projects from any field. They are quite robust in terms of execution, and some even have their own vulnerability rating and classification systems. They are also used by large holdings like Atlassian.

• Examples of such aggregators:

#1 Crowdsourced Cybersecurity Platform | Bugcrowd

HackerOne

• Examples of the projects’ BB.

Atlassian’s bug bounty program | Bugcrowd

Acronis – Bug Bounty Program | HackerOne

HackerOne

HackerOne

Conclusion: A good option for quickly deploying Bug Bounty programs, a convenient solution suitable for most projects. Usually, such aggregators have a well-established community, which means that projects from any field will find an audience relevant to their specific Bug Bounty program. However, the next option is more suitable.

• Aggregators specializing in specific fields, in our case – Web3, blockchain, and crypto.
  • Examples of such aggregators:
    • Immunefi – the leading platform for blockchain project Bug Bounties, with rewards reaching up to $10 million.
    • HackenProof – another platform for conducting Bug Bounties for crypto projects, but with more standard rewards of up to ~$50k and fewer projects compared to the previous option.
  • Examples of projects on these platforms:
    • Wormhole Bug Bounties | Immunefi
    • MakerDAO Bug Bounties | Immunefi
    • Avalanche HackenProof

Pricing:

• Immunefi
  • $0 onboarding and launch fee
  • $0 maintenance fee
  • $0 advisory fee for drafting the program
  • 10% Immunefi performance fee (charged on top of the payout) for vulnerabilities found
  • No deposits
  • You can KYC if needed, but let us know in advance
  • Projects set their own payout amounts
  • Pay rewards in your own token/coin
• HackenProof There are 3 available tariffs:
  • $0/monthwithout Triage team+10% bug feeCustomer supportHackenProof handles all policy and payment transactionsLaunch up to 2 public Bug Bounty Programs
  • $1600/month+10% bug feeDedicated program managerHackenProof handles all policy and payment transactionsLaunch up to 2 Bug Bounty Programs, private or public
  • $2000/month+10% bug feeDedicated program managerHackenProof handles all policy and payment transactionsLaunch up to 5 Bug Bounty Programs, private or publicPre-Vulnerability Assessment10% off on pentest from Hacken

Conclusion: This is the best option among those presented in the document, as it offers a quick implementation process. These platforms have communities that are highly relevant to the field, and if desired, we can outsource the vulnerability verification. It also provides a ready-made solution for handling all reports from White Hat individuals, so we don’t have to prepare a separate flow for collecting reports.

3. Bughunt Community

This option involves creating not just a simple page describing the capabilities but an entire portal for the bug hunting community. It works well for ecosystem products as it allows for highly flexible customization of the working format. Additionally, it can incentivize White Hat individuals (WH) with additional features that cannot be embedded and implemented within the scope of the previous options.

Let’s take Google as an example:

Google Bug Hunters

This portal is used not only for collecting vulnerability information but also for various bug hunting-related training, such as Bug Hunter University.

To further stimulate the community and create a competitive environment, a leaderboard is also created, showing each user’s personal statistics on vulnerability reports and rewards.

💡 Conclusion: This is the best among the possible solutions for Bug Bounty programs in terms of incentivizing the community and drawing attention to rewards. It also serves as an educational portal to increase interest in Bug Bounties, White Hat activities, and cybersecurity among the current audience while attracting new participants. Through informative articles and well-presented educational materials, the platform can become a specialized project on its own. However, it may not be suitable for us at the moment due to resource constraints.

Required Information for Bug Bounty

1. General information about the project.
2. General information about the Bug Bounty program (focus of the bounty, its purpose, etc.).
3. Start and end dates of the Bug Bounty.
4. KYC – yes / no.
5. Comprehensive vulnerability classification.
6. Detailed description of rewards for finding vulnerabilities. If there are additional reward conditions not covered by the classic classification, describe them as well.
7. Assets in Scope – a description of the software, websites, and smart contracts included in the Bug Bounty program.
8. Out of Scope – a description of the software, websites, and smart contracts not included in the Bug Bounty program.
9. Description of priorities for vulnerability analysis (if applicable).
10. General rules for participating in the Bug Bounty.

Discord

The concept mentioned in the Flow is not entirely clear, as it requires a considerable amount of manual work:

1. Sorting potential participants.
2. Adding them to a separate channel (it cannot be automated because selection will always be manual).
3. Creating all forms and announcements, outlining the classification within Discord.

Based on this, it seems that this format is unnecessary due to the availability of ready-made solutions such as aggregators or standard Bug Bounty pages.

If the plan is to provide access to the code via Discord, this requirement can be included as one of the conditions and rules of the Bug Bounty on aggregators.

Overall Conclusion

Based on the above points, the following option appears to be the most relevant:

Create a Bug Bounty on an aggregator specialized in crypto projects and share it widely. Optionally, consider the following:

• Use Triage from the aggregator to avoid using internal development resources for handling vulnerability reports.
• Add a requirement to join Discord to gain access to the code, but do not completely transfer the entire flow there.
• Design a separate page that contains all information about the Bug Bounty, but restrict vulnerability report submissions only to the aggregator’s platform.
• Establish an official partnership with the aggregator/auditor to increase visibility through their platform’s social media presence.

P.S.

In many specialized resources and articles about Bug Bounties, emphasis is placed on conducting Bug Bounty programs only after a thorough internal audit, with Bug Bounty being the final and additional form of vulnerability auditing.