Smart Contract Audit Process – Part 4 of the Smart Contract Series

In our previous posts, we have talked about smart contract security and the tools involved in the auditing process.

Today, we are going to walk through our process for auditing smart contracts, by reviewing the process for a recent smart contract audit conducted by us.

This is usually done in four stages:

1. Project Scope Assessment

This is the initial phase of our auditing process, and is common across all types of audits, not just for smart contracts. What we do here is to try and get a thorough assessment of the target scope, which is usually accompanied by a walkthrough of the DApp and all its features. This helps us understand the scope of the project, what the contract is trying to achieve, and what kind of risks can arise during its usage.

This is an essential step in the process since it helps us view the contracts from the developers’ point of view and understand their vision for it.

2. Code Review and Static Analysis

In this phase, we comb through the entire smart contract code along with its dependencies to look for any security issues/vulnerabilities that might be present throughout the smart contract code.

There are 2 ways to do this:

• Manual Code Review
• Automated Static Analysis

In a Manual Code Review, we read through each piece of the smart contract code to discover any vulnerabilities that might be present in the contract. This process can take up to a week or more, depending on the size and scope of the project in hand. For larger projects, this can take 2 weeks.

We also perform Automated Static Analysis for the smart contracts in parallel with the code review. Here, we use tools to analyze the smart contract codebase for vulnerabilities. This process looks a lot like what we did in the previous part of our smart contract blog series. We use tools like Slither and Mythril to augment our code review process and find more security issues.

Once we are done with this phase of the audit, we then publish an intermediate report for the client so they can initiate mitigation of the reported issues.

However, we are not done yet. We now move on to the next phase:

3. Dynamic Analysis:

Previously, we looked at the codebase to try and find security issues within the smart contract project. In this phase, we take a more hands-on approach to testing the contracts. We create test cases for the contracts, deploy those locally within a test environment and run the tests to see whether it is possible for attackers to misuse the smart contracts or attack them in any way. Sometimes, these tests require us to write additional contracts to test our attack vectors for the contracts in scope.

Depending on the framework being used in the project (Truffle, Hardhat etc.), the testing has to be done using the same framework as well.

These tests differ from project to project and are written specifically for the project in question. The number of tests depends on the size and scope of the project.

After we finish the dynamic analysis phase, we move on to the last part of the auditing process.

4. Reporting

This is the final phase of the auditing process. At this point in our process, we are done with our testing and we need to document our findings. We prepare a final report for the client, and walk them through it in a meeting.

This report contains a detailed description of each and every security issue discovered during the testing process, along with recommendations on how to mitigate them.

With this, we come to the end of the smart contract audit process.

Worried about attackers targeting your smart contracts? Contact us today to get your smart contracts audited for any security issues!

Anshul

Anshul is a cybersecurity analyst at DeTaSECURE. He has helped multiple organizations secure their digital assets as a security professional. He holds certifications like CEH and AZ-900. You can reach out to him by Clicking Here.