As both the importance of maintaining trust in the Web3 ecosystem and the complexity of smart contracts continue to grow, the holistic application of security practices is more vital than ever. If you’re a Web3 developer, don’t let securing your smart contracts start when you hand your code off to an auditor. Rather, think of security as an ongoing process that should be integrated into each phase of development.
Auditors perform an important role, but if you can walk through a basic self audit - a ‘pre-audit’ - before sending your contracts their way, you’ll not only avoid wasting the auditor’s time and your money, but also get a more thorough audit than you might have otherwise.
Let’s say you don’t do a pre-audit. When you send your code to the auditor, they will likely report vulnerabilities at either extreme: low hanging fruit and glaring, serious issues. An auditor may conclude their report here - digging deeper beyond this point could be wasted effort, as code changes made to mitigate low-hanging fruit could impact or invalidate deeper vulnerabilities, warranting a second audit.
This can result in overlooking hidden critical vulnerabilities that require a more theoretical or relational analysis to identify: the kinds of vulnerabilities that an auditor has more skills and time to find than you, the developer. You end up paying for the auditor’s time spent finding threats that you could have handled yourself, using this guide.
To get the true value of an audit is to challenge the auditor to find something deeper. Don’t waste your auditor's time with simple vulnerabilities; do a pre-audit.
Luckily, auditor and developer skillsets have significant overlap; learning how to conduct a basic smart contract audit won’t be far out of your wheelhouse as a Web3 developer. Where you’ll excel is at understanding the code, writing tests, and doing code review.
Where you’ll need to build new skills is for threat modeling and verifying assumptions. By following the steps below you can close the gap, becoming a better developer along the way. And don’t forget about OpSec, but we have some basics outlined further along to keep you secure there, as well.
Now let’s get into it. There are 4 steps to a self-audit: Design Review, Threat Modeling, Verification, and Mitigation.
Typically, the first step of a security audit is digesting the code and coming to understand how it functions. Since you’re the developer, you’re ahead of the game - no one knows your contracts better than you. Skip ahead to Step 2.
Begin by identifying what your actors, assets, and trust boundaries are.
Then, using a mix of tools and ideation, list all of the possible disaster situations you can think of (really let the anxiety overtake you 😉). It’s helpful to approach this brainstorm with a framework; the threat modeling methodology STRIDE is the most popular, and we’ll break it down below.
Spoofing: Could an attacker successfully impersonate another user or entity?
Tampering: Can a data asset be modified by an attacker without the system being aware, and thus trust the data as authentic?
Repudiation: Can actions be attributed to the users that performed them?
Information disclosure: Is it possible that confidential data could be leaked to unauthorized users?
Denial of service (DOS): Can an attacker prevent other users from using a component of the service?
Elevation of privilege: Could an attacker perform operations that they are not authorized to?
Walking through each threat type, list out all of the possible vulnerabilities you can identify - even ones you believe have some factor that negates the threat. The auditing process is there to challenge those assumptions, lowering your risk of being exploited as much as possible.
How could someone tamper with your data? How could your private keys be leaked? Explore these questions with a mix of approaches:
Next, you need to walk through your list of threats and determine which ones are exploitable. You do this through more manual code review and running tests to explore the ways that your theories could be true. When they are, you’ll need to prove the vulnerability and define how it can happen and how it can be verified.
Tools like Foundry and Tenderly can help you run tests like transaction simulations, unit tests, fuzzing, and debugging. The best thing about these tools? You don’t need to understand all of the principles behind the testing methods to leverage them.
Once you’ve proven something exploitable, the threat you identified is now confirmed to be a security risk, and needs to be mitigated.
It’s time to secure your code against the risks you’ve identified. And once that’s complete, though we’re nearing the end here, there’s a final, crucial piece to mitigation: the mitigation review.
The mitigation review is the post-audit audit, if you will. Similar to the software development lifecycle (SDLC), the security auditor follows a loop. Once you’ve secured your code against the risks you identified in the first audit, and every time you make a change to the code, it’s time to go back to Step 1 and check if your updates have created new vulnerabilities. It’s normal to follow this loop once or twice on the same smart contract audit until you’re not able to identify more risks.
If you’re a Web3 developer, you’re aware that there have been several high profile OpSec failures in Web3 already. An important component of building trust in the Web3 ecosystem is changing how you think of security, not as something that lives in the auditor’s domain but as a practice that should be applied holistically as a smart contract is developed.
There are a few basic OpSec principals that should be followed as a default:
If you’re working on a team of developers, it’s also worth assigning one person as your security champion. Even if they can dedicate just 5% of their time to thinking about security, that can make a huge impact on your organization. If you’re working alone, take up the mantle yourself, dedicating that same 5% to security hygiene.
Using Audit Wizard, you can walk through the essential steps for auditing smart contracts, from design review all the way to mitigation. We’ve gathered all of the tools you’ll need and made them easily digestible for Web3 developers - it’s the platform for the lazy auditor (a term of high esteem). As our CEO Joe Van Loon put it, “Audit Wizard was born from [his] dream as an auditor, wanting to do the least work [he] could.”
Besides the more obvious time saving and quality of life aspects of Audit Wizard, the platform is specifically beneficial to Web3 developers who are self-auditing because it makes complex, sometimes intimidating methodologies like threat modeling and security testing accessible to people without a security background.
Upload your first smart contract into Audit Wizard for free and get started with an audit. While you’re at it, join our Discord; we love answering questions and offering support to our users. Let us know how your first self-audit goes!
If you want to learn more about security best practices and smart contract auditing for Web3 developers, check out this recording of our CEO’s talk at ETHDenver.