For most B2B software startups, capturing the mid-size to the enterprise market is a major growth goal. This is unsurprising as customers in that market have higher than average purchasing power, stability, and reliability. However, the security and compliance requirements of that market are often more stringent since those companies have much more to lose if their data or their customer's data were stolen.
Previously, we explored the cheapest ways to achieve compliance certifications like SOC2 (often expected for SaaS platforms), PCI-DSS (required for payment processing systems), and HIPAA (required for systems that store or manage healthcare data). In addition, standards exist - like the OWASP ASVS or NIST 800-53 - that provided guidelines for the security of web applications and general IT Systems respectively.
However, in the decentralized Web3 space, there is no single organization that regulates the security of smart contracts or dAPPS (decentralized applications). As a result, multiple individuals and organizations have created their own security standards and best practices.
In this post, we want to introduce one of the few open security guides for smart contracts and dApps (decentralized Apps).
The Smart Contract Verification Standard (SCVS)
This open-source security analysis standard for smart contracts and dApps is one of the few open-source standards for security blockchain apps. It was formed by Damian Rusinek and Pawel Kurylowicz, who created a 14-part checklist inspired by the OWASP ASVS for web applications.
It includes security development and testing guidelines in these areas:
V1: Architecture, Design, and Threat Modelling: Architecture, design and threat modeling in the context of creating secure smart contracts. Consider all possible threats before the implementation of the smart contract.
V2: Access Control: The process of granting or denying specific requests to obtain and use of information and related information processing services.
V3: Blockchain Data: Smart contracts in public blockchain have no built-in mechanism to store secret data securely. It is important to protect sensitive data from reading by an untrusted actor.
V4: Communications: Communications includes the topic of the relations between smart contracts and their libraries.
V5: Arithmetic: The arithmetic category covers mathematical operations in smart contracts.
V6: Malicious input handling: Malicious input handling is about how values obtained as parameters by smart contracts should be validated.
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.
V8: Business Logic: To build secure smart contracts, we need to consider the security of their business logic. Some smart contracts are weakened by vulnerabilities in 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.
V9: Denial of Service: The denial of service category focuses on the availability of smart contracts and possible ways to minimize the risk of DoS.
V10: Token: The token implementation should be in accordance with established standards.
V11: Code Clarity: Keeping code clear and simple has many advantages but the reason why we have created a whole category is that we believe security vulnerabilities will be much easier to spot and remediate.
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.
V13: Known Attacks: The Known attacks category has a different form from the other categories. It covers all known attacks and links them to the requirements from other categories
V14: Decentralized Finance: Decentralized Finance (DeFi) is a concept with various financial applications deployed on the blockchain using smart contracts. This category covers the security requirements for the constructions used by the DeFi applications such as lending pools, flash loans, governance, on-chain oracles, etc.
The SCVS checklist serves various purposes, including
Acting as a foundation for formal threat modeling.
Assessing the security and maturity of a smart contract.
Defining the scope of a penetration test or security audit for a smart contract.
Providing a list of formal security requirements for developers or external parties working on the smart contract.
Enabling developers to perform self-checks.
Identifying areas in need of additional security development.
To get started with the SCVS Checklist, you can begin here.
The 5-Minute Security Assessment for Blockchain Startups
Are you considering a security audit of your blockchain-based project? I want to invite you to take our Free 5-Minute security assessment, designed specifically for SaaS and Blockchain startups. And yes, it really does take only 5 minutes, then we do the rest.
Once you complete the short assessment form, we craft two confidential reports - A Security Assessment report that show what your major software security gaps and risks are, as well as A Security Recommendations Report with custom solutions and priorities that your team can either begin implementing or add to your roadmap.
