Note: While we've engaged the legal opinion of many, this does not constitute legal advice. Please consult your legal counsel for the specific suitability of the disclose.io terms in your organization.)
| Take me to... | Link |
|---|---|
| Create a Vulnerability Disclosure Program | https://policymaker.disclose.io/ |
| Learn more at the disclose.io Community Forum | https://community.disclose.io |
| Compare thousands of existing company policies | https://disclose.io/programs |
- Core terms: The core terms are the primary documents in the repo. The language in these terms is designed to provide maximum flexibility whilst maintaining bi-lateral safety and readability, and accommodating varying legal environments for both the finder and the vendor. Note that while the bug bounty terms are a subset of the vulnerability disclosure policy VDP terms with additional fields regarding rewards and scope, we've chosen to separate them to avoid ambiguity between a VDP and a bug bounty.
- Core modules: The core modules are derived from the Core terms, which are the basis for language and regional legal translation.
- Regionalized terms: The regionalized terms have been contributed by PSIRTS, disclosure platforms, security policy advocates, and vendor program operators.
- Archive: This folder contains deprecated or archived terms for posterity and easy reference.
Organizations should first choose the boilerplate that is the best fit to their organization. The dioterms repo contains a number of different options:
- Core terms for VDP and BBP designed to provide maximum flexibility whilst maintaining bi-lateral safety and readability,
- Regionalized terms which accommodate the laws and languages of country or jurisdiction of the organization,
- Verticalized terms which take the nuances of different industries or use-cases (e.g. election infrastructure) into account, and
- Simple Safe Harbor which is designed to add Safe Harbor language to VDPs and bug bounty programs which are already in place.
The core requirements for disclose.io's definition of Full Safe Harbor are for the policy to provide:
- Authorization against anti-hacking laws
- Exemption from anti-circumvention laws
- Exemption from violation of the TOS/AUP during security testing
- A statement acknowledging good-faith.
The intention of Safe Harbor language provided by disclose.io is for it to be followed specifically, with minor, if any, modifications. If modifications are made, the four tenets laid out above are the most important to address in your policy.
Policies missing any of the core tenets above, but that still contain a good-faith statement committing not to pursue legal action on security researchers, meet the criteria for Partial Safe Harbor.
Note: Incentives or "bounties" for vulnerability reports are not a prerequisite for Safe Harbor or for a program to be considered a VDP.
- Coordinated Disclosure: A researcher can share details of the vulnerability after a fix has been applied and the program owner has provided permission to disclose or after a clearly-stated time has passed from submission, whichever is sooner;
- Discretionary Disclosure: The researcher or the program owner can request mutual permission to share details of the vulnerability after approval is explicitly received; or
- Non-Disclosure: Researchers are required to keep vulnerability details and the existence of the program itself confidential, regardless of the fix or any conversations between them and the vendor. Note that non-disclosure is considered inappropriate and generally ineffective as a disclosure type for VDPs.
Disclose.io maintains five levels of best-practice attainment:
- security.txt: The subdomain/domain contains a security.txt file only.
- Basic: A publicly available Policy and Official Channel exist.
- Partial: Basic, with the addition of Partial Safe Harbor provisions.
- Full: Basic, with the addition of Full Safe Harbor provisions.
- Full with CVD: Full, with the addition of a Coordinated Disclosure Policy that includes a proactive disclosure timeline.
In each template we've also provided boilerplate examples for the additional section.
- Scope (Required) – A complete list of "In-Scope" properties for which the organization is explicitly allowing and encouraging good-faith security research. Keep in mind that a true vulnerability disclosure program considers the entire attack surface of the organization running the program, so erring on the side of inclusiveness is best practice with respect to scope.
- Out-of-Scope (Optional) - A non-exhaustive list of systems and security testing activities that the organization strongly wishes to discourage testing against, and
- Rewards (Optional) – Information on whether or not the program offers payment for valid, unique issues, as well as the type and parameters of that compensation.
- Official Communication Channels (Required) – A full list of the communication methods that are made available by the organization to receive and communicate about vulnerability submissions.
- Disclosure Policy (Required) – A clear policy outlining the conditions under which a researcher can disclose the details of a reported issue to third parties.
Once you've published your policy, you can:
- Add the appropriate disclose.io seal to your public program brief,
- Submit a pull request to add your program to the open-source disclose.io program list,
- Let the world know you're joining the initiative!
- Contribute back to the disclose.io project!