|
1 | | -# Security Policy |
| 1 | +## This repo will be archived soon |
| 2 | +Active development in this repo is ending 2024-03-02. Anza is continuing development |
| 3 | +in the [agave fork](https://github.com/anza-xyz/agave). Please refer to |
| 4 | +[the security policy in that repo](https://github.com/anza-xyz/agave/security) |
2 | 5 |
|
3 | | -1. [Reporting security problems](#reporting) |
4 | | -4. [Security Bug Bounties](#bounty) |
5 | | -2. [Incident Response Process](#process) |
6 | | - |
7 | | -<a name="reporting"></a> |
8 | | -## Reporting security problems in the Solana Labs Validator Client |
9 | | - |
10 | | -**DO NOT CREATE A GITHUB ISSUE** to report a security problem. |
11 | | - |
12 | | -Instead please use this [Report a Vulnerability](https://github.com/solana-labs/solana/security/advisories/new) link. |
13 | | -Provide a helpful title, detailed description of the vulnerability and an exploit |
14 | | -proof-of-concept. Speculative submissions without proof-of-concept will be closed |
15 | | -with no further consideration. |
16 | | - |
17 | | -Please refer to the |
18 | | -[Solana Program Library (SPL) security policy](https://github.com/solana-labs/solana-program-library/security/policy) |
19 | | -for vulnerabilities regarding SPL programs such as SPL Token. |
20 | | - |
21 | | -If you haven't done so already, please **enable two-factor auth** in your GitHub account. |
22 | | - |
23 | | -Expect a response as fast as possible in the advisory, typically within 72 hours. |
24 | | - |
25 | | --- |
26 | | - |
27 | | -If you do not receive a response in the advisory, send an email to |
28 | | -[email protected] with the full URL of the advisory you have created. DO NOT |
29 | | -include attachments or provide detail sufficient for exploitation regarding the |
30 | | -security issue in this email. **Only provide such details in the advisory**. |
31 | | - |
32 | | -If you do not receive a response from [email protected] please followup with |
33 | | -the team directly. You can do this in the `#core-technology` channel of the |
34 | | -[Solana Tech discord server](https://solana.com/discord), by pinging the `Solana Labs` |
35 | | -role in the channel and referencing the fact that you submitted a security problem. |
36 | | - |
37 | | -<a name="process"></a> |
38 | | -## Incident Response Process |
39 | | - |
40 | | -In case an incident is discovered or reported, the following process will be |
41 | | -followed to contain, respond and remediate: |
42 | | - |
43 | | -### 1. Accept the new report |
44 | | -In response a newly reported security problem, a member of the |
45 | | -`solana-labs/admins` group will accept the report to turn it into a draft |
46 | | -advisory. The `solana-labs/security-incident-response` group should be added to |
47 | | -the draft security advisory, and create a private fork of the repository (grey |
48 | | -button towards the bottom of the page) if necessary. |
49 | | - |
50 | | -If the advisory is the result of an audit finding, follow the same process as above but add the auditor's github user(s) and begin the title with "[Audit]". |
51 | | - |
52 | | -If the report is out of scope, a member of the `solana-labs/admins` group will |
53 | | -comment as such and then close the report. |
54 | | - |
55 | | -### 2. Triage |
56 | | -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. |
57 | | -If it is determined that this is 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. |
58 | | - |
59 | | -### 3. Prepare Fixes |
60 | | -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. |
61 | | -There is no CI available in the private repository so you must build from source and manually verify fixes. |
62 | | -Code review from the reporter is ideal, as well as from multiple members of the core development team. |
63 | | - |
64 | | -### 4. Notify Security Group Validators |
65 | | -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. |
66 | | -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. |
67 | | - |
68 | | -### 5. Ship the patch |
69 | | -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. |
70 | | -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 |
71 | | -Using the "Solana Red Alert" channel: |
72 | | - a) Notify validators that there's an issue and a patch will be provided in X minutes |
73 | | - b) If X minutes expires and there's no patch, notify of the delay and provide a new ETA |
74 | | - c) Provide links to patches of https://release.solana.com/ for each affected branch |
75 | | -Validators can be expected to build the patch from source against the latest release for the affected branch. |
76 | | -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. |
77 | | - |
78 | | -### 6. Public Disclosure and Release |
79 | | -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. |
80 | | - |
81 | | -### 7. Security Advisory Bounty Accounting and Cleanup |
82 | | -If this issue is [eligible](#eligibility) for a bounty, prefix the title of the |
83 | | -security advisory with one of the following, depending on the severity: |
84 | | -- [Bounty Category: Critical: Loss of Funds] |
85 | | -- [Bounty Category: Critical: Consensus / Safety Violations] |
86 | | -- [Bounty Category: Critical: Liveness / Loss of Availability] |
87 | | -- [Bounty Category: Critical: DoS Attacks] |
88 | | -- [Bounty Category: Supply Chain Attacks] |
89 | | -- [Bounty Category: RPC] |
90 | | - |
91 | | -Confirm with the reporter that they agree with the severity assessment, and discuss as required to reach a conclusion. |
92 | | - |
93 | | -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. |
94 | | - |
95 | | -<a name="bounty"></a> |
96 | | -## Security Bug Bounties |
97 | | -At its sole discretion, the Solana Foundation may offer a bounty for |
98 | | -[valid reports](#reporting) of critical Solana vulnerabilities. Please see below |
99 | | -for more details. The submitter is not required to provide a |
100 | | -mitigation to qualify. |
101 | | - |
102 | | -#### IMPORTANT | PLEASE NOTE |
103 | | -_Beginning February 1st 2024, the Security bounty program payouts will be updated in the following ways:_ |
104 | | -- _Bug Bounty rewards will be denominated in SOL tokens, rather than USD value._ |
105 | | -_This change is to better reflect for changing value of the Solana network._ |
106 | | -- _Categories will now have a discretionary range to distinguish the varying severity_ |
107 | | -_and impact of bugs reported within each broader category._ |
108 | | - |
109 | | -_Note: Payments will continue to be paid out in 12-month locked SOL._ |
110 | | - |
111 | | - |
112 | | -#### Loss of Funds: |
113 | | -_**As of 2/1/24:** Max: 25,000 SOL tokens. Min: 6,250 SOL tokens_ |
114 | | - |
115 | | -* Theft of funds without users signature from any account |
116 | | -* Theft of funds without users interaction in system, stake, vote programs |
117 | | -* Theft of funds that requires users signature - creating a vote program that drains the delegated stakes. |
118 | | - |
119 | | -#### Consensus/Safety Violations: |
120 | | -_**As of 2/1/24:** Max: 12,500 SOL tokens. Min: 3,125 SOL tokens_ |
121 | | - |
122 | | -* Consensus safety violation |
123 | | -* Tricking a validator to accept an optimistic confirmation or rooted slot without a double vote, etc. |
124 | | - |
125 | | -#### Liveness / Loss of Availability: |
126 | | -_**As of 2/1/24:** Max: 5,000 SOL tokens. Min: 1,250 SOL tokens_ |
127 | | - |
128 | | -* Whereby consensus halts and requires human intervention |
129 | | -* Eclipse attacks, |
130 | | -* Remote attacks that partition the network, |
131 | | - |
132 | | -#### DoS Attacks: |
133 | | -_**As of 2/1/24:** Max: 1,250 SOL tokens. Min: 315 SOL tokens_ |
134 | | - |
135 | | -* Remote resource exhaustion via Non-RPC protocols |
136 | | - |
137 | | -#### Supply Chain Attacks: |
138 | | -_**As of 2/1/24:** Max: 1,250 SOL tokens. Min: 315 SOL tokens_ |
139 | | - |
140 | | -* Non-social attacks against source code change management, automated testing, release build, release publication and release hosting infrastructure of the monorepo. |
141 | | - |
142 | | -#### RPC DoS/Crashes: |
143 | | -_**As of 2/1/24:** Max: 65 SOL tokens. Min: 20 SOL tokens_ |
144 | | - |
145 | | -* RPC attacks |
146 | | - |
147 | | -### Out of Scope: |
148 | | -The following components are out of scope for the bounty program |
149 | | -* Metrics: `/metrics` in the monorepo as well as https://metrics.solana.com |
150 | | -* Any encrypted credentials, auth tokens, etc. checked into the repo |
151 | | -* Bugs in dependencies. Please take them upstream! |
152 | | -* Attacks that require social engineering |
153 | | -* Any undeveloped automated tooling (scanners, etc) results. (OK with developed PoC) |
154 | | -* Any asset whose source code does not exist in this repository (including, but not limited |
155 | | -to, any and all web properties not explicitly listed on this page) |
156 | | -* Programs in the Solana Program Library, such as SPL Token. Please refer to the |
157 | | -[SPL security policy](https://github.com/solana-labs/solana-program-library/security/policy). |
158 | | - |
159 | | -### Eligibility: |
160 | | -* Submissions _MUST_ include an exploit proof-of-concept to be considered eligible |
161 | | -* The participant submitting the bug report shall follow the process outlined within this document |
162 | | -* Valid exploits can be eligible even if they are not successfully executed on a public cluster |
163 | | -* 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 |
164 | | -* 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. |
165 | | - |
166 | | -### Duplicate Reports |
167 | | -Compensation for duplicative reports will be split among reporters with first to report taking priority using the following equation |
168 | | -``` |
169 | | -R: total reports |
170 | | -ri: report priority |
171 | | -bi: bounty share |
172 | | -
|
173 | | -bi = 2 ^ (R - ri) / ((2^R) - 1) |
174 | | -``` |
175 | | -#### Bounty Split Examples |
176 | | -| total reports | priority | share | | total reports | priority | share | | total reports | priority | share | |
177 | | -| ------------- | -------- | -----: | - | ------------- | -------- | -----: | - | ------------- | -------- | -----: | |
178 | | -| 1 | 1 | 100% | | 2 | 1 | 66.67% | | 5 | 1 | 51.61% | |
179 | | -| | | | | 2 | 2 | 33.33% | | 5 | 2 | 25.81% | |
180 | | -| 4 | 1 | 53.33% | | | | | | 5 | 3 | 12.90% | |
181 | | -| 4 | 2 | 26.67% | | 3 | 1 | 57.14% | | 5 | 4 | 6.45% | |
182 | | -| 4 | 3 | 13.33% | | 3 | 2 | 28.57% | | 5 | 5 | 3.23% | |
183 | | -| 4 | 4 | 6.67% | | 3 | 3 | 14.29% | | | | | |
184 | | - |
185 | | -### Payment of Bug Bounties: |
186 | | -* Bounties are currently awarded on a rolling/weekly basis and paid out within 30 days upon receipt of an invoice. |
187 | | -* 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. |
0 commit comments