Auditing smart contracts for the first time can feel daunting. Beginners unsure of where to start can benefit from following the process of an experienced professional. As you gain experience, you’ll naturally develop your own methodology. For now, draw inspiration from established auditors in the field.

Read on to see how different blockchain security experts approach auditing smart contracts.

Mudit Gupta

Mudit Gupta is a blockchain security researcher and current CISO at Polygon. He outlined his approach for auditing smart contracts during a YouTube live stream. I highly recommend watching it!

• Read about the project to get an idea of what the smart contracts are meant to do. Glance over all the resources about the project that were made available to you.
• Create a threat model and make a list of theoretical attack vectors including all common pitfalls and past exploit techniques.
• Look at places that can do value exchange. Especially functions like transfer, transferFrom, send, call, delegatecall, and selfdestruct. Walk backward from them to ensure they are secured properly.
• Do a line-by-line review of the contracts.
• Do another review from the perspective of every actor in your threat model.
• Run tools like slither and review their output.
• Glance over the test cases and code coverage.

Tincho

Tincho is a Web3 security professional and former lead smart contract auditor at OpenZeppelin! He founded The Red Guild and is the creator of Damn Vulnerable DeFi, a popular CTF that reinforces decentralized finance exploits. These are notes on his approach how to perform security assessments for smart contracts.

“I don’t have a super formal auditing process. I will just show you briefly some things that I do…” - Tincho

Read the Documentation

Reading the documentation will help you understand the protocol and the goals of the project.

Tools and Frameworks

Use what you are most comfortable with. For Tincho, these are some of the tools and frameworks he utilizes.

• VSCodium: Free Visual Studio Code clone without any of the Microsoft telemetry gathering
• Foundry: Framework for testing code, fuzzing, QA, and more! Tests are written in Solidity.
• CLOC: simple command line tool to count the number of source lines of code for a codebase
• Solidity Metric: Another tool for providing metrics about a Solidity codebase

Audit Organization

Tincho uses cloc and Solidity Metrics to organize the codebase by complexity in order to systematically perform the audit. He recommends uploading the results to a Notion table and audit the least complex files first (or least lines of code).

While reading through the code, he will leave comments, questions, and notes to himself. They look similar to this:

// ? - a question to answer later
// q - alternative way to ask a question
// ! - something important or a security issue
// e - explaining something in his own words

Tincho also creates a simple notes.md file to keep track of notes while auditing. He prefers this over installing additional note taking plugins.

Test Often

Note sure if a function is actually working as intended? Write a quick test in Foundry!

Communicate

Keep an open line of communication with the project developers. They will have a better understanding of the codebase and can answer any questions you may have.

Know when to stop

It is difficult to know when a security assessment is fully complete. Are there more bugs to be found? Should I reread that function again?

Security audits are not perfect and will not always catch every single bug or vulnerability. Do your best!

Conclusion

Today we auditing advice from two established security professionals. Finding an auditing methodology you are comfortable with takes time, practice and patience. If you are just started your web3 security journey, it’s not a bad idea to follow guidelines from other security researchers.

~ happy hacking!