- Damian Rusinek @drdr_zz ([email protected])
- Paweł Kuryłowicz @wh01s7 ([email protected])
Smart Contract Security Verification Standard (v2) is a FREE checklist created to standardize the security of smart contracts for developers, architects, security reviewers, and vendors.
This list helps to avoid the majority of known security problems and vulnerabilities by guiding at every stage of the development cycle of smart contracts (from design to implementation).
Objectives
- Help to develop high-quality code of smart contracts.
- Help to mitigate known vulnerabilities by design.
- Provide a checklist for security reviewers.
- Provide a clear and reliable assessment - Compliance score - of how secure smart contracts are in the relation to the percentage of SCSVS coverage.
Security, Composability, and Transparency are fundamentals of the SCSVS. These values are achieved thanks to the engagement and cooperation of the #BlockSec community. The standard structure distinguishes 3 chapters, each operating in a slightly different area.
- General - common and general security problems including, among others: design, upgrades, and policies.
- Components - contracts that make up the project, frequently used patterns with their typical security issues.
- Integrations - components with which the project integrates, general recommendations and threats to frequently used smart contracts.
You can use the SCSVS checklist in multiple ways:
- As a starting point for formal threat modeling exercise.
- As a measure of your smart contract security and maturity.
- As a scoping document for a penetration test or security audit of a smart contract.
- As a formal security requirement list for developers or third parties developing the smart contract for you.
- As a self-check for developers.
- To point out areas that need further development regarding security.
Depending on your role in the protocol, we recommend performing different actions summarized below. Treat it as an inspiration and not strict rules.
If you are designing a protocol, you should schedule (and potentially delegate) the following actions:
- Use security requirements from the General and Components chapters to identify potential security bugs your team might introduce in the protocol.
- Use security requirements from the Interaction chapter to identify potential threats coming from the 3rd party protocols.
- Write down all potential threats identified in steps 1 and 2. This will be great input for the threat modeling session.
- Inform your team about the identified threats (e.g. during a threat modeling session).
If you are developing a protocol, you should schedule (and potentially delegate) the following actions:
- Get the potential threats identified by the Auditor, Architect or during a threat modeling session and learn how to avoid them.
- When implementing a smart contract with specific functionalities, check the security requirements from the corresponding SCSVS category.
- After release, make sure the SCSVS coverage report is present in the protocol repository.
If you are the owner of a protocol or represent the business side of the project, you should schedule and delegate the following actions:
- Ask other protocols teams that yours is integrated with for their SCSVS coverage report.
- Check the Compliance score of your protocol by doing SCSVS coverage of all 3 chapters.
If you are an internal or external auditor of a protocol, you should schedule (and potentially delegate) the following actions:
- Do a threat modeling session (as soon as possible) to identify potential threats and decide how to handle them. Use the output of Architect actions as partial input.
- Just before the release, do the SCSVS coverage of all 3 chapters to get the Compliance score of your protocol.
- Add SCSVS coverage report to the protocol repository.
- G: General
- C: Components
- I: Integrations
Threat modeling and risk analysis are important parts of the security assessment. Threat modeling allows the discovery of potential threats and their risk impact. Risk analysis aims to identify security risks and determine their severity, which allows the team to prioritize them in the mitigation process.
The SCSVS does not include the severity of the risks related to the requirements. Even though there are multiple methodologies to assess the severity, each application is unique and so are the threat actors, their goals, and the impact of a breach.
Moreover, the requirements cannot be uniquely linked to the security risks, as many risks can refer to one requirement and many requirements can refer to one risk.
We recommend determining the severity of the risks related to the requirements when performing the security assessment using the SCSVS standard.
We recommend Common Vulnerability Scoring System (CVSS), a free and open industry standard for assessing the severity of security vulnerabilities.
The SCSVS project was originally started by Damian Rusinek and Paweł Kuryłowicz in securing company in the following repository: https://github.com/securing/SCSVS.
This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
The entire checklist is in a form similar to OWASP APPLICATION SECURITY VERIFICATION STANDARD v4.0. Every category has a brief description of the control objectives and a list of security verification requirements.