gaurav5430/dioterms

Open-source vulnerability disclosure policies.

The disclose.io Terms

Our Vision: A healthy and ubiquitous Internet Immune System
Our Mission: To drive vulnerability disclosure adoption through safety, simplicity, and standardization.

disclose.io is a collaborative and vendor-agnostic movement that engages security researchers, corporate and independent legal experts, and industry leaders from all around the world.

The goal of the project is to support the accelerated adoption of vulnerability disclosure best practices including bi-lateral safe harbor, readability for non-legal and non-native language audiences, and a recognizable mark of solidarity with the disclose.io movement.

For a more complete overview of disclose.io, a presentation from GRIMMCon is available here, and a video walkthrough of the project is available here.

Getting started

(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.)

1. Choose the legal terms that best fit your vulnerabilty disclosure or bug bounty progam.
2. Add the appropriate disclose.io logo to your public program brief.
3. Submit a pull request to add your program to the open-source disclose.io program list.
4. Let the world know you're joining the movement!
5. Contribute back! We're looking for lawyers, hackers, and experts to collaborate. Check our issues log.

Core terms

Choose your region or vertical, choose your language, and go!

The core requirements for safe harbor:

• Authorization against anti-hacking laws
• Exemption from anti-circumvention laws
• Exemption from violation of the TOS/AUP during security testing
• Statement of support and agreement.

The intention of the safe harbor language 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.

Additional terms

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.

Simple Safe Harbor

If you already have a disclosure program, the Simple Safe Harbor terms may suffice. These terms were written to be even more generic and simple to understand than the core terms, whilst still maxmizing legal completeness.

Example disclosure types

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

License

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