certusone
/
wormhole
mirror of https://github.com/certusone/wormhole.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: typos in SECURITY.md (#3567) 

fix typos
This commit is contained in:
hattizai 2023-12-12 20:35:05 +08:00 committed by GitHub
parent da2bdd67be
commit 07161d191d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
SECURITY.md
View File

@ -122,7 +122,7 @@ Additionally, ensure:
The Wormhole project maintains a social media monitoring program to stay abreast of important ecosystem developments. The Wormhole project maintains a social media monitoring program to stay abreast of important ecosystem developments.
These developments include monitoring services like Twitter for key phrases and patterns such that the Wormhole project is informed of a compromise or vulnerability in a dependancy that could negatively affect Wormhole, its users, or the chains that Wormhole is connected to. These developments include monitoring services like Twitter for key phrases and patterns such that the Wormhole project is informed of a compromise or vulnerability in a dependency that could negatively affect Wormhole, its users, or the chains that Wormhole is connected to.
In the case of a large ecosystem development that requires response, the Wormhole project will engage its security incident response program. In the case of a large ecosystem development that requires response, the Wormhole project will engage its security incident response program.
@ -130,7 +130,7 @@ In the case of a large ecosystem development that requires response, the Wormhol
The Wormhole project maintains an incident response program to respond to vulnerabilities or active threats to Wormhole, its users, or the ecosystems it's connected to. Wormhole can be made aware about a security event from a variety of different sources (eg. bug bounty program, audit finding, security monitoring, social media, etc.) The Wormhole project maintains an incident response program to respond to vulnerabilities or active threats to Wormhole, its users, or the ecosystems it's connected to. Wormhole can be made aware about a security event from a variety of different sources (eg. bug bounty program, audit finding, security monitoring, social media, etc.)
When a Wormhole project contributor becomes aware of a security event, that contributor immediately holds the role of [incident commander](https://en.wikipedia.org/wiki/Incident_commander) for the issue until they hand off to a more appropriate incident commander. A contributor does not need to be a "security person" or have any special priviledges to hold the role of incident commander, they simply need to be responsible, communicate effectively, and maintain the following obligations to manage the incident to completion. When a Wormhole project contributor becomes aware of a security event, that contributor immediately holds the role of [incident commander](https://en.wikipedia.org/wiki/Incident_commander) for the issue until they hand off to a more appropriate incident commander. A contributor does not need to be a "security person" or have any special privileges to hold the role of incident commander, they simply need to be responsible, communicate effectively, and maintain the following obligations to manage the incident to completion.
The role of the incident commander for Wormhole includes the following minimum obligations: The role of the incident commander for Wormhole includes the following minimum obligations:
@ -169,7 +169,7 @@ The benefits of such an approach include the following:
The caveats of such an approach include the following: The caveats of such an approach include the following:
- Speed to shutdown is limited by speed to develop the temporary bug fix (only for the unknown cases, known cases won't require development) - Speed to shutdown is limited by speed to develop the temporary bug fix (only for the unknown cases, known cases won't require development)
- Speed to shutdown is limited by speed at which goverance can be passed to accept the temporary bug fix (slower for unknown cases and faster for known cases) - Speed to shutdown is limited by speed at which governance can be passed to accept the temporary bug fix (slower for unknown cases and faster for known cases)
- Restoring after a shutdown will require a secondary governance action to either repoint the proxy contract to a non-shutdown implementation (known cases) or to revert the temporary patch and apply the long term patch (unknown cases) - Restoring after a shutdown will require a secondary governance action to either repoint the proxy contract to a non-shutdown implementation (known cases) or to revert the temporary patch and apply the long term patch (unknown cases)
## Security Monitoring ## Security Monitoring