Smart contract security Audit 101

As blockchain is revolutionizing industries, hacks and other security breaches threaten to derail it before it can really take off. To put it more specifically, blockchain itself is secure in most cases, but the apps that run it are not. Blockchain interacts with the apps via smart contracts, but it is still vulnerable to specific kinds of bugs just like any other software. However, it is important to note that blockchain apps very often have direct control of financial assets. This puts a greater emphasis on securing the smart contract to avoid a hack like the infamous attack on the Decentralized Autonomous Organization (DAO) in 2016. Hackers exploited a vulnerability in the smart contract to  steal $50 million worth of Ethereum.  

In order to make sure that the blockchain apps are safe to use, it is necessary to conduct an audit of the smart contract to identify any possible vulnerabilities.

Performing the Smart Contract Audit

Auditing the smart contract entails a thorough analysis of the contract itself to identify possible mistakes in the code, design flaws, and other security issues. Let’s take a look at some of the steps involved in the audit.

1. Specification

The audit team will study all of the specifications and other related documents to obtain information about the architecture, design and how the app was built. If the audit team does not have access to this information, they will not know what the code is meant to do or whether or not it works properly. Therefore, the first thing that you should do before undertaking such an audit of the security contract is to make sure that all project specifications are accounted for since they will serve as the foundation for the audit itself.

Make sure that everybody is in agreement when the code freeze will happen. This is when the code has been finished and the developers have looked over everything to make that there are no bugs. A final commit hash will be included in the specs to make sure that everybody is on the same page as to the code that is subject to the audit and any further changes are not within the scope of the audit.

2. Testing

Testing is the best and easiest way to identify bugs. These tests can range from unit testing, which is targeted at certain functions, as well as integration testing, which is broader in terms of scope and volume of code. By performing all of these tests, you eliminate the easily noticeable bugs, thus making the audit more effective. Also, the tests will make sure that everybody is in complete agreement in terms of how the project is supposed to perform and what functionalities should be, thus preventing confusion during the audit itself. There will usually be a whole suite of tests performed by the auditing team. If they see a large amount of failed tests, they will suggest a temporary pause in the audit if significant changes need to be made to the code-base.

Be sure to check the line coverage, which will tell you how much code has been covered by the tests. The more code that has been covered, the more features have been tested, which translated to fewer unforeseen issues and vulnerabilities. Generally, line coverage should be about 85-90%. If this number falls below 75% the project team should be notified as soon as possible so more testing can be conducted before deployment.

3. Automated Testing

Software that controls financial assets requires the safest code possible, which means that automated tools will have to be used. Such tools can be used to identify the inputs that trigger each part of the program to perform. This makes it much easier for the auditing team to locate common stumbling blocks, thus reducing the audit turnaround time and allowing the human auditors to focus on new and more complex issues.

4. Manual Testing

The automated tools will not be able to understand the developer’s intentions. There will be situations where the software might be perfectly sound, but it will differ from what the developer initial wanted it to perform. This is why manual testing is also necessary. A quality auditing team will take in all of the specifications and then determine whether everything is working as intended. If it is not, they will notify the development team and provide recommendations on how to fix the issues.

5. Providing You With a Report

Once the audit has been completed, your internal team or the contractor performing the audit will provide you with a detailed report on the work that has been performed and the findings. The development team must need to understand all of the issues detected and the audit team will make recommendations of the needed patches. In fact, it is a good idea to conduct an additional audit to make sure that all of the patches have been implemented and there are no identified vulnerabilities.

Different Strokes for Different Folks

It is important to understand that there is no perfect or standard approach for smart contract auditing. When push comes to shove, a lot of the big decisions will be left up to the auditing team and the development team might not agree with the recommended changes. This is where transparency is absolutely critical. In order to make sure that everybody is aware of the state of the project, all of the information must be available for open discussion, thus increasing the likelihood of a successful project. It would not make much sense to pin one team against another since, ultimately, everybody has the same goal. Everybody needs to understand that if vulnerabilities are found, it is not an indictment against them. It is the auditing team’s responsibility to protect the financial assets of the clients and the reputation of the company. Another hack like the one experienced by the DOA mentioned above would be disastrous for any organization, just like it was for the DOA itself.