# The Monero Project Vulnerability Response Process
## Preamble
1. Researchers/Hackers: while you research/hack, we ask that you please refrain from committing the following:
- Denial of Service / Active exploiting against the Monero/Kovri networks
- Social Engineering of Monero/Kovri Project staff or contractors
- Any physical or electronic attempts against Monero/Kovri community property and/or data centers
2. As a pro-privacy project we have volunteers running copies of the websites on hidden services on Tor and I2P, as well as on multiple public domains. **The live sites are NOT in the scope of this process; only the code is!**
3. While **Kovri** is in a pre-Alpha release state, HackerOne should not be used for disclosure. All **Kovri** issues should be directed to [GitHub](https://github.com/monero-project/kovri)
4. Bounty will be released for all projects in Monero XMR only. For more information on how to use Monero, visit the [Monero website](https://getmonero.org)
5. Bounty will not be available for **Kovri** until **Kovri Beta** is released
- i. Response Manager responds with reasons why submission is not a vulnerability
- ii. Response Manager moves discussion to a new or existing ticket on GitHub if necessary
5. If over email, Response Manager opens a HackerOne issue for new submission
6. Establish severity of vulnerability:
- a. HIGH: impacts network as a whole, has potential to break entire monero/kovri network, results in the loss of monero, or is on a scale of great catastrophe
- b. MEDIUM: impacts individual nodes, routers, wallets, or must be carefully exploited
7. Respond according to the severity of the vulnerability:
- a. HIGH severities must be notified on website and reddit /r/Monero (/r/Kovri for kovri) within 3 working days of classification
- i. The notification should list appropriate steps for users to take, if any
- ii. The notification must not include any details that could suggest an exploitation path
- iii. The latter takes precedence over the former
- b. MEDIUM and HIGH severities will require a Point Release
- c. LOW severities will be addressed in the next Regular Release
8. Response Team applies appropriate patch(es)
- a. Response Manager designates a PRIVATE git "hotfix branch" to work in
- b. Patches are reviewed with the researcher
- c. Any messages associated with PUBLIC commits during the time of review should not make reference to the security nature of the PRIVATE branch or its commits
- d. Vulnerability announcement is drafted
- i. Include the severity of the vulnerability
- ii. Include all vulnerable systems/apps/code
- iii. Include solutions (if any) if patch cannot be applied
- e. Release date is discussed
9. At release date, Response Team coordinates with developers to finalize update:
- a. Response Manager propagates the "hotfix branch" to trunk
- b. Response Manager includes vulnerability announcement draft in release notes
- b. Finalize vulnerability announcement draft and include the following:
- i. Project name and URL
- ii. Versions known to be affected
- iii. Versions known to be not affected (for example, the vulnerable code was introduced in a recent version, and older versions are therefore unaffected)
- iv. Versions not checked
- v. Type of vulnerability and its impact
- vi. If already obtained or applicable, a CVE-ID
- vii. The planned, coordinated release date
- viii. Mitigating factors (for example, the vulnerability is only exposed in uncommon, non-default configurations)
- ix. Workarounds (configuration changes users can make to reduce their exposure to the vulnerability)
- x. If applicable, credits to the original reporter
- c. Release finalized vulnerability announcement on website and reddit /r/Monero (/r/Kovri for kovri)
- d. For HIGH severities, release finalized vulnerability announcement on well-known mailing lists:
- i. oss-security@lists.openwall.com
- ii. bugtraq@securityfocus.com
- e. If applicable, developers request a CVE-ID
- i. The commit that applied the fix is made reference too in a future commit and includes a CVE-ID
3. If the Incident Response process in section III is *not* successfully completed:
- a. Response Team and developers organize an IRC meeting to discuss why/what points in section III were not resolved and how the team can resolve them in the future
- b. Any developer meetings immediately following the incident should include points made in section V
- c. If disputes arise about whether or when to disclose information about a vulnerability, the Response Team will publicly discuss the issue via IRC and attempt to reach consensus
- d. If consensus on a timely disclosure is not met (no later than 90 days), the researcher (after 90 days) has every right to expose the vulnerability to the public
- Total availability of XMR bounty can be tracked [here](https://forum.getmonero.org/8/funding-required/87597/monero-bounty-for-hackerone). XMR market values can be found at the various exchanges. See also [Cryptowatch](https://cryptowat.ch/) and [Live Coin Watch](https://www.livecoinwatch.com/).
- As reports come in and payouts are made, the total bounty supply shrinks. This gives incentive for bug hunters to report bugs a.s.a.p.
- The following percentages apply to available XMR bounty (severity is defined above in section III. 6.):
1. 10% reserved for LOW severity bugs
2. 30% reserved for MEDIUM severity bugs
3. 60% for HIGH severity bugs
- Each bug will at most receive 10% of each category. Example: 10% of 60% for a HIGH severity bug.
Any further questions or resolutions regarding the incident(s) between the researcher and response + development team after public disclosure can be addressed via the following:
