-
Notifications
You must be signed in to change notification settings - Fork 0
Auditing Process
In this section I will dive into best practices and auditing processes for Smart Contracts. If you are a developer comprising smart contracts, it is imperative that you have an audit conducted. Millions and millions of dollars worth of investor capital and contract liquidity have been drained over the past 6 years due to excessive vulnerabilities in various protocols. (I have another page dedicated to some of the most common and infamous attacks to date)
Below, I will highlight the necessary steps and measures to take in the duration of a Smart Contract audit and the amount of time that should be allocated.
It is important to ascertain the time and number of individuals necessary for an audit. Its best practice to work with more than one auditor of course. This is dependent on the complexity of the codebase, as protocols or contracts that have multiple instances of inheritance, use cases etc may need a larger team of auditors. You may come across some contracts that can appear to be convoluted, employing mathematical concepts.
Covering the codebase is equally important from an understanding perspective and this is important to feature in the audit process. Large codebases like a DEX or Lending Protocols would require several weeks of analysis, whereas perhaps basic ERC20 contracts may only need 2/3 days maximum.
This is a very important step; understanding the codebase. Read the documentation, if there is any. If not, ask for it! It will help you decipher what is going on with the contract/s. Perhaps align with other protocols who have a similar set up e.g a DEX or Staking protocols. Going through previous audit on these contracts is key as well. Additionally, become acquainted with the common vulnerabilities associated with these models.
So you have the contracts in front of you and you have done the above. Its time to manually walk through the different functionalities. As you do this, you'll come across elements of the code you may not understand. This is fine. Add an @audit tag with your thoughts and revisit it at a later point. If you think at initial analysis there are some potential areas of vulnerability, add an @audit tag or even add your thoughts, some questions perhaps. Its also useful to highlight any gas optimization areas.
At this point, you need to be familiar with some useful security tools which are going to aid your audit. Here is a link to some of the most useful tools recommended by the Consensus team. Please have a read through, but they incorporate methodology to statically analyze your smart contracts in real time.
Additionally, there are tools available to conduct Fuzzing on your Smart Contracts, where you will send random inputs of data via a function call. This will stress test your Smart Contract functionality and see if the function will return something it is not expected to return.
Please have a detailed read through via the link above, as this is, in my opinion, a prerequisite to conduct technical analysis of your Smart Contracts.
Should you browse through the Smart Contract you have been given to audit, and find there is little to no tests written, this should be a core focus. You want to make sure the codebase works at its supposed to. So, just like you did in the initial stages, you will want to refamiliarize yourself with what the Smart Contract is trying to do. If there is existential test coverage, then you will need to review the test that are currently in place. Do they cover all bases? For example, say you have the below function in the code you're reviewing:
function mint(address to_, uint256 tokenId_,) public payable virtual onlyRole(MINTER_ROLE) {
_mint(to_, tokenId_,);
}You can see that it is designed to only be called by the person who has control over the MINTER_ROLE. So you will want to test that this can happen. Additionally, you will to test that it cannot happen if the person trying to call this function is not the MINTER_ROLE. Perhaps the protocol you are reviewing has several roles? You want to test that none of these other roles in isolation can call this function. It may include suggesting to the developers of this code that they need to include a revert message? This is a simple example, but you should always make sure all possible angles are covered.
You can include this as part of PoCs (Proof of Concepts), which you need to prove to the developer that a vulnerability exists. This could also tie in nicely with any Fuzzing or Hacking you might conduct.
Testing in this manner can be executed with Fuzzing of course, or by implementing basic Unit Tests written in Javascript. There are other ways to conduct testing and various frameworks like Truffle, Hardhat and Foundry to name a few. I have listed them below.
You will now want to conclude your audit. This will involve creating some documentation or/and formal notes on your progress and what you have found during your audit process. With your discoveries, create an overview in the report with the description, vulnerability, status, the sincerity of it and remediation. I would suggest for high-severity discoveries, create parity with a PoC, so the developers can see specifically what you are highlighting. At this point, the team can refactor, if necessary, the recommendations you have made.
This isn't an exhaustive list and the audit may continue after these stages. Perhaps off the back of your recommendations, births another audit? Be prepared to follow best practice above, even in the event of a second or third audit.