The future security of your smart contracts – upcoming changes in SCSVS

Maintaining security in DeFi projects

One of the biggest security problems with DeFi today is the fact that with such a fast pace of market development, it is difficult to ensure proper education and development of developers. There is a lack of reliable and proven materials, and even if such materials are created, they very often cease to be up-to-date or there is no time to consume them. Designs rely on general reputation and if something has been around long enough and hasn’t hit rekt.news it is considered relatively secure. Very few projects use threat modeling to make decisions based on informed choices rather than general assumptions.

Remember that:

Therefore, the fact that the project has not been hacked does not mean that integration with it will not introduce a bug to your system.

Cooperation with auditors, even though it is necessary, with the current occupancy does not allow testing all new creative projects that need them. Therefore we decided to undertake the adaptation of SCSVS to the upcoming changes. The version 2.0 will not only cover current problems, but also adapt to the composability spirit in which projects are built.

Drive to make Smart Contract Security Verification Standard even better

The Smart Contract Security Verification Standard has proven its worth over the years  and became one of the most comprehensive and helpful materials for smart contracts developers, auditors and architects. We have heard a lot of good things both from the BlockSec community and from our clients. Here are a few examples:

Such opinions are very valuable to us and make us feel that we need to continue the good work. We must also look to the future, supporting the construction of a new, secure and decentralized world. Based on over 18 years of experience in the security industry, we get to know various perspectives, and it is this knowledge that allows us to take up the challenge of solving the toughest issues.

SCSVS 2.0 – upcoming security revolution for DeFi

Security, Composability and Transparency are fundamentals on which we want to build this standard. We want projects to be able to consciously make such important decisions as what contract to use or with which project to integrate. For this reason, we decided to propose a breakdown of the security approach into three different areas by creating chapters for the different categories.

General – design, upgrades, policies, common and general security concerns.

Containing most of the categories from SCSVS v1.2. There are system issues that are not specific to any particular type of contract. It will give you a good overview of the security condition of the project: smart contracts, approach, policies and procedures.

G: Architecture, Design and Threat Modeling
G: Documentation and procedures NEW!
G: Upgradeability NEW!
G: Access Control
G: Blockchain Data
G: Communications
G: Arithmetic
G: Gas Usage & Limitations
G: Business Logic
G: Denial of Service
G: Code Clarity
G: Test Coverage

Components – contracts that make up the project, frequently used patterns with their typical security issues.

The first new chapter will contain categories dedicated to frequently used contracts and their common issues. This category will allow not only a quick overview of what a given project consists of, but also securely expand it by selecting a checklist for a specific contract that you want to build.

C: Token 
C: Governance NEW!
C: Bridge NEW!
C: Oracle NEW!
C: Liquidity pool NEW!
C: Vaults NEW!

Integrations – external components with which the project integrates, general recommendations and threats to frequently used smart contracts.

The second new chapter will focus on integration with components. In addition to the general list important for integration with any smart contract, here we also plan to create categories for the most frequently used components such as tokens, pools, governance and more.

I: Basic NEW!
I: Token NEW!
I: Governance NEW!
I: Oracle NEW!
I: FlashLoan provider NEW!
I: Liquidity pool NEW!

Bright future of smart contracts security ahead

Now let’s imagine for a moment that we plan to integrate our system with some external smart contract, e.g. allow the use of a new Token. What can we do? We can browse the DeFi hacks history to see if there have been problems with it. We can try to find the report and read exactly what is in it. Furthermore, we can also rely on the principle that if everyone uses it, it has to be good and secure. 

We can also contact the developers or order our own tests of this component, but each of these methods requires a lot of commitment and, due to the lack of standardization, can take a long time and have various results. Every report, every team, article or history of existence will be different. But what if all these difficulties could be avoided?

Suppose we have a set of filled SCSVS for all protocols to aid our decision making. Various audit firms, regardless of their methodology, follow common guidelines, which are a set of known mistakes made in the past and best security practices from the AppSecworld. What’s more, we do not have to review the entire history and all reports, we can, as a decision-maker, check the Token by a specific category result. Already, on the basis of this information, we will know if it is even worth considering further integration.

If the Token passed through this check and the SCSVS result satisfies us, we were left to go through the categories from the Integrations chapter. In addition to checking whether the component is well-managed, check what threats it can bring to our system and consciously make the final decision to integrate the external smart contract.

What a beautiful world it would be if every project repository in addition to reports with different test scopes, methodologies, and all the small details that are very important and are time-consuming to verify.  There would be also an SCSVSv2 which:

• clearly shows the percentage result,
• has a universal methodology and the same checks for everyone,
• shows the full spectrum of security from design, policies and approach to security to very technical and specific issues for selected components.

It’s all about teamwork

Going further, there might be a one place where we can gather completed SCSVS of all projects. Wouldn’t it be wonderful?

In our opinion, it would. But, it is only possible with your help. We will be able to make projects more secure if they know about the existence of SCSVSv2, and it is useful to them. On our part, we will make every effort to ensure that it is the most qualitative and well-thought-out standard. 

Due to the fact that we want this standard to become universal and widely accepted, we are also starting talks with many excellent specialists and friends from the exceptional blockchain security community. Soon we will provide a draft repository to which we will encourage all specialists to contribute. If some checks are not clear, become obsolete, or you see that we are missing an important category – you will be able to act!

Follow our project on GitHub (turn on notifications!) To be up to date with upcoming changes.

👉 https://github.com/securing/SCSVS 

Something amazing is on the way. Help us build the standard based on which projects will be able to boldly build a new, secure, better and decentralized future.

We enjoy talking with others who care about smart contracts security. If you have any thoughts about upcoming changes, feel free to write to us!

Paweł Kuryłowicz Principal IT Security Consultant
Hackflix Product Lead