51 lines
2.2 KiB
Markdown
51 lines
2.2 KiB
Markdown
|
# Security Policy
|
|||
|
|
|
|||
|
|
## How to disclose a vulnerability to us
|
|||
|
|
|
|||
|
|
### The wrong way to disclose
|
|||
|
|
|
|||
|
|
The following actions will disqualify you from eligibility for a reward:
|
|||
|
|
|
|||
|
|
1. Filing a public ticket mentioning the vulnerability
|
|||
|
|
2. Testing the vulnerability on the mainnet or testnet
|
|||
|
|
|
|||
|
|
#### The right way to disclose
|
|||
|
|
|
|||
|
|
### Smart contract and infrastructure vulnerabilities
|
|||
|
|
|
|||
|
|
We have a bounty program with a maximum payout of $2,000,042. Please see [our bounty program](https://immunefi.com/bounty/optimism/) at Immunefi for more details.
|
|||
|
|
|
|||
|
|
### Other vulnerabilities
|
|||
|
|
|
|||
|
|
For vulnerabilities in any of our websites, email servers or other non-critical infrastructure, please email OP Labs at [security@oplabs.co](mailto:security@oplabs.co). We and Labs appreciate detailed instructions for confirming the vulnerability.
|
|||
|
|
|
|||
|
|
|
|||
|
|
## How we disclose vulnerabilities
|
|||
|
|
|
|||
|
|
In the event that we learn of a critical security vulnerability, we reserve the right to
|
|||
|
|
silently fix it without immediately publicly disclosing the existence of nature of the vulnerability.
|
|||
|
|
|
|||
|
|
In such a scenario we will:
|
|||
|
|
|
|||
|
|
1. silently fix a vulnerability and include the fix in release X,
|
|||
|
|
2. after 4-8 weeks, we will disclose that X contained a security-fix,
|
|||
|
|
3. after an additional 4-8 weeks, we will publish details of the vulnerability along with credit to the reporter (with express permission from the reporter).
|
|||
|
|
|
|||
|
|
Alongside this policy, we also reserve the right to do either of the following:
|
|||
|
|
- bypass this policy and publish details on a shorter timeline
|
|||
|
|
- to directly notify a subset of downstream users prior to making a public announcement
|
|||
|
|
|
|||
|
|
This policy is based the Geth team’s [silent patch policy](https://geth.ethereum.org/docs/vulnerabilities/vulnerabilities#why-silent-patches).
|
|||
|
|
|
|||
|
|
### Defensive measures during an incident
|
|||
|
|
|
|||
|
|
Our system does not currently have fault proofs, meaning we are able to pause the system in an
|
|||
|
|
emergency.
|
|||
|
|
|
|||
|
|
We've established some guiding criteria for disabling the system during an incident response
|
|||
|
|
situation:
|
|||
|
|
|
|||
|
|
- If an attack is ongoing: we should disable or pause in order to prevent further damage.
|
|||
|
|
- If we suspect that a vulnerability might be widely known: we should disable or pause proactively.
|
|||
|
|
- Otherwise: we should not disable or pause the system.
|