Audit Process

Audit Process

When starting an audit, it is good to know when you are going to stop.

Set myself the goal of fully understanding the system to the point where I could reimplement it from scratch without being allowed a look at the original codebase. Not from remembering the code, but from having understood what the application is supposed to do. If you have examined a project that far and have not found a bug, the chances of finding one by continuing is low. However, if there is a bug in there, your chances of finding it with this method are high.

- Alexander Schlindwein

The audit process will be different based on if you are doing an audit on a bug bounty program, your own program, or have been hired either directly or working with an organization. However, the basic ideas of each of these steps should be considered for all audits.

1. Go through a pre-audit checklist with the project team

2. Read specification/documentation of the project to understand the requirements, design and architecture

3. Run fast automated tools such as linters or static analyzers to investigate common Solidity pitfalls or missing smart contract best-practices

4. Manual code analysis to understand business logic and detect vulnerabilities in it

5. Look over the layout to see if it matches best practice and to understand how it is laid out if not

6. Create a data flow diagram (Consider using tools to help with this such as: ThreatDragon, Etherscan, VS Code Solidity Auditor)

7. Run slower but more deeper automated tools such as symbolic checkers, fuzzers or formal verification analyzers which typically require formulation of properties/constraints beforehand, hand holding during the analyses and some post-run evaluation of their results

8. Create proof-of-concept attacks to validate any findings

9. Communicate the status with the project team and get clarification on business logic or threat model

10. Steps 1-6 are more cyclical in nature than check off and move on

11. Write report summarizing the above with details on findings and recommendations

12. Deliver the report to the project team and discuss findings, severity and potential fixes

13. Evaluate fixes from the project team and verify that they indeed removed or mitigated the vulnerabilities identified in findings

Note: some skip step two and go directly into step 3. This is because documentation can lead you astray because it is wrong or misleading; however, the code is the source of truth.

Layout

1. pragma directives

2. import directives

3. Structs/Enums/Contracts

   1. state variables

   2. events

   3. errors

   4. modifiers

   5. constructor

   6. functions

Where to Start

When presented with several contracts and hundreds of lines of code, it may be daunting to find a starting place for the manual audit or even to start reviewing the code. Consider starting with either the asset flow or the access control areas of the smart contract.