You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Reporting security problems in the <project_name>
8
+
## Reporting security problems for Anchor Lang
8
9
9
10
**DO NOT CREATE A GITHUB ISSUE** to report a security problem.
10
11
@@ -13,22 +14,30 @@ Provide a helpful title, detailed description of the vulnerability and an exploi
13
14
proof-of-concept. Speculative submissions without proof-of-concept will be closed
14
15
with no further consideration.
15
16
16
-
17
17
If you haven't done so already, please **enable two-factor auth** in your GitHub account.
18
18
19
19
Expect a response as fast as possible in the advisory, typically within 72 hours.
20
20
21
-
--
21
+
As a general rule of thumb, we will look to these questions to evaluate eligibility:
22
+
1. Does the bug affect multiple contracts? Vulnerabilities don’t have to affect multiple contracts, but a more widespread bug is generally indicative of a fundamental issue with the library, as opposed to a mistake by the developer
23
+
2. Was the bug public knowledge previously? This may mean that it’s a vulnerability class for users of Anchor, but not an issue within Anchor itself
24
+
3. How complicated is the bug to trigger? The simpler and more plausible the proof of concept, the more likely it is to be a bug in the library
25
+
26
+
Regardless, if you think you have an issue, we’d like to hear about it.
27
+
28
+
For bugs that affect production code, we will pay up to $X according to the following guidelines. This is exclusive to any bounties claimed from the protocol. In other words, reports can’t double-dip.
29
+
- Critical: X. Bypass of fundamental Anchor checks, such as account ownership, discriminator, memory safety, etc.
30
+
- Medium: X. Denial of service
31
+
- Low: X: All remaining issues
32
+
33
+
34
+
---
22
35
23
36
If you do not receive a response in the advisory, send an email to
24
37
disclosures@solana.org with the full URL of the advisory you have created. DO NOT
25
38
include attachments or provide detail sufficient for exploitation regarding the
26
39
security issue in this email. **Only provide such details in the advisory**.
27
40
28
-
29
-
If you do not receive a response from disclosures@solana.org please followup with
30
-
the team on another platform like @solana_devs on X/twitter
31
-
32
41
<aname="process"></a>
33
42
## Incident Response Process
34
43
@@ -38,7 +47,7 @@ followed to contain, respond and remediate:
38
47
### 1. Accept the new report
39
48
In response a newly reported security problem, a member of the
40
49
`solana-foundation/admins` group will accept the report to turn it into a draft
41
-
advisory. The `solana-foundation/security-incident-response` group should be added to
50
+
advisory. The `solana-foundation/anchor-security-incident-response` group should be added to
42
51
the draft security advisory, and create a private fork of the repository (grey
43
52
button towards the bottom of the page) if necessary.
44
53
@@ -48,20 +57,102 @@ If the report is out of scope, a member of the `solana-foundation/admins` group
48
57
comment as such and then close the report.
49
58
50
59
### 2. Triage
51
-
Within the draft security advisory, discuss and determine the severity of the issue. If necessary, members of the solana-foundation/security-incident-response group may add other github users to the advisory to assist.
60
+
Within the draft security advisory, discuss and determine the severity of the issue. If necessary, members of the `solana-foundation/anchor-security-incident-response` group may add other github users to the advisory to assist.
52
61
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.
53
62
54
63
### 3. Prepare Fixes
55
64
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.
56
65
There is no CI available in the private repository so you must build from source and manually verify fixes.
57
66
Code review from the reporter is ideal, as well as from multiple members of the core development team.
58
67
59
-
### 4. Notify Security Group Validators
60
-
Once an ETA is available for the fix, a member of the solana-foundation/security-incident-response group should notify the validators so they can prepare for an update using the "Solana Red Alert" notification system.
68
+
### 4. Notify Security Group
69
+
Once an ETA is available for the fix, a member of the `solana-foundation/anchor-security-incident-response` group should notify major affected parties.
61
70
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.
62
71
63
72
### 5. Ship the patch
64
-
Once the fix is accepted it may be distributed directly to validators as a patch, depending on the vulnerability.
73
+
Once the fix is accepted it may be distributed directly to develoers as a patch, depending on the vulnerability.
74
+
75
+
### 6. Public Disclosure and Release
76
+
Once the fix has been deployed to major affected parties, 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 parties requested to upgrade as quickly as possible.
77
+
78
+
### 7. Security Advisory Bounty Accounting and Cleanup
79
+
If this issue is [eligible](#eligibility) for a bounty, prefix the title of the
80
+
security advisory with one of the following, depending on the severity:
81
+
82
+
-[Bounty Category: Critical](#critical): X. Bypass of fundamental Anchor checks, such as account ownership, discriminator, memory safety, etc.
83
+
-[Bounty Category: Medium](#medium): X. Denial of service
84
+
-[Bounty Category: Low](#low): X: All remaining issues
85
+
86
+
Confirm with the reporter that they agree with the severity assessment, and discuss as required to reach a conclusion.
65
87
66
88
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.
67
89
90
+
<aname="bounty"></a>
91
+
## Security Bug Bounties
92
+
At its sole discretion, the Solana Foundation may offer a bounty for
93
+
[valid reports](#reporting) of critical Solana vulnerabilities. Please see below
94
+
for more details. The submitter is not required to provide a
95
+
mitigation to qualify.
96
+
97
+
#### IMPORTANT | PLEASE NOTE
98
+
_Note: Payments will continue to be paid out in 12-month locked SOL._
99
+
100
+
<aname="critical"></a>
101
+
#### Critical:
102
+
_Max: X SOL tokens. Min: Y SOL tokens_
103
+
104
+
* Bypassing fundamental Anchor checks, such as account ownership, discriminator, memory safety, etc.
105
+
106
+
<aname="medium"></a>
107
+
#### Medium:
108
+
_Max: X SOL tokens. Min: Y SOL tokens_
109
+
110
+
* Denial of service attacks
111
+
112
+
<aname="low"></a>
113
+
#### Low:
114
+
_Max: X SOL tokens. Min: Y SOL tokens_
115
+
116
+
* All remaining issues
117
+
118
+
* Attacks to devex infrastructure
119
+
120
+
### Out of Scope:
121
+
The following components are out of scope for the bounty program
122
+
* Any encrypted credentials, auth tokens, etc. checked into the repo
123
+
* Bugs in dependencies. Please take them upstream!
124
+
* Attacks that require social engineering
125
+
* Any undeveloped automated tooling (scanners, etc) results. (OK with developed PoC)
126
+
* Any asset whose source code does not exist in this repository (including, but not limited
127
+
to, any and all web properties not explicitly listed on this page)
128
+
129
+
### Eligibility:
130
+
* Anyone under a grant or the financial arrangement with Solana Foundation to develop or audit related tools is not eligibile
131
+
* Submissions _MUST_ include an exploit proof-of-concept to be considered eligible
132
+
* The participant submitting the bug report shall follow the process outlined within this document
133
+
* Valid exploits can be eligible even if they are not successfully executed on a public cluster
134
+
* 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
135
+
* Participants must complete KYC and sign the participation agreement here when the registrations are open https://solana.org/kyc. Security exploits will still be assessed and open for submission at all times. This needs only be done prior to distribution of tokens.
136
+
137
+
### Duplicate Reports
138
+
Compensation for duplicative reports will be split among reporters with first to report taking priority using the following equation
139
+
```
140
+
R: total reports
141
+
ri: report priority
142
+
bi: bounty share
143
+
144
+
bi = 2 ^ (R - ri) / ((2^R) - 1)
145
+
```
146
+
#### Bounty Split Examples
147
+
| total reports | priority | share || total reports | priority | share || total reports | priority | share |
0 commit comments