This document outlines a simple approach for conducting a security review. We don't use the related term "security audit" because the word "audit" would traditionally imply a certified professional completing this work to provide a level of verification.
IMPORTANT. We cannot provide a guarantee that this process will lead to discovering all vulnerabilities, but it's a good starting point to refining your own process whether you are doing this internally or on behalf of clients. There may be a temptation to consider this document as an exhaustive "checklist". Unfortunately, security is more an art than a science and each set of contracts require their own distinct treatment. We hope that this document is a helpful reference if you forgot to consider one or the other attack vector, but it should not constitute the entirety of your security process.
Before starting, identify and agree on the scope of the review. Reviews can encompass a whole patch or focus on as little as one function. Other ways scope can manifest are the following:
Agree on a specific commit.
Since security reviews often happen in a limited time frame, you should focus your attention on areas that are more likely to reveal vulnerabilities:
A good way to explicitly capture these priorities is to create a list of questions to answer during the review, e.g., "establish that user funds cannot be lost".
As you look for and discover vulnerabilities, you will need a way to test them. Learn how to use the tooling in the given code repository in order to create your own tests or set up a dedicated environment for experimentation. A test net deployment of the code base could also help with this purpose but is not always feasible.
Follow How to Quickly Understand a Protocol to speed this process up.
Make sure you get as much context as possible. Unless you are specifically required to do a black box code review, you should use any and all available documentation to get up to speed with what the system is trying to do. If some areas are not well documented or confusing, ask questions to solidify your understanding. Chances are the ambiguity may have led to an actual issue.
Study the most significant dependencies (e.g., libraries, external code, etc.). Read the audit reports for each dependency as they could suggest potential issues in usage or incorrect assumptions.
Use a Visual Inspection Tool like Surya to generate overview diagrams for the code base. These will come in handy in a wide variety of situations, for example:
From your list of questions, you can use the references below to find the most appropriate review techniques and tools to answer these questions. The use of each technique should be informed by the specific nature of the smart contracts being reviewed.
Even for internal reviews, it's recommended to prepare a review output for the following purposes:
After the security review is complete, you may discover that some issues were not discovered at the time. This is an opportunity to come back to the process and analyze if you missed the vulnerability simply due to human error or because of a missing step in the process. Ask yourself, what kind of auditing technique would have helped discover this issue? Implement it for the next review. Please get in touch with us on Twitter if you discover a new auditing technique.
Disclaimer. We are not a professional security auditing firm. We have merely listed techniques that we have found useful from time to time, use them carefully and at your own judgment.