The community-powered index of ALL known public bug bounty and vulnerability disclosure programs, including their safe harbor status.
If you've found a new program, new information on an existing program, or think a program should be deleted, you can contribute to the bug-bounty-list by issuing a pull request (PR) to the repo. If you're new to Github, this article is a good primer on how PRs work.
Programs on the bug-bounty-list need to satisfy the definition of a public bug bounty or vulnerability disclosure program, which means they need two key components:
- A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
- A publicly accessible channel for vulnerability submission which is explicitly mentioned in the vulnerability disclosure policy.
Some examples of suggestions that won't be accepted:
- Private programs
- Invitation-only programs
- Programs that you heard about from a friend but aren't listed publicly
- Programs without a public policy or a nominated channel for communication
- program_name (required): What is the name of the company or product team responsible for the program?
- policy_url (required): Where can the policy which defines the program be found? (Usually a webpage e.g. /security, a URL on a vulnerability management platform, or in a robots.txt or security.txt file).
- submission_url (required): Where does policy say vulnerability submissions should be sent? (Usually a web form, a URL on a vulnerability management platform, or an email address. Emails can be added as URLs using 'mailto:').
- launch_date (optional): When does the program say it was launched?
- bug_bounty (optional): Does the program commit to rewarding vulnerabilities?
- swag (optional): Does the program commit to sending swag out for vulnerabilities?
- hall_of_fame (optional): Does the program have a listing or Hall of Fame page acknowledging vulnerability reporters?
- safe_harbor (required): Does the program support full or partial safe-harbor?
{
"program_name": "Tesla",
"policy_url": "https://bugcrowd.com/tesla",
"submission_url": "https://bugcrowd.com/tesla/report",
"launch_date": "2013-11-26",
"bug_bounty": true,
"swag": false,
"hall_of_fame": true,
"safe_harbor": "full"
},
Example: Tesla
The list supports three safe harbor states: Full, Partial, and None. The flow below will help you determine which applies to the policy as you contribute to the list:
- Does the policy mention anything about legal protections for good-faith hackers? If it does, go to Step 2. If not, then you should choose "None".
- Does the policy talk about authorization of testing and/or an exemption from pre-existing legal terms? In addition, does the policy clearly define the scope of testing, the compensation for valid findings, the official communication channels, and a disclosure policy? If so, you should choose "Full". If not got to Step 3.
- Does the policy talk about "not legally pursuing researchers" or use similar language, but does not explicitly grant authorization and/or exemption for security testing? Are any of the key parameters described above ambiguously defined or missing completely? If so, you should choose "Partial".
- Launch date can be tricky to find on some programs e.g. it's buried in a press release or blog post and not on the program page. If you think you've found a launch date, please include a reference to where you found it in the PR so the maintainers can check.
- Some companies will offer these things on an ad-hoc or case-by-case basis, but this doesn't mean they're committing to do it for everyone. Be careful with the bug_bounty, swag, and hall_of_fame options. As always, read the program page.