Definition
A security audit is a process in which a client subjects his or her smart contracts to a review, in which one or more auditors search and document vulnerabilities that may alter the project correct functionality. The main idea of this post is to specify the process of audits, who belongs to them and how the different individuals interact from the moment the client reaches us to the moment we end communication with them.
Roles
Client
The client starts the audit process when he reaches us. The Lead Manager will verify if their petition corresponds to an audit and proceeds to mediate deadlines and budget depending on the source code the client provides. Once an agreement is accomplished and the payment is done the client will have direct communication with the Client Manager and the auditor, who will provide updates as needed. At some point before the deadline is due it will receive a document with the results of the audit. The client should also review this document and provide updates to the source code if applicable which will be used to further update the original document for publishing.
Lead Manager
The Lead Manager is in charge of reviewing the petitions of potential clients who reached us. In case the Lead Manager understands that the client wants an audit, it will start to mediate as explained in the Client role. Once the Lead Manager receives the code, it will give the files to the Audit Manager who will try to determine the difficulty of the audit. Using that information, the Lead Manager will finish mediating the deadline and budget with the client who will settle the payment and start the audit.
Audit Manager
The Audit Manager is in charge of assigning the audit task to the auditors depending on their availability. The Audit Manager should also be able to determine the complexity of an audit. If there are doubts, it should talk to the Auditor which will be in charge of executing the audit to further determine the deadline. It is also in charge of reviewing the audit documents before delivery, or assigning the task to another auditor.
Client Manager
The client manager is in charge of establishing continuous communication with the client and the auditor during an audit. It should be able to clarify any doubts that the client has while the auditor is not present. It should also address further concerns the client may have once the first iteration of the document is presented. This includes deadlines for the client to make changes to the source code, if the audit is going to be published or not, when it will take place if that is the case, and any other concerns the client may have.
Auditor
The auditor is in charge of executing the audit. It will create a document that includes the vulnerabilities he finds in the project, and other important information. It should also be available to discuss the complexity of a project with the Audit Manager before the audit starts. It will be in constant communication with the client, asking questions about the code and clarifying potential vulnerabilities that will be in the document. It will also create a second version of the document after the client fixes the vulnerabilities included in the first document.
Deliverables
Audit Guide
This is a general document that will be delivered to the client once it’s established that an audit is needed. It should contain a summary of the audit process in regards of what the client should expect from us and what we expect from them. It should be available publicly for other potential clients. It should make sure to explain that an audit is not a formal proof, and it’s subject to false negatives (non documented vulnerabilities) and false positives (vulnerabilities wrongly documented).
Audit Report
This is the document created by the auditor. This document should contain all the vulnerabilities found, introduced by a description of the project to audit and the audit itself in detail. It should contain at least:
- A description of the audited contracts, describing what they do and how they interact with each other.
- A list of the vulnerabilities found, categorized in order of importance.
- A description of the analysis performed, detailing also the contract code and how it works.
- An overall conclusion of the state of the contracts, and what options the client may have to proceed.
In addition, it may contain:
- A list of suggestions to enhance the contract code.
- An evaluation of the project design in the context of potential future changes and their impact on the security of the audited system.
The auditor should also provide documentation that eases the technical review by the Audit Manager. This may be included in the report if it’s considered valuable input to the client.
Interactions
These are the interactions in order of occurrence between the different roles in an audit process:
- The client contacts us via email or another medium.
- The Lead Manager determines which kind of service the client needs, in this case it determines it needs an audit.
- The Lead Manager establishes communication with the client, ensuring the service needed is an audit and guiding them. If all goes well, the client will receive an audit guide containing the details about the audit process, and the Lead Manager should receive the code from the client.
- The Lead Manager gives the source code to the Audit Manager, debating about the complexity of the project. Furthermore the Audit Manager should take into account the availability of the Auditors which may affect the deadline of the audit.
- Requirements: It is necessary to have the source code to audit, and knowing exactly which parts of the project are meant to be audited. The code should be stable without any expected modifications in the short term.
- Dynamic: The Lead Manager shares the code with the Audit Manager and they debate.
- Results: A partially objective judgement about the complexity and deadline of the audit.
- The Lead Manager negotiates and determines the final details of the audit:
- The budget
- The deadline
- Which medium to communicate with during the audit
- The Lead Manager communicates with the Audit Manager again to inform that the deadline was set and the payment was completed, which allows the Audit Manager to begin the audit.
- The Audit Manager should assign the audit to one or multiple auditors if necessary, giving them the source code to audit. Furthermore the Audit Manager should also inform the Client Manager so they may establish a communication channel between the client and the auditor.
- At the same time:
- The Client Manager should establish a communication channel with the client, depending on what is more convenient.
- The Auditor should make a local copy of the source code for a historical registry. Also, it should make a document specifying the project, the starting date, and a link to the code repository. The document should also contain an activity log specifying which actions were taken, the dates when they started and their duration. Finally, it should start auditing the smart contracts of the client while creating the audit report.
- Once the communication channel is established, the Auditor should use it to communicate with the client. The dynamic should be as fluid as possible, despite the difference in time zones. All doubts should be evacuated, and as soon as some vulnerabilities are found these should be informed to the client to prevent false positives and be reassuring. The Auditor should make documentation that eases the technical review of the Audit Manager. These may be included in the report if it is considered valuable to the client.
- The Auditor considers the audit finished, having made the report for the client. It gives the report to the Audit Manager for review, and the Audit Manager starts reviewing the audit.
- Requirements: It’s necessary to have the report, and also both the source code and a summary of the interaction with the client to give a better context of the audit.
- Dynamic: The communication should be two-way, which will allow the auditor to have a better understanding of the review. The focus of the review are the technical details.
- Results: The audit report in a pre-final form, open to client changes.
- The Audit Manager gives the report in its pre-final version to the Client Manager.
- The Client Manager delivers the report to the client, and determines the following points using the communication channel with the Auditor:
- Concerns that the client may have about the report delivered.
- How long the client is going to take to make the changes to the source code related to the vulnerabilities reported.
- If the report is pretended to be published or not, and when it is possible to do it.
- The client performs the changes in the code and shows them using the communication channel.
- The Auditor performs the changes necessary in the report in regards with the changes and petitions of the client.
- The Auditor delivers the final report on the communication channel, indirectly informing the Client Manager.
- The Client Manager finalizes the audit process informing the Audit Manager.
Initial Complexity Estimation
We will define the complexity estimating the amount of weeks that will take to make the audit for some properties of the contract, these are:
- Amount of code
- Amount of contracts deployed
We will estimate the amount of weeks with each of these properties and we’ll take the average which results in a final estimation. If some of these properties are out of the defined bounds of the table, it’s a good signal that it requires a custom manual estimation.
Amount of Code
This is the amount of effective code that is going to be audited. Documentation, comments or white spaces are not included. The Said values may be obtained with a tool like CLOC. The estimations are:
Amount of code Effort
- Under 350 SLOC 1 week
- Under 650 SLOC 2 weeks
- Under 900 SLOC 3 weeks
- Under 1200 SLOC 4 weeks
- Under 1600 SLOC 5 weeks
- Under 2000 SLOC 6 weeks
Amount of contracts deployed
This is the amount of contracts deployed by the project. This is NOT contract constructs like the ones found in Solidity, it includes only those that obtain a unique address in the blockchain.
Deployed contracts effort
- Under 2 contracts 1 week
- Under 3 contracts 2 weeks
- Under 4 contracts 3 weeks
- Under 5 contracts 4 weeks
- Under 6 contracts 5 weeks
- Under 7 contracts 6 weeks
Other modifiers
Some other modifiers may extend or shorten the estimate if they are found in the project. Examples are:
- Inline assembly
- Eternal Storage
- Heavy use of game theory
- State channels
- Over engineering
