Architecture, design and threat modeling in the context of creating secure smart contracts. Consider all possible threats before the implementation of the smart contract.
Ensure that a verified contract satisfies the following high-level requirements:
- All related smart contracts are identified and used properly,
- Specific smart contracts security assumptions are considered during the design phase.
Category “G1” lists requirements related to the architecture, design and threat modeling of the smart contracts.
| # | Description |
|---|---|
| G1.1 | Verify that every introduced design change is preceded by an earlier threat modeling. |
| G1.2 | Verify that the documentation clearly and precisely defines all trust boundaries in the contract (trusted relations with other contracts and significant data flows). |
| G1.3 | Verify that the SCSVS, security requirements or policy is available to all developers and testers. |
| G1.4 | Verify that the events for the (state changing/crucial for business) operations are defined. |
| G1.5 | Verify that there exists a mechanism that can temporarily stop the sensitive functionalities of the contract in case of a new attack. This mechanism should not block access to the assets (e.g. tokens) for their owners. |
| G1.6 | Verify that the amount of unused cryptocurrencies kept on the contract is controlled and at the minimum acceptable level so as not to become a potential target of an attack. |
| G1.7 | Verify that if fallback function can be called by anyone, it is included in the threat modeling. |
| G1.8 | Verify that the business logic in contracts is consistent. Important changes in the logic should be allowed for all or none contract. |
| G1.9 | Verify that code analysis tools are in use that can detect potentially malicious code. |
| G1.10 | Verify that the latest version of Solidity release is used. |
| G1.11 | Verify that, when using the external implementation of contract, you use the current version which has not been superseded. |
| G1.12 | Verify that when functions are overridden to extend functionality, the super keyword is used to maintain functionality. |
| G1.13 | Verify that the order of inheritance is carefully specified. |
| G1.14 | Verify that there is a component that monitors contract activity using events. |
| G1.15 | Verify that the threat model includes whale transactions. |
| G1.16 | Verify that the leakage of one person's private key does not compromise the security of the entire project. |
For more information, see also:
- Instant Threat Modeling - SecuRing
- OWASP Threat Modeling Cheat Sheet
- OWASP Attack Surface Analysis Cheat Sheet
- OWASP Threat modeling
- Microsoft SDL
- NIST SP 800-57
- Use events to monitor contract activity
- An example of superseded contract - EIP 1820
Consult your architecture with the SCSVS authors. Contact a specialist.