Smart Contracts Security Verification Standard
In recent months, me and Damian Rusinek have worked together to standardize the security of smart contracts for developers, architects, security reviewers and vendors. In short — everyone working with smart contracts.
Smart Contracts Security Verification Standard
In recent months, me and Damian Rusinek have worked together to standardize the security of smart contracts for developers, architects, security reviewers and vendors. In short — everyone working with smart contracts.
We set clear objectives to achieve:
- Help to develop high quality code of the smart contracts,
- Help to mitigate known vulnerabilities by design,
- Provide a checklist for developers, architects and security reviewers,
- Provide a clear and reliable assessment of how secure a smart contract is in relation to the percentage of SCSVS coverage.
It wasn’t as easy as we thought to think of something that would meet all four goals, but after a few creative evenings over beer — Damian came up with a great idea.
How did we implement it?
We created a 13-part checklist in a form inspired by well-known and widely used OWASP ASVS. Everyone in the #appsec knows or SHOULD KNOW this standard, that’s exactly why we think that this form will be the handiest and useful for everyone.
Here are key areas that we covered:
V1: Architecture, Design and Threat Modelling
Architecture, design and threat modelling in the context of creating secure smart contracts. Consider all possible threats before the implementation of the smart contract.
High-level requirements:
- All related smart contracts are identified and used properly,
- Specific smart contracts security assumptions are considered during the design phase.
Category “V1” lists requirements related to the architecture, design and threat modelling of the smart contracts.
V2: Access Control
Access control is the process of granting or denying specific requests to obtain and use information and related information processing services.
High-level requirements:
- Users and other contracts are associated with a well-defined set of roles and privileges,
- Access is granted only to privileged users and contracts.
Category “V2” lists requirements related to the access control mechanisms of the smart contracts.
V3: Blockchain Data
Smart contracts in public blockchains have no built-in mechanism to store secret data securely. It is important to protect sensitive data from reading by an untrusted actor.
High-level requirements:
- Data stored in smart contract is identified and protected,
- Secret data is not kept in blockchain as plaintext,
- Smart contract is not vulnerable due to data misrepresentation.
Category “V3” lists requirements related to the blockchain data of the smart contracts.
V4: Communications
Communications includes the topic of the relations between smart contracts and their libraries.
High-level requirements:
- The external calls from and to other contracts have considered abuse case and are authorized,
- Used libraries are safe and state-of-the-art security libraries are used.
Category “V4” lists requirements related to the function calls between the verified contracts and other contracts out of the scope of the application.
V5: Arithmetic
Arithmetic category covers mathematical operations in the smart contracts.
High-level requirements:
- All mathematical operations and extreme variable values are handled in a safe and predictable manner.
Category “V5” lists requirements related to the arithmetic operations of the smart contracts.
V6: Malicious input handling
Malicious input handling is about how values obtained as parameters by smart contracts should be validated.
High-level requirements:
- The function parameters being passed are handled in a safe and predictable manner.
Category “V6” lists requirements related to the malicious input to the functions of smart contracts.
V7: Gas Usage & Limitations
The efficiency of gas consumption should be taken into account not only in terms of optimization, but also in terms of safety to avoid possible exhaustion. Smart contracts by nature have different limitations that, if they are not taken into account, can cause different vulnerabilities.
High-level requirements:
- The use of gas is optimized and unnecessary losses are prevented,
- The implementation is in line with the smart contracts’ limitations.
Category “V7” lists requirements related to gas and smart contract limitations.
V8: Business Logic
To build secure smart contracts, we need to consider the security of their business logic. Some of the smart contracts are influenced by vulnerabilities by their design. The components used should not be considered safe without verification. Business assumptions should meet with the principle of minimal trust, which is essential in building smart contracts.
High-level requirements:
- The business logic flow is sequential and in order,
- Business limits are specified and enforced,
- Cryptocurrency and token business logic flows have considered abuse cases and malicious actors.
Category “V8” lists requirements related to the business logic of the smart contracts.
V9: Denial of Service
Denial of service category focuses on the availability of smart contracts and possible ways to minimize the risk of DoS.
High-level requirements:
- The contract logic prevents influencing the availability of the contract.
Category “V9” lists requirements related to the possible denial of service of the smart contracts.
V10: Token
The token implementation should be in accordance with established standards.
High-level requirements:
- The implemented token follows the security standards.
Category “V10” lists requirements related to the token of the smart contracts.
V11: Code Clarity
Keeping code clear and simple has many advantages but the reason why we have created a whole category it is that we believe security vulnerabilities will be much easier to spot and remediate.
High-level requirements:
- The code is clear and easy to read,
- There are no unwanted or unused parts of the code,
- Variable names are in line with good practices,
- The functions being used are secure.
Category “V11” lists requirements related to the code clarity of the smart contracts.
V12: Test Coverage
We know from experience that when and what is tested is as important as how and that is what Test Coverage focus on.
High-level requirements:
- The specification has been formally tested,
- The implementation has been tested statically and dynamically,
- The implementation has been tested using symbolic execution.
Category “V12” lists requirements related to the testing process of the smart contracts.
V13: Known Attacks
The Known attacks category has a different form from the other categories. It covers all known attacks and link them to the requirements from other categories.
Category “V13” aims to ensure that a verified contract is protected from the known attacks.
I hope I got you a bit closer to the standard we’ve created. We really would like it to become a tool solving many problems related to the security of smart contracts in the future, but to this we need feedback from You. That’s why I invite you to contact:
- Me (pawel.kurylowicz@securing.pl) or
- Damian (damian.rusinek@securing.pl) and share your ideas!
Full Smart Contracts Security Verification Standard can be found at:
https://securing.github.io/SCSVS/
If you believe in this project, please SHARE so that more people can hear about SCSVS.
Hackflix Product Lead
