chore: update policy #23
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,8 +1,146 @@ | ||
| # Cosmos Security Vulnerability Disclosure and Bug Bounty Policy | ||
|
|
||
| ## Introduction | ||
|
|
||
| Cosmos Labs is committed to the security of the Cosmos Stack and | ||
| encourages responsible disclosure of vulnerabilities. We operate a bug | ||
| bounty program to reward security researchers for discovering and | ||
| reporting issues. | ||
| This policy outlines how to report vulnerabilities, how our bug bounty | ||
| program works, and our approach to patching and disclosing security | ||
| issues. | ||
|
|
||
| ------------------------------------------------------------------------ | ||
|
|
||
| ## Reporting a Vulnerability | ||
|
|
||
| **Private Disclosure:** | ||
| If you discover a potential security vulnerability in Cosmos (e.g., | ||
| Cosmos SDK, CometBFT, IBC, or related core components), report it | ||
| privately through our official channels. | ||
|
|
||
| - **Preferred method:** Report via the [Cosmos HackerOne Bug Bounty | ||
| Program](https://hackerone.com/cosmos). | ||
| - If unable to use HackerOne, you may email: `security@cosmoslabs.io` | ||
| with the vulnerability details (steps to reproduce, impact, etc.). | ||
|
|
||
| > Issues reported via email are *ineligible* for bounty rewards --- only reports through HackerOne qualify. | ||
| When reporting, **do not publicize the issue** (e.g., no public GitHub | ||
| issues or social posts) until we have addressed it and granted | ||
| permission to disclose. | ||
| We may coordinate with you on a public disclosure timeline. | ||
|
|
||
| By reporting to us, you agree to **participate in coordinated | ||
| vulnerability disclosure**, allowing us time to develop and | ||
| distribute a fix before details are made public. | ||
|
|
||
| ------------------------------------------------------------------------ | ||
|
|
||
| ## Bug Bounty Program Overview | ||
|
|
||
| Our bug bounty program rewards valid security bug reports submitted | ||
| through **HackerOne**, where bounty amounts depend on severity and | ||
| impact. | ||
|
|
||
| **Scope:** Core Cosmos Stack components, such as: Cosmos SDK, CometBFT consensus engine, IBC, Cosmos EVM and | ||
| other critical infrastructure | ||
|
|
||
| For full scope, severity definitions, and reward ranges, see the Cosmos | ||
| page on HackerOne. | ||
|
|
||
| We follow a **Safe Harbor** policy to protect researchers acting in good | ||
| faith. The official HackerOne page contains the **Coordinated | ||
| Vulnerability Disclosure Policy** and **Safe Harbor terms**. | ||
| > In case of discrepancies, the HackerOne policy supersedes other | ||
| documents. | ||
|
|
||
| ------------------------------------------------------------------------ | ||
|
|
||
| ## Vulnerability Severity Levels | ||
|
|
||
| All reported vulnerabilities are assigned a severity category guiding how they are handled and disclosed. | ||
|
|
||
| | **Level** | **Description** | **Examples** | | ||
| |--------------|-----------------------------------------------------------------------------------------------------------|---------------------------------------------------------| | ||
| | **Critical** | Bugs posing an existential or network-wide threat (chain halts, consensus failures, inflation, or theft). | Token creation beyond fixed supply, permanent fork bug. | | ||
| | **High** | Major disruption to many nodes or users, often remotely exploitable. | Remote crash or chain halt vulnerability. | | ||
| | **Medium** | Moderate impact or harder to exploit; may require specific configurations. | Slow block propagation, limited DoS. | | ||
| | **Low** | Minor impact or impractical exploitation. | Benign input causing small performance issue. | | ||
|
Comment on lines
+66
to
+69
There was a problem hiding this comment. need to expand on these further and be more specific in the definitions between critical and high. this is probably what security researchers care most about, and here critical and high sound very similar, feels like you could argue any high is a critical based on these defs. |
||
|
|
||
| These levels align with common security practices and determine both | ||
| urgency and disclosure timelines. | ||
|
|
||
| ------------------------------------------------------------------------ | ||
|
|
||
| ## Silent Patch and Disclosure Process | ||
|
|
||
| Cosmos will adopt a **silent patch** approach. Vulnerabilities are fixed | ||
| quietly before disclosure. | ||
| This mirrors practices from projects like **Ethereum's Geth**, **Bitcoin | ||
| Core**, and **Zcash**. | ||
|
|
||
| **Why:** | ||
| Announcing vulnerabilities too early can endanger unpatched nodes. | ||
| Silent fixes allow time for safe upgrades before attackers become aware. | ||
|
|
||
| ### Fix Distribution | ||
|
|
||
| - Fixes are incorporated into new or patch releases. | ||
| - Release notes may **not** mention the security nature of the fix. | ||
| - Validators and node operators are **privately encouraged** to | ||
| upgrade. | ||
| - For critical issues, patches may be **privately distributed** to key | ||
| operators or trigger **emergency upgrades**. | ||
|
|
||
| ### Disclosure Timeline | ||
|
|
||
|
|
||
| ### Disclosure Timeline | ||
|
|
||
| | **Severity** | **Disclosure Timing** | **Details** | | ||
| |------------------|----------------------------------------------------------------------------|-----------------------------------------------------------------------------------------| | ||
| | **Low / Medium** | ~4 weeks after public fix release | Publish full advisory with impact and fix details. | | ||
| | **High** | After the affected version reaches **End-of-Life (EOL)** (~1 year typical) | Mirrors Bitcoin Core's delayed high-severity policy. | | ||
| | **Critical** | **Ad-hoc** (case-by-case) | Disclose only when safe; may delay or omit full details to prevent future exploitation. | | ||
|
|
||
| ------------------------------------------------------------------------ | ||
|
|
||
| ### Advance Notice | ||
|
|
||
| Before disclosing, Cosmos issues a **pre-announcement**, e.g.: | ||
|
|
||
| > "Upcoming security disclosure: vulnerabilities fixed in Cosmos SDK | ||
| > vX.Y.Z will be publicly disclosed on \[Date\]. Please ensure you have | ||
| > upgraded." | ||
| This alerts operators while maintaining security during the embargo. | ||
|
Comment on lines
+109
to
+117
There was a problem hiding this comment. i dont totally get this part, so we have silent releases, but also will announce that patch x.y.z has a security vulnerability in it that we are fixing and will announce what that is in a year? im assuming for a lot of these the security vuln will be the only thing in the patch if we are upgrading the previous release family, so then based on the commit message + this announcement it feels like it defeats the purpose of it being silent. |
||
|
|
||
| ------------------------------------------------------------------------ | ||
|
|
||
| ## Transparency and Post-Disclosure | ||
|
|
||
| Once the embargo period expires, a **Security Advisory** is published | ||
| (via GitHub advisories or blog), detailing: - Vulnerability | ||
| description - Affected versions - Severity - Fix steps - Reporter credit | ||
| (unless anonymity requested) | ||
|
|
||
| Historical advisories remain publicly available. | ||
| This **delayed transparency model** balances immediate safety with | ||
| long-term openness and trust. | ||
|
|
||
| ------------------------------------------------------------------------ | ||
|
|
||
| Cosmos Labs deeply appreciates the work of white-hat hackers and auditors | ||
| whose contributions strengthen the Cosmos ecosystem. | ||
|
|
||
| ------------------------------------------------------------------------ | ||
|
|
||
| ### References | ||
|
|
||
| - [Bitcoin Core Security | ||
| Advisories](https://bitcoincore.org/en/security-advisories/) | ||
| - [Go Ethereum Vulnerability | ||
| Disclosure](https://ethereumpow.github.io/go-ethereum/docs/vulnerabilities/vulnerabilities) | ||
| - [Bitcoin Core Security Disclosure Policy | ||
| Announcement](https://bitexes.com/blog/124272) | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should probably just list out the exact scope here (instead of leaving it at 'other critical infra'), we also should link to the page on hacker one here.