Skip to content
This is a fork of Amit Elazari's #legalbugbounty project at Berkley's CLTC, aimed at updating for real-world use.
Branch: master
Clone or download
Pull request Compare This branch is 32 commits ahead of EdOverflow:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
templates
LICENSE.md
README.md
_config.yml

README.md

Legal bug bounty

This is a fork of the #legalbugbounty standardization project. As Amit Elazari explains in her Enigma talk and her papers - the legal landscape of bug bounties is currently lacking. Safe harbor is the exception, not the standard and thousands of thousands of hunters are put in "legal" harm's way. Bug bounty legal terms, starting with safe harbor, can and should be standardized. Once standardization of bug bounty legal language is achieved, the bug bounty economy will be a viable alternate private legal regime in which white-hat hacking is celebrated and rewarded through regulatory incentives.

This fork aims to update Amit's project based on multi-year real world experience with common issues faced by hunters when considering whether to participate in a bug bounty program. Where it deviates from prosecution-biased templates like the DOJ framework, it does so with an eye toward greater protection for bounty participants and submitters, without limiting a company's ability to stop platform abuse or misuse.

Standardization will start a race-to-the-top over the quality of bug bounty terms. This project aims to achieve standardization of bug bounty legal terms across platforms, industries and sponsors, drawing from the DOJ framework and other best-practice proposals, and akin to the licenses employed by Creative Commons and the open source industry. This will reduce the informational burden and increase hackers’ awareness of terms (salience). It could also signal whether a particular platform or company conforms with the standard terms that are considered best practice.

Finally, it could reduce the drafting costs of the platform or sponsoring program, as well as the transactional costs. While some organizations (such as governmental or financial organizations) might require adjustments, generally the legal concerns of bug bounties’ sponsors and platforms are similar and could be addressed in standardized language. Moreover, standardization should be used to ensure that hackers have authorized access to any third-parties data or components implemented in the bug bounty administrator product/network, and to facilitate coordinated disclosure of third-party vulnerabilities found. Companies and platforms should coordinate to ensure that such clauses are included in all terms, facilitating a best practice mentality in the industry.

The benefits of standardization in bug bounties/CVDs of legal language across industries and platforms

  • One language of safe harbor akin to Creative Commons/Open Source;
  • Create an industry standard that will serve as a benchmark and signal to hackers if companies don’t adopt it;
  • Reduce the informational burden and increase hackers’ awareness towards terms;
  • Reduce transaction and drafting costs;
  • Create a reputation system for legal terms.

⚖ Legal disclaimer

⚠ You must consult with a lawyer before using anything on this repo.

This report and all included templates and materials do not constitute legal advice, and the author(s) is(are) not your lawyer(s). The information within is for general guidance and discussion only. The application and impact of laws can vary widely based on the specific facts involved. Given the changing nature of laws, terms, rules and regulations, there may be delays, omissions, or inaccuracies in information contained here. Accordingly, the information is provided with the understanding that the authors are not engaged in rendering legal or other professional advice and services. As such, it should not be used as a substitute for consultation with professional legal or other competent advisers. Before making any decision or taking any action, you should consult a lawyer admitted to practice in your and other relevant jurisdictions. All information is provided “as is”, with no guarantee of completeness, accuracy, timeliness or of the results obtained from the use of this information, and without warranty of any kind, express or implied, including, but not limited to warranties of performance, merchantability and fitness for a particular purpose. In no event will the author be liable to you or anyone else for any decision made or action taken in reliance on the information herein or for any consequential, special or similar damages. This disclaimer does not appear on all pages, but should be read as applying to every page within this repo.

Bug bounty program policies are a highly fact-specific and company-specific decision, and relevant laws, rules, and regulations may vary based on many factors. A lawyer admitted in the relevant jurisdiction(s) for your situation should be consulted before adopting any of the template language here.

About this project

This is a fork of the #legalbugbounty project, and is not affiliated with or supported or endorsed by CLTC, UC Berkeley, or any other person involved with that #legalbugbounty project.

You can’t perform that action at this time.