Smart Contract Audit Guide
The audit process consists of multiple steps. To get audited by the Dedaub team, if we have not had prior communication, the best first step is a request through our contact page. Please include as much information about your project as possible in order for us to start looking into it. Assuming your project is a good fit for our team, we will contact you back, to start the scoping phase. After the scope is agreed upon, and our LOE is signed, we may send you further instructions that will help you prepare your project for auditing.
The most important phase of the audit process involves our engineers actually performing the audit. Subsequently, a number of fix reviews may be carried out, depending on whether the project is modified and our services are requested again.
But first...
How To Think of an Audit
The best advice for a development team is to think of the auditors as their allies in the security battle. The developers remain the primary stakeholders of the project, so ultimate responsibility for security decisions remains with them. A red flag for us (starting from very early phases of the process) is a desire to just get a stamp of approval and move on, or, worse, to expect that auditors are the ones that will magically add security to a project that has not much considered it before. (Sometimes this misalignment of reality and expectations is obvious from the very first step of the process, e.g., from getting questions such as "will your audit be recognized in country-XYZ courts?". If we see the misunderstanding persist after informing the client of the realities of what an audit provides, we typically do not engage.)
The absolute best auditing results are achieved when, for every consideration an auditor raises, the development team ends up thinking of more! The audit is meant to be a hard look at the security of a project, with its outcomes thoroughly examined, generalized, acted upon, or possibly dismissed (with care). Not a checklist, but an in-depth study that the development team fully owns at the conclusion of the audit.
Audit Process Steps
1. Project Scoping
In this step, we are trying to estimate how much time is required for our team to audit your project with a good level of confidence. The easiest way for us to scope your project is to provide us with the source code via Github. If you require an NDA prior to this step, we provide an easy signing process (mutual NDA, pre-signed on our end, hence immediately executable as soon as you sign) through this form. Further information, such as documentation and whitepapers, or video calls with your developers will further help us scope the project appropriately and determine whether we would be the right match for your project. If a vulnerability is discovered during the scoping phase, we will disclose this to you for no cost.
At the end of the scoping process, we will provide you with a proposal and quote for auditing your project.
2. Signing the Dedaub LoE
If the proposal and quote is to your liking, you will need to sign our Letter of Engagement (LoE). The terms contained in our LoE are standard, and are available here. Most of the time, we bill projects by the time required to audit the project at our standard daily rate. If, by the time the project starts, you request us to audit a larger project than originally scoped, we will let you know the difference in advance, assuming we have the time capacity to audit it.
3. Project Preparation
During auditing, you are employing security consultants to go over your code. For auditors, studying your code and issuing an audit report is a complex balance. Auditors need to have some level of confidence to sign off on your project, yet they will not spend infinite time to gain this confidence. The time allotted has typically been scoped based on your code size and apparent complexity, using extensive past experience. You can help us by following these steps:
To enhance the auditor's confidence and facilitate their work:
- Provide Succinct, But Sufficient, Documentation: Before auditors start their work, provide them with clear and comprehensive documentation that explains the intent and design of your project. This is not merely about code specifics, but should also provide an understanding of the project at a high level. Of course, when one understands both levels, the high-level should match the specifics.
- Use Consistent Naming and Comments: Try to use consistent variable and function names to explicitly document the intent of the code. Use comments to document complex parts of the code but also make sure these are consistent with the code. If you can write invariants or explain the intent of complex parts, this can go a long way.
- Set Up a Communication Channel: Establish a synchronous communication channel between your developer(s) and the auditors to facilitate information sharing. If requested, walk the auditors through your code before they start the audit or when they prefer to (e.g., after they have read the documentation, or after one pass over the code). Be responsive during the audit period.
- Ensure the Project is Fully Tested and Compiles: By the time an audit begins, make sure the project compiles without errors and is fully tested. This will allow the auditors to focus on the difficult parts of the code, rather than discovering that some functions are uncallable or do not do what they are expected to do under straightforward inputs. Possibly deploy your code on a testnet and exercise it to its limits, focusing on unexpected, corner-case, and possibly adversarial behavior.
- Understand the Limitations of a Manual Audit: An audit is not a testing service or a magical way to find all bugs. Auditors will not know your specification (i.e., your mathematical formulas, your desired behavior) if you do not clearly communicate it. Auditing will likely miss violations of functional correctness when the definition of correct calculations is not given.
- Focus on Adversarial Environmental Conditions: Auditors' time is best spent thinking about adversarial environmental conditions and not simply uncommon inputs. The latter is a functional correctness issue, best uncovered via testing.
4. Core Audit Phase, on Our End
The smart contract audit consists of a careful inspection of your project’s code by expert human inspectors, aided by Dedaub’s proprietary analysis tools that leverage theorem proving and static analysis techniques, off-the-shelf tools, and other techniques in accordance with state-of-the-art practices. The findings of this exercise will be detailed in an audit report. This report will rank issues as “Critical”, “High Severity”, “Medium Severity”, “Low Severity”, and “Advisory Suggestions''.
During this phase, we try to be in synchronous communication with developers, as needed. This helps in getting us quick clarification on unclear topics, in preventing misunderstandings as early as possible, and in offering the development team continuous feedback, especially on crucial isses.
The audit team will be selected to provide the best match to your protocol. We have multiple audit teams, and if you are developing a fork of a major protocol, we might have auditors who have audited the same protocol you're forking off from. We also have people outside the smart contract audit team that can assist the core audit team, such as expert quants, cryptographers, or senior blockchain engineers.
Our audits are internally soft-2-phased. That is, without strictly allocating the time, we try to have a first phases of just understanding the code from the perspective of normal use, followed by an in-depth "adversarial" phase, where we ask how the code can be abused by a possible attacker. We also rely heavily on the two senior auditors educating and challenging each other continuously: each one is asked to come up with questions for the other to answer; summaries of aspects they found surprising/interesting; trust and threat models.
5. Fix Reviews (optional)
The typical audit engagement does not include fix reviews by default, since these are not always required. After delivering an audit report it is recommended to fix issues indicated in the report starting from the critical and high severity issues.
When undertaking formal bytecode reviews, Dedaub utilizes our decompiler and static analysis toolchain to validate the semantics expressed in the codebase.
When undertaking a fix review, based on fixes that arise out of our reporting, Dedaub reviews the fixes for issues identified in the original report. This work involves a review of specific areas of the source code, not a comprehensive analysis of the system.
6. Post-deployment security monitoring (optional)
This part is entirely optional, but should you decide to get audited by our team, we usually provide two months of free monitoring services.