|
1 | | -# Security Policy |
| 1 | +# Jito-Solana Security |
2 | 2 |
|
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 Agave Validator |
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/anza-xyz/agave/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 `Anza` |
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 | | -`anza-xyz/admins` group will accept the report to turn it into a draft |
46 | | -advisory. The `anza-xyz/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 `anza-xyz/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 anza-xyz/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 anza-xyz/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 it may be distributed directly to validators as a patch, depending on the vulnerability. |
70 | | - |
71 | | -### 6. Public Disclosure and Release |
72 | | -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. |
73 | | - |
74 | | -### 7. Security Advisory Bounty Accounting and Cleanup |
75 | | -If this issue is [eligible](#eligibility) for a bounty, prefix the title of the |
76 | | -security advisory with one of the following, depending on the severity: |
77 | | -- [Bounty Category: Critical: Loss of Funds] |
78 | | -- [Bounty Category: Critical: Consensus / Safety Violations] |
79 | | -- [Bounty Category: Critical: Liveness / Loss of Availability] |
80 | | -- [Bounty Category: Critical: DoS Attacks] |
81 | | -- [Bounty Category: Supply Chain Attacks] |
82 | | -- [Bounty Category: RPC] |
83 | | - |
84 | | -Confirm with the reporter that they agree with the severity assessment, and discuss as required to reach a conclusion. |
85 | | - |
86 | | -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. |
87 | | - |
88 | | -<a name="bounty"></a> |
89 | | -## Security Bug Bounties |
90 | | -At its sole discretion, the Solana Foundation may offer a bounty for |
91 | | -[valid reports](#reporting) of critical Solana vulnerabilities. Please see below |
92 | | -for more details. The submitter is not required to provide a |
93 | | -mitigation to qualify. |
94 | | - |
95 | | -#### IMPORTANT | PLEASE NOTE |
96 | | -_Beginning February 1st 2024, the Security bounty program payouts will be updated in the following ways:_ |
97 | | -- _Bug Bounty rewards will be denominated in SOL tokens, rather than USD value._ |
98 | | -_This change is to better reflect for changing value of the Solana network._ |
99 | | -- _Categories will now have a discretionary range to distinguish the varying severity_ |
100 | | -_and impact of bugs reported within each broader category._ |
101 | | - |
102 | | -_Note: Payments will continue to be paid out in 12-month locked SOL._ |
103 | | - |
104 | | - |
105 | | -#### Loss of Funds: |
106 | | -_Max: 25,000 SOL tokens. Min: 6,250 SOL tokens_ |
107 | | - |
108 | | -* Theft of funds without users signature from any account |
109 | | -* Theft of funds without users interaction in system, stake, vote programs |
110 | | -* Theft of funds that requires users signature - creating a vote program that drains the delegated stakes. |
111 | | - |
112 | | -#### Consensus/Safety Violations: |
113 | | -_Max: 12,500 SOL tokens. Min: 3,125 SOL tokens_ |
114 | | - |
115 | | -* Consensus safety violation |
116 | | -* Tricking a validator to accept an optimistic confirmation or rooted slot without a double vote, etc. |
117 | | - |
118 | | -#### Liveness / Loss of Availability: |
119 | | -_Max: 5,000 SOL tokens. Min: 1,250 SOL tokens_ |
120 | | - |
121 | | -* Whereby consensus halts and requires human intervention |
122 | | -* Eclipse attacks, |
123 | | -* Remote attacks that partition the network, |
124 | | - |
125 | | -#### DoS Attacks: |
126 | | -_Max: 1,250 SOL tokens. Min: 315 SOL tokens_ |
127 | | - |
128 | | -* Remote resource exhaustion via Non-RPC protocols |
129 | | - |
130 | | -#### Supply Chain Attacks: |
131 | | -_Max: 1,250 SOL tokens. Min: 315 SOL tokens_ |
132 | | - |
133 | | -* Non-social attacks against source code change management, automated testing, release build, release publication and release hosting infrastructure of the monorepo. |
134 | | - |
135 | | -#### RPC DoS/Crashes: |
136 | | -_Max: 65 SOL tokens. Min: 20 SOL tokens_ |
137 | | - |
138 | | -* RPC attacks |
139 | | - |
140 | | -### Out of Scope: |
141 | | -The following components are out of scope for the bounty program |
142 | | -* Metrics: `/metrics` in the monorepo as well as https://metrics.solana.com |
143 | | -* Any encrypted credentials, auth tokens, etc. checked into the repo |
144 | | -* Bugs in dependencies. Please take them upstream! |
145 | | -* Attacks that require social engineering |
146 | | -* Any undeveloped automated tooling (scanners, etc) results. (OK with developed PoC) |
147 | | -* Any asset whose source code does not exist in this repository (including, but not limited |
148 | | -to, any and all web properties not explicitly listed on this page) |
149 | | -* Programs in the Solana Program Library, such as SPL Token. Please refer to the |
150 | | -[SPL security policy](https://github.com/solana-labs/solana-program-library/security/policy). |
151 | | - |
152 | | -### Eligibility: |
153 | | -* Submissions _MUST_ include an exploit proof-of-concept to be considered eligible |
154 | | -* The participant submitting the bug report shall follow the process outlined within this document |
155 | | -* Valid exploits can be eligible even if they are not successfully executed on a public cluster |
156 | | -* 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 |
157 | | -* 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. |
158 | | - |
159 | | -### Duplicate Reports |
160 | | -Compensation for duplicative reports will be split among reporters with first to report taking priority using the following equation |
161 | | -``` |
162 | | -R: total reports |
163 | | -ri: report priority |
164 | | -bi: bounty share |
165 | | -
|
166 | | -bi = 2 ^ (R - ri) / ((2^R) - 1) |
167 | | -``` |
168 | | -#### Bounty Split Examples |
169 | | -| total reports | priority | share | | total reports | priority | share | | total reports | priority | share | |
170 | | -| ------------- | -------- | -----: | - | ------------- | -------- | -----: | - | ------------- | -------- | -----: | |
171 | | -| 1 | 1 | 100% | | 2 | 1 | 66.67% | | 5 | 1 | 51.61% | |
172 | | -| | | | | 2 | 2 | 33.33% | | 5 | 2 | 25.81% | |
173 | | -| 4 | 1 | 53.33% | | | | | | 5 | 3 | 12.90% | |
174 | | -| 4 | 2 | 26.67% | | 3 | 1 | 57.14% | | 5 | 4 | 6.45% | |
175 | | -| 4 | 3 | 13.33% | | 3 | 2 | 28.57% | | 5 | 5 | 3.23% | |
176 | | -| 4 | 4 | 6.67% | | 3 | 3 | 14.29% | | | | | |
177 | | - |
178 | | -### Payment of Bug Bounties: |
179 | | -* Bounties are currently awarded on a rolling/weekly basis and paid out within 30 days upon receipt of an invoice. |
180 | | -* 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. |
181 | | -* **Note: payment notices need to be sent to [email protected] within 90 days of receiving payment advice instructions. ** Failure to do so may result in forfeiture of the bug bounty reward. |
| 3 | +The bug bounty program for Jito-Solana is managed by Immunefi. More details can be found [here](https://immunefi.com/bug-bounty/jito/information/). |
0 commit comments