BranchesTags

Repository files navigation

The disclose.io Database (diodb)

What is diodb?

A true, community-powered, vendor agnostic directory of all known VDP and BBPs, contact details, policy location, preferred languages, and the status of:

  • Safeharbor
  • Availability rewards, hall of fame, swag
  • Disclosure policy

Why does diodb exist?

diodb exists to drive the adoption of Safe Harbor for hackers and promote the cybersecurity posture of early adopters, simplify the process of finding the right contacts and channel at an organization, and help both finders and vendors align around the expectations of engagement. It also provides a simple, vendor-agnostic point of engagement for program operators, potential program operators, and the security community to maintain updates to their program.

How to contribute

Getting started

If you have new VDP or bug bounty program information to add, update, or delete in the #diodb open-source vulnerability disclosure and bug bounty program list, we'd love you to contribute by issuing a Pull Request.

If you're new to Github, this article is a good primer on how PRs work. If you'd like to help us create tooling to allow updates without the use of Git and PRs, get in touch at hello@disclose.io.

Adding a new program?

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:

  1. "policy_url" - A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. "contact_url" - A publicly accessible intake channel for vulnerability submissions. This intake channel must be explicitly mentioned in the vulnerability disclosure policy.

If you work with an organization like this, encourage them to launch a formal and public program and point them to disclose.io for helpful tools to assist them along the way!

Other tips

  • 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 "bounty_offered", "swag_offered", and "hall_of_fame" options. As always, read the program page.

Some examples of suggestions that won't be accepted:

Remember, the goal of The disclose.io Project is to drive the adoption of VDP with best practices, so we'll only accept entries that satisfy the Policy and Intake requirement above.

Sometimes, organizations have informal vulnerability reporting setups. While these organizations provide lucky or persistent folks with the option to report issues, this arrangement does NOT constitute a formally established and fully endorsed public VDP.

Some examples of this include:

  1. Private programs
  2. Invitation-only programs
  3. Updates where the intake channel is unlisted or informal in the policy
  4. Programs that you heard about from a friend but aren't listed publicly
  5. Programs without a public policy or a nominated channel for communication
  6. security.txt entries without a valid "policy_url"

License

Creative Commons License
disclose by disclose.io is licensed under a Creative Commons Attribution 4.0 International License.

disclose.io/program-list

The community-powered index of ALL known public bug bounty and vulnerability disclosure programs, including their safe harbor status.

How to contribute

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.

Before you go hunting for new programs to add...

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:

  1. A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. 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:

  1. Private programs
  2. Invitation-only programs
  3. Programs that you heard about from a friend but aren't listed publicly
  4. Programs without a public policy or a nominated channel for communication
  5. Programs

Definition of fields

  • program_name (optional): 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).
  • contact_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 Thanks page, Hall of Fame, or other 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",
"contact_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

How to fill out the safe harbor field

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:

  1. 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".
  2. 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.
  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".

Other tips

  • 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.

About

Open-source vulnerability disclosure and bug bounty program database.

disclose.io

Resources

Readme
License

Code of conduct

Code of conduct
Activity
Custom properties

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Repository files navigation
The disclose.io Database (diodb)
What is diodb?
A true, community-powered, vendor agnostic directory of all known VDP and BBPs, contact details, policy location, preferred languages, and the status of:
  • Safeharbor
  • Availability rewards, hall of fame, swag
  • Disclosure policy
Why does diodb exist?
diodb exists to drive the adoption of Safe Harbor for hackers and promote the cybersecurity posture of early adopters, simplify the process of finding the right contacts and channel at an organization, and help both finders and vendors align around the expectations of engagement. It also provides a simple, vendor-agnostic point of engagement for program operators, potential program operators, and the security community to maintain updates to their program.
How to contribute
Getting started
If you have new VDP or bug bounty program information to add, update, or delete in the #diodb open-source vulnerability disclosure and bug bounty program list, we'd love you to contribute by issuing a Pull Request.
If you're new to Github, this article is a good primer on how PRs work. If you'd like to help us create tooling to allow updates without the use of Git and PRs, get in touch at hello@disclose.io.
Adding a new program?
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:
  1. "policy_url" - A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. "contact_url" - A publicly accessible intake channel for vulnerability submissions. This intake channel must be explicitly mentioned in the vulnerability disclosure policy.
If you work with an organization like this, encourage them to launch a formal and public program and point them to disclose.io for helpful tools to assist them along the way!
Other tips
  • 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 "bounty_offered", "swag_offered", and "hall_of_fame" options. As always, read the program page.
Some examples of suggestions that won't be accepted:
Remember, the goal of The disclose.io Project is to drive the adoption of VDP with best practices, so we'll only accept entries that satisfy the Policy and Intake requirement above.
Sometimes, organizations have informal vulnerability reporting setups. While these organizations provide lucky or persistent folks with the option to report issues, this arrangement does NOT constitute a formally established and fully endorsed public VDP.
Some examples of this include:
  1. Private programs
  2. Invitation-only programs
  3. Updates where the intake channel is unlisted or informal in the policy
  4. Programs that you heard about from a friend but aren't listed publicly
  5. Programs without a public policy or a nominated channel for communication
  6. security.txt entries without a valid "policy_url"
License
Creative Commons License
disclose by disclose.io is licensed under a Creative Commons Attribution 4.0 International License.
disclose.io/program-list
The community-powered index of ALL known public bug bounty and vulnerability disclosure programs, including their safe harbor status.
How to contribute
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.
Before you go hunting for new programs to add...
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:
  1. A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. 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:
  1. Private programs
  2. Invitation-only programs
  3. Programs that you heard about from a friend but aren't listed publicly
  4. Programs without a public policy or a nominated channel for communication
  5. Programs
Definition of fields
  • program_name (optional): 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).
  • contact_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 Thanks page, Hall of Fame, or other 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",
"contact_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
How to fill out the safe harbor field
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:
  1. 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".
  2. 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.
  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".
Other tips
  • 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.
About
Open-source vulnerability disclosure and bug bounty program database.
disclose.io
Resources
Readme
License
Code of conduct
Code of conduct
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
The disclose.io Database (diodb)
What is diodb?
A true, community-powered, vendor agnostic directory of all known VDP and BBPs, contact details, policy location, preferred languages, and the status of:
  • Safeharbor
  • Availability rewards, hall of fame, swag
  • Disclosure policy
Why does diodb exist?
diodb exists to drive the adoption of Safe Harbor for hackers and promote the cybersecurity posture of early adopters, simplify the process of finding the right contacts and channel at an organization, and help both finders and vendors align around the expectations of engagement. It also provides a simple, vendor-agnostic point of engagement for program operators, potential program operators, and the security community to maintain updates to their program.
How to contribute
Getting started
If you have new VDP or bug bounty program information to add, update, or delete in the #diodb open-source vulnerability disclosure and bug bounty program list, we'd love you to contribute by issuing a Pull Request.
If you're new to Github, this article is a good primer on how PRs work. If you'd like to help us create tooling to allow updates without the use of Git and PRs, get in touch at hello@disclose.io.
Adding a new program?
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:
  1. "policy_url" - A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. "contact_url" - A publicly accessible intake channel for vulnerability submissions. This intake channel must be explicitly mentioned in the vulnerability disclosure policy.
If you work with an organization like this, encourage them to launch a formal and public program and point them to disclose.io for helpful tools to assist them along the way!
Other tips
  • 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 "bounty_offered", "swag_offered", and "hall_of_fame" options. As always, read the program page.
Some examples of suggestions that won't be accepted:
Remember, the goal of The disclose.io Project is to drive the adoption of VDP with best practices, so we'll only accept entries that satisfy the Policy and Intake requirement above.
Sometimes, organizations have informal vulnerability reporting setups. While these organizations provide lucky or persistent folks with the option to report issues, this arrangement does NOT constitute a formally established and fully endorsed public VDP.
Some examples of this include:
  1. Private programs
  2. Invitation-only programs
  3. Updates where the intake channel is unlisted or informal in the policy
  4. Programs that you heard about from a friend but aren't listed publicly
  5. Programs without a public policy or a nominated channel for communication
  6. security.txt entries without a valid "policy_url"
License
Creative Commons License
disclose by disclose.io is licensed under a Creative Commons Attribution 4.0 International License.
disclose.io/program-list
The community-powered index of ALL known public bug bounty and vulnerability disclosure programs, including their safe harbor status.
How to contribute
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.
Before you go hunting for new programs to add...
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:
  1. A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. 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:
  1. Private programs
  2. Invitation-only programs
  3. Programs that you heard about from a friend but aren't listed publicly
  4. Programs without a public policy or a nominated channel for communication
  5. Programs
Definition of fields
  • program_name (optional): 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).
  • contact_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 Thanks page, Hall of Fame, or other 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",
"contact_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
How to fill out the safe harbor field
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:
  1. 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".
  2. 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.
  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".
Other tips
  • 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.
About
Open-source vulnerability disclosure and bug bounty program database.
disclose.io
Resources
Readme
License
Code of conduct
Code of conduct
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
The disclose.io Database (diodb)
What is diodb?
A true, community-powered, vendor agnostic directory of all known VDP and BBPs, contact details, policy location, preferred languages, and the status of:
  • Safeharbor
  • Availability rewards, hall of fame, swag
  • Disclosure policy
Why does diodb exist?
diodb exists to drive the adoption of Safe Harbor for hackers and promote the cybersecurity posture of early adopters, simplify the process of finding the right contacts and channel at an organization, and help both finders and vendors align around the expectations of engagement. It also provides a simple, vendor-agnostic point of engagement for program operators, potential program operators, and the security community to maintain updates to their program.
How to contribute
Getting started
If you have new VDP or bug bounty program information to add, update, or delete in the #diodb open-source vulnerability disclosure and bug bounty program list, we'd love you to contribute by issuing a Pull Request.
If you're new to Github, this article is a good primer on how PRs work. If you'd like to help us create tooling to allow updates without the use of Git and PRs, get in touch at hello@disclose.io.
Adding a new program?
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:
  1. "policy_url" - A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. "contact_url" - A publicly accessible intake channel for vulnerability submissions. This intake channel must be explicitly mentioned in the vulnerability disclosure policy.
If you work with an organization like this, encourage them to launch a formal and public program and point them to disclose.io for helpful tools to assist them along the way!
Other tips
  • 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 "bounty_offered", "swag_offered", and "hall_of_fame" options. As always, read the program page.
Some examples of suggestions that won't be accepted:
Remember, the goal of The disclose.io Project is to drive the adoption of VDP with best practices, so we'll only accept entries that satisfy the Policy and Intake requirement above.
Sometimes, organizations have informal vulnerability reporting setups. While these organizations provide lucky or persistent folks with the option to report issues, this arrangement does NOT constitute a formally established and fully endorsed public VDP.
Some examples of this include:
  1. Private programs
  2. Invitation-only programs
  3. Updates where the intake channel is unlisted or informal in the policy
  4. Programs that you heard about from a friend but aren't listed publicly
  5. Programs without a public policy or a nominated channel for communication
  6. security.txt entries without a valid "policy_url"
License
Creative Commons License
disclose by disclose.io is licensed under a Creative Commons Attribution 4.0 International License.
disclose.io/program-list
The community-powered index of ALL known public bug bounty and vulnerability disclosure programs, including their safe harbor status.
How to contribute
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.
Before you go hunting for new programs to add...
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:
  1. A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. 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:
  1. Private programs
  2. Invitation-only programs
  3. Programs that you heard about from a friend but aren't listed publicly
  4. Programs without a public policy or a nominated channel for communication
  5. Programs
Definition of fields
  • program_name (optional): 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).
  • contact_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 Thanks page, Hall of Fame, or other 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",
"contact_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
How to fill out the safe harbor field
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:
  1. 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".
  2. 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.
  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".
Other tips
  • 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.
About
Open-source vulnerability disclosure and bug bounty program database.
disclose.io
Resources
Readme
License
Code of conduct
Code of conduct
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Repository files navigation
The disclose.io Database (diodb)
What is diodb?
A true, community-powered, vendor agnostic directory of all known VDP and BBPs, contact details, policy location, preferred languages, and the status of:
  • Safeharbor
  • Availability rewards, hall of fame, swag
  • Disclosure policy
Why does diodb exist?
diodb exists to drive the adoption of Safe Harbor for hackers and promote the cybersecurity posture of early adopters, simplify the process of finding the right contacts and channel at an organization, and help both finders and vendors align around the expectations of engagement. It also provides a simple, vendor-agnostic point of engagement for program operators, potential program operators, and the security community to maintain updates to their program.
How to contribute
Getting started
If you have new VDP or bug bounty program information to add, update, or delete in the #diodb open-source vulnerability disclosure and bug bounty program list, we'd love you to contribute by issuing a Pull Request.
If you're new to Github, this article is a good primer on how PRs work. If you'd like to help us create tooling to allow updates without the use of Git and PRs, get in touch at hello@disclose.io.
Adding a new program?
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:
  1. "policy_url" - A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. "contact_url" - A publicly accessible intake channel for vulnerability submissions. This intake channel must be explicitly mentioned in the vulnerability disclosure policy.
If you work with an organization like this, encourage them to launch a formal and public program and point them to disclose.io for helpful tools to assist them along the way!
Other tips
  • 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 "bounty_offered", "swag_offered", and "hall_of_fame" options. As always, read the program page.
Some examples of suggestions that won't be accepted:
Remember, the goal of The disclose.io Project is to drive the adoption of VDP with best practices, so we'll only accept entries that satisfy the Policy and Intake requirement above.
Sometimes, organizations have informal vulnerability reporting setups. While these organizations provide lucky or persistent folks with the option to report issues, this arrangement does NOT constitute a formally established and fully endorsed public VDP.
Some examples of this include:
  1. Private programs
  2. Invitation-only programs
  3. Updates where the intake channel is unlisted or informal in the policy
  4. Programs that you heard about from a friend but aren't listed publicly
  5. Programs without a public policy or a nominated channel for communication
  6. security.txt entries without a valid "policy_url"
License
Creative Commons License
disclose by disclose.io is licensed under a Creative Commons Attribution 4.0 International License.
disclose.io/program-list
The community-powered index of ALL known public bug bounty and vulnerability disclosure programs, including their safe harbor status.
How to contribute
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.
Before you go hunting for new programs to add...
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:
  1. A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. 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:
  1. Private programs
  2. Invitation-only programs
  3. Programs that you heard about from a friend but aren't listed publicly
  4. Programs without a public policy or a nominated channel for communication
  5. Programs
Definition of fields
  • program_name (optional): 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).
  • contact_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 Thanks page, Hall of Fame, or other 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",
"contact_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
How to fill out the safe harbor field
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:
  1. 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".
  2. 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.
  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".
Other tips
  • 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.
About
Open-source vulnerability disclosure and bug bounty program database.
disclose.io
Resources
Readme
License
Code of conduct
Code of conduct
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
The disclose.io Database (diodb)
What is diodb?
A true, community-powered, vendor agnostic directory of all known VDP and BBPs, contact details, policy location, preferred languages, and the status of:
  • Safeharbor
  • Availability rewards, hall of fame, swag
  • Disclosure policy
Why does diodb exist?
diodb exists to drive the adoption of Safe Harbor for hackers and promote the cybersecurity posture of early adopters, simplify the process of finding the right contacts and channel at an organization, and help both finders and vendors align around the expectations of engagement. It also provides a simple, vendor-agnostic point of engagement for program operators, potential program operators, and the security community to maintain updates to their program.
How to contribute
Getting started
If you have new VDP or bug bounty program information to add, update, or delete in the #diodb open-source vulnerability disclosure and bug bounty program list, we'd love you to contribute by issuing a Pull Request.
If you're new to Github, this article is a good primer on how PRs work. If you'd like to help us create tooling to allow updates without the use of Git and PRs, get in touch at hello@disclose.io.
Adding a new program?
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:
  1. "policy_url" - A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. "contact_url" - A publicly accessible intake channel for vulnerability submissions. This intake channel must be explicitly mentioned in the vulnerability disclosure policy.
If you work with an organization like this, encourage them to launch a formal and public program and point them to disclose.io for helpful tools to assist them along the way!
Other tips
  • 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 "bounty_offered", "swag_offered", and "hall_of_fame" options. As always, read the program page.
Some examples of suggestions that won't be accepted:
Remember, the goal of The disclose.io Project is to drive the adoption of VDP with best practices, so we'll only accept entries that satisfy the Policy and Intake requirement above.
Sometimes, organizations have informal vulnerability reporting setups. While these organizations provide lucky or persistent folks with the option to report issues, this arrangement does NOT constitute a formally established and fully endorsed public VDP.
Some examples of this include:
  1. Private programs
  2. Invitation-only programs
  3. Updates where the intake channel is unlisted or informal in the policy
  4. Programs that you heard about from a friend but aren't listed publicly
  5. Programs without a public policy or a nominated channel for communication
  6. security.txt entries without a valid "policy_url"
License
Creative Commons License
disclose by disclose.io is licensed under a Creative Commons Attribution 4.0 International License.
disclose.io/program-list
The community-powered index of ALL known public bug bounty and vulnerability disclosure programs, including their safe harbor status.
How to contribute
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.
Before you go hunting for new programs to add...
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:
  1. A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. 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:
  1. Private programs
  2. Invitation-only programs
  3. Programs that you heard about from a friend but aren't listed publicly
  4. Programs without a public policy or a nominated channel for communication
  5. Programs
Definition of fields
  • program_name (optional): 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).
  • contact_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 Thanks page, Hall of Fame, or other 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",
"contact_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
How to fill out the safe harbor field
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:
  1. 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".
  2. 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.
  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".
Other tips
  • 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.
About
Open-source vulnerability disclosure and bug bounty program database.
disclose.io
Resources
Readme
License
Code of conduct
Code of conduct
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
The disclose.io Database (diodb)
What is diodb?
A true, community-powered, vendor agnostic directory of all known VDP and BBPs, contact details, policy location, preferred languages, and the status of:
  • Safeharbor
  • Availability rewards, hall of fame, swag
  • Disclosure policy
Why does diodb exist?
diodb exists to drive the adoption of Safe Harbor for hackers and promote the cybersecurity posture of early adopters, simplify the process of finding the right contacts and channel at an organization, and help both finders and vendors align around the expectations of engagement. It also provides a simple, vendor-agnostic point of engagement for program operators, potential program operators, and the security community to maintain updates to their program.
How to contribute
Getting started
If you have new VDP or bug bounty program information to add, update, or delete in the #diodb open-source vulnerability disclosure and bug bounty program list, we'd love you to contribute by issuing a Pull Request.
If you're new to Github, this article is a good primer on how PRs work. If you'd like to help us create tooling to allow updates without the use of Git and PRs, get in touch at hello@disclose.io.
Adding a new program?
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:
  1. "policy_url" - A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. "contact_url" - A publicly accessible intake channel for vulnerability submissions. This intake channel must be explicitly mentioned in the vulnerability disclosure policy.
If you work with an organization like this, encourage them to launch a formal and public program and point them to disclose.io for helpful tools to assist them along the way!
Other tips
  • 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 "bounty_offered", "swag_offered", and "hall_of_fame" options. As always, read the program page.
Some examples of suggestions that won't be accepted:
Remember, the goal of The disclose.io Project is to drive the adoption of VDP with best practices, so we'll only accept entries that satisfy the Policy and Intake requirement above.
Sometimes, organizations have informal vulnerability reporting setups. While these organizations provide lucky or persistent folks with the option to report issues, this arrangement does NOT constitute a formally established and fully endorsed public VDP.
Some examples of this include:
  1. Private programs
  2. Invitation-only programs
  3. Updates where the intake channel is unlisted or informal in the policy
  4. Programs that you heard about from a friend but aren't listed publicly
  5. Programs without a public policy or a nominated channel for communication
  6. security.txt entries without a valid "policy_url"
License
Creative Commons License
disclose by disclose.io is licensed under a Creative Commons Attribution 4.0 International License.
disclose.io/program-list
The community-powered index of ALL known public bug bounty and vulnerability disclosure programs, including their safe harbor status.
How to contribute
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.
Before you go hunting for new programs to add...
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:
  1. A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. 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:
  1. Private programs
  2. Invitation-only programs
  3. Programs that you heard about from a friend but aren't listed publicly
  4. Programs without a public policy or a nominated channel for communication
  5. Programs
Definition of fields
  • program_name (optional): 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).
  • contact_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 Thanks page, Hall of Fame, or other 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",
"contact_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
How to fill out the safe harbor field
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:
  1. 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".
  2. 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.
  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".
Other tips
  • 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.
About
Open-source vulnerability disclosure and bug bounty program database.
disclose.io
Resources
Readme
License
Code of conduct
Code of conduct
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Repository files navigation
The disclose.io Database (diodb)
What is diodb?
A true, community-powered, vendor agnostic directory of all known VDP and BBPs, contact details, policy location, preferred languages, and the status of:
  • Safeharbor
  • Availability rewards, hall of fame, swag
  • Disclosure policy
Why does diodb exist?
diodb exists to drive the adoption of Safe Harbor for hackers and promote the cybersecurity posture of early adopters, simplify the process of finding the right contacts and channel at an organization, and help both finders and vendors align around the expectations of engagement. It also provides a simple, vendor-agnostic point of engagement for program operators, potential program operators, and the security community to maintain updates to their program.
How to contribute
Getting started
If you have new VDP or bug bounty program information to add, update, or delete in the #diodb open-source vulnerability disclosure and bug bounty program list, we'd love you to contribute by issuing a Pull Request.
If you're new to Github, this article is a good primer on how PRs work. If you'd like to help us create tooling to allow updates without the use of Git and PRs, get in touch at hello@disclose.io.
Adding a new program?
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:
  1. "policy_url" - A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. "contact_url" - A publicly accessible intake channel for vulnerability submissions. This intake channel must be explicitly mentioned in the vulnerability disclosure policy.
If you work with an organization like this, encourage them to launch a formal and public program and point them to disclose.io for helpful tools to assist them along the way!
Other tips
  • 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 "bounty_offered", "swag_offered", and "hall_of_fame" options. As always, read the program page.
Some examples of suggestions that won't be accepted:
Remember, the goal of The disclose.io Project is to drive the adoption of VDP with best practices, so we'll only accept entries that satisfy the Policy and Intake requirement above.
Sometimes, organizations have informal vulnerability reporting setups. While these organizations provide lucky or persistent folks with the option to report issues, this arrangement does NOT constitute a formally established and fully endorsed public VDP.
Some examples of this include:
  1. Private programs
  2. Invitation-only programs
  3. Updates where the intake channel is unlisted or informal in the policy
  4. Programs that you heard about from a friend but aren't listed publicly
  5. Programs without a public policy or a nominated channel for communication
  6. security.txt entries without a valid "policy_url"
License
Creative Commons License
disclose by disclose.io is licensed under a Creative Commons Attribution 4.0 International License.
disclose.io/program-list
The community-powered index of ALL known public bug bounty and vulnerability disclosure programs, including their safe harbor status.
How to contribute
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.
Before you go hunting for new programs to add...
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:
  1. A publicly accessible vulnerability disclosure policy, sometimes called a program brief or bounty brief, and
  2. 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:
  1. Private programs
  2. Invitation-only programs
  3. Programs that you heard about from a friend but aren't listed publicly
  4. Programs without a public policy or a nominated channel for communication
  5. Programs
Definition of fields
  • program_name (optional): 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).
  • contact_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 Thanks page, Hall of Fame, or other 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",
"contact_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
How to fill out the safe harbor field
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:
  1. 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".
  2. 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.
  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".
Other tips
  • 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.
About
Open-source vulnerability disclosure and bug bounty program database.
disclose.io
Resources
Readme
License
Code of conduct
Code of conduct
Activity
Custom properties
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages