diff --git a/SECURITY.md b/SECURITY.md index aa5749920a..0405b223b8 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -11,8 +11,64 @@ email to security@solana.com and provide your github username so we can add you to a new draft security advisory for further discussion. +DO NOT include attachments or provide detail sufficient for exploitation regarding the security issue in this email. +DO send the email from an email domain that is less likely to get flagged for spam by gmail. + Expect a response as fast as possible, typically within 72 hours. +If you do not receive a response within that time frame, please do followup with the team directly. You can do this through discord (#core-technology) by pinging the admins of the channel and referencing the fact that you submitted a security bounty. + +As above, please DO NOT include attachments or provide detail regarding the security issue in this email. + +## Incident Response Process + +In case an incident is discovered or reported, the following process will be followed to contain, respond and remediate: + +# 1. Establish a new draft security advisory +In response to an email to security@solana.com, a member of the solana-labs/admins group will +Create a new draft security advisory for the incident at https://github.com/solana-labs/solana/security/advisories +Add the reporter's github user and the solana-labs/security-incident-response group to the draft security advisory +Create a private fork of the repository (grey button towards the bottom of the page) +Respond to the reporter by email, sharing a link to the draft security advisory + +# 2. Triage +Within the draft security advisory, discuss and determine the severity of the issue. If necessary, members of the solana-labs/security-incident-response group may add other github users to the advisory to assist. +If it is determined that this not a critical network issue then the advisory should be closed and if more follow-up is required a normal Solana public github issue should be created. + +# 3. Prepare Fixes +For the affected branches, typically all three (edge, beta and stable), prepare a fix for the issue and push them to the corresponding branch in the private repository associated with the draft security advisory. +There is no CI available in the private repository so you must build from source and manually verify fixes. +Code review from the reporter is ideal, as well as from multiple members of the core development team. + +# 4. Notify Security Group Validators +Once an ETA is available for the fix, a member of the solana-labs/security-incident-response group should notify the validators so they can prepare for an update using the "Solana Red Alert" notification system. +The teams are all over the world and it's critical to provide actionable information at the right time. Don't be the person that wakes everybody up at 2am when a fix won't be available for hours. + +# 5. Ship the patch +Once the fix is accepted, a member of the solana-labs/security-incident-response group should prepare a single patch file for each affected branch. The commit title for the patch should only contain the advisory id, and not disclose any further details about the incident. +Copy the patches to https://release.solana.com/ under a subdirectory named after the advisory id (example: https://release.solana.com/GHSA-hx59-f5g4-jghh/v1.4.patch). Contact a member of the solana-labs/admins group if you require access to release.solana.com +Using the "Solana Red Alert" channel: + a) Notify validators that there's an issue and a patch will be provided in X minutes + b) If X minutes expires and there's no patch, notify of the delay and provide a new ETA + c) Provide links to patches of https://release.solana.com/ for each affected branch +Validators can be expected to build the patch from source against the latest release for the affected branch. +Since the software version will not change after the patch is applied, request that each validator notify in the existing channel once they've updated. Manually monitor the roll out until a sufficient amount of stake has updated - typically at least 33.3% or 66.6% depending on the issue. + +# 6. Public Disclosure and Release +Once the fix has been deployed to the security group validators, the patches from the security advisory may be merged into the main source repository. A new official release for each affected branch should be shipped and all validators requested to upgrade as quickly as possible. + +# 7. Security Advisory Bounty Accounting and Cleanup +If this issue is eligible for a bounty, prefix the title of the security advisory with one of the following, depending on the severity: +[Bounty Category: Critical: Loss of Funds] +[Bounty Category: Critical: Consensus / Safety Violations] +[Bounty Category: Critical: Liveness / Loss of Availability] +[Bounty Category: Critical: DoS Attacks] +[Bounty Category: Supply Chain Attacks] +[Bounty Category: RPC] +Confirm with the reporter that they agree with the severity assessment, and discuss as required to reach a conclusion. + +We currently do not use the Github workflow to publish security advisories. Once the issue and fix have been disclosed, and a bounty category is assessed if appropriate, the GitHub security advisory is no longer needed and can be closed. + ## Security Bug Bounties We offer bounties for critical security issues. Please see below for more details. @@ -26,11 +82,11 @@ $2,000,000 USD in locked SOL tokens (locked for 12 months) Consensus/Safety Violations: $1,000,000 USD in locked SOL tokens (locked for 12 months) * Consensus safety violation -* Tricking a validator to accept an optimistic confirmation or rooted slot without a double vote, etc.. +* Tricking a validator to accept an optimistic confirmation or rooted slot without a double vote, etc. -Other Attacks: - $400,000 USD in locked SOL tokens (locked for 12 months) -* Protocol liveness attacks, +Liveness / Loss of Availability: +$400,000 USD in locked SOL tokens (locked for 12 months) +* Whereby consensus halts and requires human intervention * Eclipse attacks, * Remote attacks that partition the network, @@ -38,6 +94,10 @@ DoS Attacks: $100,000 USD in locked SOL tokens (locked for 12 months) * Remote resource exaustion via Non-RPC protocols +Supply Chain Attacks: +$100,000 USD in locked SOL tokens (locked for 12 months) +* Non-social attacks against source code change management, automated testing, release build, release publication and release hosting infrastructure of the monorepo. + RPC DoS/Crashes: $5,000 USD in locked SOL tokens (locked for 12 months) * RPC attacks @@ -54,116 +114,10 @@ Eligibility: * The participant submitting the bug report shall follow the process outlined within this document * Valid exploits can be eligible even if they are not successfully executed on the cluster * Multiple submissions for the same class of exploit are still eligible for compensation, though may be compensated at a lower rate, however these will be assessed on a case-by-case basis -* Participants must complete KYC and sign the participation agreement here when the registrations are open https://solana.com/validator-registration. Security exploits will still be assessed and open for submission at all times. This needs only be done prior to distribution of tokens. +* Participants must complete KYC and sign the participation agreement here when the registrations are open https://solana.foundation/kyc. Security exploits will still be assessed and open for submission at all times. This needs only be done prior to distribution of tokens. Payment of Bug Bounties: -* Payments for eligible bug reports are distributed monthly. -* Bounties for all bug reports submitted in a given month are paid out in the middle of the -following month. -* The SOL/USD conversion rate used for payments is the market price at the end of - the last day of the month for the month in which the bug was submitted. -* The reference for this price is the Closing Price given by Coingecko.com on - that date given here: - https://www.coingecko.com/en/coins/solana/historical_data/usd#panel -* For example, for all bugs submitted in March 2021, the SOL/USD price for bug - payouts is the Close price on 2021-03-31 of $19.49. This applies to all bugs - submitted in March 2021, to be paid in mid-April 2021. -* Bug bounties are paid out in -[stake accounts](https://solana.com/staking) with a -[lockup](https://docs.solana.com/staking/stake-accounts#lockups) -expiring 12 months from the last day of the month in which the bug was submitted. - - -## Incident Response Process - -In case an incident is discovered or reported, the following process will be -followed to contain, respond and remediate: - -### 1. Establish a new draft security advisory -In response to an email to security@solana.com, a member of the `solana-labs/admins` group will -1. Create a new draft security advisory for the incident at https://github.com/solana-labs/solana/security/advisories -1. Add the reporter's github user and the `solana-labs/security-incident-response` group to the draft security advisory -1. Create a private fork of the repository (grey button towards the bottom of the page) -1. Respond to the reporter by email, sharing a link to the draft security advisory - -### 2. Triage -Within the draft security advisory, discuss and determine the severity of the -issue. If necessary, members of the `solana-labs/security-incident-response` -group may add other github users to the advisory to assist. - -If it is determined that this not a critical network issue then the advisory -should be closed and if more follow-up is required a normal Solana public github -issue should be created. - -### 3. Prepare Fixes -For the affected branches, typically all three (edge, beta and stable), prepare -a fix for the issue and push them to the corresponding branch in the private -repository associated with the draft security advisory. - -There is no CI available in the private repository so you must build from source -and manually verify fixes. - -Code review from the reporter is ideal, as well as from multiple members of the -core development team. - -### 4. Notify Security Group Validators -Once an ETA is available for the fix, a member of the -`solana-labs/security-incident-response` group should notify the validators so -they can prepare for an update using the "Solana Red Alert" notification system. - -The teams are all over the world and it's critical to provide actionable -information at the right time. Don't be the person that wakes everybody up at -2am when a fix won't be available for hours. - -### 5. Ship the patch -Once the fix is accepted, a member of the -`solana-labs/security-incident-response` group should prepare a single patch -file for each affected branch. The commit title for the patch should only -contain the advisory id, and not disclose any further details about the -incident. - -Copy the patches to https://release.solana.com/ under a subdirectory named after -the advisory id (example: -https://release.solana.com/GHSA-hx59-f5g4-jghh/v1.4.patch). Contact a member of -the `solana-labs/admins` group if you require access to release.solana.com - -Using the "Solana Red Alert" channel: -1. Notify validators that there's an issue and a patch will be provided in X minutes -2. If X minutes expires and there's no patch, notify of the delay and provide a - new ETA -3. Provide links to patches of https://release.solana.com/ for each affected branch - -Validators can be expected to build the patch from source against the latest -release for the affected branch. - -Since the software version will not change after the patch is applied, request -that each validator notify in the existing channel once they've updated. Manually -monitor the roll out until a sufficient amount of stake has updated - typically -at least 33.3% or 66.6% depending on the issue. - -### 6. Public Disclosure and Release -Once the fix has been deployed to the security group validators, the patches from the security -advisory may be merged into the main source repository. A new official release -for each affected branch should be shipped and all validators requested to -upgrade as quickly as possible. - -### 7. Security Advisory Bounty Accounting and Cleanup - -If this issue is eligible for a bounty, prefix the title of the security -advisory with one of the following, depending on the severity: -* `[Bounty Category: Critical: Loss of Funds]` -* `[Bounty Category: Critical: Loss of Availability]` -* `[Bounty Category: Critical: DoS]` -* `[Bounty Category: Critical: Other]` -* `[Bounty Category: Non-critical]` -* `[Bounty Category: RPC]` - -Confirm with the reporter that they agree with the severity assessment, and -discuss as required to reach a conclusion. - -We currently do not use the Github workflow to publish security advisories. -Once the issue and fix have been disclosed, and a bounty category is assessed if -appropriate, the GitHub security advisory is no longer needed and can be closed. - -Bounties are currently awarded once a quarter (TODO: link to this process, or -inline the workflow) +* Bounties are currently awarded on a rolling/weekly basis and paid out within 15 days upon receipt of an invoice. +* The SOL/USD conversion rate used for payments is the market price of SOL (denominated in USD) at the end of the day the invoice is submitted by the researcher. +* The reference for this price is the Closing Price given by Coingecko.com on that date given here: https://www.coingecko.com/en/coins/solana/historical_data/usd#panel +* Bug bounties that are paid out in SOL are paid to stake accounts with a lockup expiring 12 months from the date of delivery of SOL.