Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a Grin Bug Bounty Program #149

Open
chisa0a opened this issue Jun 13, 2019 · 2 comments
Open

Create a Grin Bug Bounty Program #149

chisa0a opened this issue Jun 13, 2019 · 2 comments
Labels
governance Anything related to governance task An action that needs to be taken

Comments

@chisa0a
Copy link

chisa0a commented Jun 13, 2019

After discussion on gitter, I would like to continue building out a bug bounty program for Grin.

Others have also discussed interest in such a program, and believe it would benefit project security in the long-term.

With Grin's first hardfork soon approaching, this issue can serve to collect ideas and discussion about a bug bounty program.

Some initial thoughts (continuing from the security doc):

  • recognition rewards (leader/trophy board)
  • tiered financial rewards
  • budget planning based on tiered rewards + calculated bug likelihoods
  • forming vulnerability response team to assist @lehnberg & @ignopeverell
  • clear response plan for fixes, disclosures, rewards, and recognition
  • consider platform provider options like BugCrowd, HackerOne, etc.
@lehnberg lehnberg added governance Anything related to governance task An action that needs to be taken labels Jun 13, 2019
@lehnberg
Copy link
Collaborator

@chisa0a thanks for raising this issue.

Ahead of the governance meeting, it would be helpful if these thoughts could be fleshed out into something more concrete that can then be discussed in the meeting. For example, rather "tiered financial rewards", what would be a proposal for the actual tiers?

There's also a relevant forum thread here: https://www.grin-forum.org/t/please-help-evaluate-grins-security-process/4537

@chisa0a
Copy link
Author

chisa0a commented Jun 18, 2019

Questions about a bug bounty program from @yeastplume:

Why would a program benefit grin?

Engaging the independent security researcher community increases the number of domain experts reviewing Grin code.

Encouraging positive security research, and responsible bug disclosure, helps ensure critical bugs are found & remediated before bad actors have a chance to exploit them.

What are the downsides?

Time expenditure reviewing and triaging bug reports. Some noise (sometimes a non-trivial amount) is to be expected.

Research should be conducted into how other successful programs mitigate this problem, and boost noise-signal ratio.

Bug bounties by their nature cost money. The goal is for the expenditure to be outweighed by preventing more expensive exploits or PR/ecosystem/user damage from irresponsible bug disclosure.

What are some projects similar to grin that have shown a success using a bug bounty problem?

Are there better things we could be spending money on?

Possibly, and it should be researched if there are more proven ways to engage independent security researchers.

It could be argued that continued professional audits are more productive. Bounties and audits are not mutually exclusive, and bug bounties offer a larger number of minds reviewing + testing Grin code. Bug bounties are also considerably cheaper, as the most expensive bugs are also the least likely to occur.

What are the risks?

The bug bounty program could be an abject failure, resulting in nothing but useless noise. Constructed properly, this is unlikely to happen.

No one takes interest in the bug program, and there is no increase in Grin security research. This is low-risk, since no funds would be expended, and could be reallocated after a consensus vote.

Grin depletes reserves paying out bounty rewards. Obviously very bad, but can be mitigated by properly budgeting and structuring reward tiers. Further mitigation could include temporarily suspending the program to replenish funds (done by a number of other projects).

What's the cost-benefit analysis.

Costs:

  • Reward funds (replenished as needed)
  • Vulnerability response team member time expenditure (reviewing reports, triaging, coordinating fixes / rewards, etc.)

Benefits:

  • Low-to-Critical bugs found, responsibly disclosed, and remediated before being exploited/sold in the wild
  • Long-term project health
  • Increased involvement of the security research community

Questions about a bug bounty program from @jaspervdm:

Who decides which bugs are worth it?

The Vulnerability Response Team would be the first-line here. Once a bug has been validated as real (possibly discussing/deferring to core devs), discussion continues with other core/council members to coordinate fix(es) and reward(s).

Where do we get the money from?

Money could be allocated from the Grin general fund, and/or donated by community members interested in supporting the bug bounty program.

How much do we pay?

Samples of reward tiers:

Ethereum:

Severity (OWASP) - Reward (1 point = $1 USD)

  • Critical - <= 25,000 points
  • High - <= 15,000 points
  • Medium - <= 10,000 points
  • Low - <= 2,000 points
  • Note - <= 500 points

Pivx:

Severity (CVSSv3) - Reward

  • Critical - $5,000 USD
  • High - $2,500 USD
  • Medium - $1,000 USD
  • Low - $200 USD

VeChain:

Severity (CVSSv3) - Reward

  • Critical - $10,000 USD
  • High - $5,000 USD
  • Medium - $2,500 USD
  • Low - $500 USD

Zilliqa:

Rating (based on BugCrowd taxonomy) : Binary/Code review Reward : VRT Submission Reward

  • P1 (Critical) : $3k - $5k : $2.1 - $2.5k
  • P2 (Severe) : $1.5k - $3k : $1.2 - $1.5k
  • P3 (Medium-High) : $500 - $1k : $500 - $1.2k
  • P4 (Low-Medium) : $200 - $800 : $150 - $500

Kraken:

  • Min reward: $100 USD in BTC
  • Higher rewards at their discretion

Possible bug bounty platform providers:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
governance Anything related to governance task An action that needs to be taken
Projects
None yet
Development

No branches or pull requests

2 participants