Update SECURITY.md (backport cometbft#1626) (cometbft#1634)

* Update SECURITY.md (cometbft#1626)

Signed-off-by: Thane Thomson <connect@thanethomson.com>
(cherry picked from commit 62a97f2)

# Conflicts:
#	SECURITY.md

* Resolve conflicts

Signed-off-by: Thane Thomson <connect@thanethomson.com>

---------

Signed-off-by: Thane Thomson <connect@thanethomson.com>
Co-authored-by: Thane Thomson <connect@thanethomson.com>

SECURITY.md

@@ -1,208 +1,33 @@
-# Security
+# How to Report a Security Bug
 
-## Reporting a Bug
+If you believe you have found a security vulnerability in the Interchain Stack,
+you can report it to our primary vulnerability disclosure channel, the [Cosmos
+HackerOne Bug Bounty program][h1].
 
-As part of our Coordinated Vulnerability Disclosure Policy (link will be added
-once this policy is finalized for CometBFT), we operate a [bug
-bounty][hackerone]. See the policy for more details on submissions and rewards,
-and see "Example Vulnerabilities" (below) for examples of the kinds of bugs
-we're most interested in.
+If you prefer to report an issue via email, you may send a bug report to
+<security@interchain.io> with the issue details, reproduction, impact, and other
+information. Please submit only one unique email thread per vulnerability. Any
+issues reported via email are ineligible for bounty rewards.
 
-### Guidelines
+Artifacts from an email report are saved at the time the email is triaged.
+Please note: our team is not able to monitor dynamic content (e.g. a Google Docs
+link that is edited after receipt) throughout the lifecycle of a report. If you
+would like to share additional information or modify previous information,
+please include it in an additional reply as an additional attachment.
 
-We require that all researchers:
+Please **DO NOT** file a public issue in this repository to report a security
+vulnerability.
 
-* Use the bug bounty to disclose all vulnerabilities, and avoid posting
-  vulnerability information in public places, including GitHub Issues, Discord
-  channels, and Telegram groups
-* Make every effort to avoid privacy violations, degradation of user experience,
-  disruption to production systems (including but not limited to the Cosmos
-  Hub), and destruction of data
-* Keep any information about vulnerabilities that you’ve discovered confidential
-  between yourself and the CometBFT engineering team until the issue has been
-  resolved and disclosed
-* Avoid posting personally identifiable information, privately or publicly
+## Coordinated Vulnerability Disclosure Policy and Safe Harbor
 
-If you follow these guidelines when reporting an issue to us, we commit to:
+For the most up-to-date version of the policies that govern vulnerability
+disclosure, please consult the [HackerOne program page][h1-policy].
 
-* Not pursue or support any legal action related to your research on this
-  vulnerability
-* Work with you to understand, resolve and ultimately disclose the issue in a
-  timely fashion
+The policy hosted on HackerOne is the official Coordinated Vulnerability
+Disclosure policy and Safe Harbor for the Interchain Stack, and the teams and
+infrastructure it supports, and it supersedes previous security policies that
+have been used in the past by individual teams and projects with targets in
+scope of the program.
 
-## Disclosure Process
-
-CometBFT uses the following disclosure process:
-
-1. Once a security report is received, the CometBFT team works to verify the
-   issue and confirm its severity level using CVSS.
-2. The CometBFT team collaborates with the Gaia team to determine the
-   vulnerability’s potential impact on the Cosmos Hub.
-3. Patches are prepared for eligible releases of CometBFT in private
-   repositories. See “Supported Releases” below for more information on which
-   releases are considered eligible.
-4. If it is determined that a CVE-ID is required, we request a CVE through a CVE
-   Numbering Authority.
-5. We notify the community that a security release is coming, to give users time
-   to prepare their systems for the update. Notifications can include forum
-   posts, tweets, and emails to partners and validators.
-6. 24 hours following this notification, the fixes are applied publicly and new
-   releases are issued.
-7. Cosmos SDK and Gaia update their CometBFT dependencies to use these releases,
-   and then themselves issue new releases.
-8. Once releases are available for CometBFT, Cosmos SDK and Gaia, we notify the
-   community, again, through the same channels as above. We also publish a
-   Security Advisory on GitHub and publish the CVE, as long as neither the
-   Security Advisory nor the CVE include any information on how to exploit these
-   vulnerabilities beyond what information is already available in the patch
-   itself.
-9. Once the community is notified, we will pay out any relevant bug bounties to
-   submitters.
-10. One week after the releases go out, we will publish a post with further
-    details on the vulnerability as well as our response to it.
-
-This process can take some time. Every effort will be made to handle the bug in
-as timely a manner as possible, however it's important that we follow the
-process described above to ensure that disclosures are handled consistently and
-to keep CometBFT and its downstream dependent projects--including but not
-limited to Gaia and the Cosmos Hub--as secure as possible.
-
-### Example Timeline
-
-The following is an example timeline for the triage and response. The required
-roles and team members are described in parentheses after each task; however,
-multiple people can play each role and each person may play multiple roles.
-
-#### 24+ Hours Before Release Time
-
-1. Request CVE number (ADMIN)
-2. Gather emails and other contact info for validators (COMMS LEAD)
-3. Create patches in a private security repo, and ensure that PRs are open
-   targeting all relevant release branches (CometBFT ENG, CometBFT LEAD)
-4. Test fixes on a testnet  (CometBFT ENG, COSMOS SDK ENG)
-5. Write “Security Advisory” for forum (CometBFT LEAD)
-
-#### 24 Hours Before Release Time
-
-1. Post “Security Advisory” pre-notification on forum (CometBFT LEAD)
-2. Post Tweet linking to forum post (COMMS LEAD)
-3. Announce security advisory/link to post in various other social channels
-   (Telegram, Discord) (COMMS LEAD)
-4. Send emails to validators or other users (PARTNERSHIPS LEAD)
-
-#### Release Time
-
-1. Cut CometBFT releases for eligible versions (CometBFT ENG, CometBFT
-   LEAD)
-2. Cut Cosmos SDK release for eligible versions (COSMOS ENG)
-3. Cut Gaia release for eligible versions (GAIA ENG)
-4. Post “Security releases” on forum (CometBFT LEAD)
-5. Post new Tweet linking to forum post (COMMS LEAD)
-6. Remind everyone via social channels (Telegram, Discord)  that the release is
-   out (COMMS LEAD)
-7. Send emails to validators or other users (COMMS LEAD)
-8. Publish Security Advisory and CVE, if CVE has no sensitive information
-   (ADMIN)
-
-#### After Release Time
-
-1. Write forum post with exploit details (CometBFT LEAD)
-2. Approve pay-out on HackerOne for submitter (ADMIN)
-
-#### 7 Days After Release Time
-
-1. Publish CVE if it has not yet been published (ADMIN)
-2. Publish forum post with exploit details (CometBFT ENG, CometBFT LEAD)
-
-## Supported Releases
-
-The CometBFT team commits to releasing security patch releases for both
-the latest minor release as well for the major/minor release that the Cosmos Hub
-is running.
-
-If you are running older versions of CometBFT, we encourage you to
-upgrade at your earliest opportunity so that you can receive security patches
-directly from the CometBFT repo. While you are welcome to backport security
-patches to older versions for your own use, we will not publish or promote these
-backports.
-
-## Scope
-
-The full scope of our bug bounty program is outlined on our
-[Hacker One program page][hackerone]. Please also note that, in the interest of
-the safety of our users and staff, a few things are explicitly excluded from
-scope:
-
-* Any third-party services
-* Findings from physical testing, such as office access
-* Findings derived from social engineering (e.g., phishing)
-
-## Example Vulnerabilities
-
-The following is a list of examples of the kinds of vulnerabilities that we’re
-most interested in. It is not exhaustive: there are other kinds of issues we may
-also be interested in!
-
-### Specification
-
-* Conceptual flaws
-* Ambiguities, inconsistencies, or incorrect statements
-* Mis-match between specification and implementation of any component
-
-### Consensus
-
-Assuming less than 1/3 of the voting power is Byzantine (malicious):
-
-* Validation of blockchain data structures, including blocks, block parts,
-  votes, and so on
-* Execution of blocks
-* Validator set changes
-* Proposer round robin
-* Two nodes committing conflicting blocks for the same height (safety failure)
-* A correct node signing conflicting votes
-* A node halting (liveness failure)
-* Syncing new and old nodes
-
-Assuming more than 1/3 the voting power is Byzantine:
-
-* Attacks that go unpunished (unhandled evidence)
-
-### Networking
-
-* Authenticated encryption (MITM, information leakage)
-* Eclipse attacks
-* Sybil attacks
-* Long-range attacks
-* Denial-of-Service
-
-### RPC
-
-* Write-access to anything besides sending transactions
-* Denial-of-Service
-* Leakage of secrets
-
-### Denial-of-Service
-
-Attacks may come through the P2P network or the RPC layer:
-
-* Amplification attacks
-* Resource abuse
-* Deadlocks and race conditions
-
-### Libraries
-
-* Serialization
-* Reading/Writing files and databases
-
-### Cryptography
-
-* Elliptic curves for validator signatures
-* Hash algorithms and Merkle trees for block validation
-* Authenticated encryption for P2P connections
-
-### Light Client
-
-* Core verification
-* Bisection/sequential algorithms
-
-[hackerone]: https://hackerone.com/cosmos
+[h1]: https://hackerone.com/cosmos?type=team
+[h1-policy]: https://hackerone.com/cosmos?type=team&view_policy=true