“Damn Vulnerable DeFi” Creator Teaches You How To Audit
We meet up with Tincho, Damn Vulnerable DeFi creator and previous Openzeppelin lead auditor, on what his exact audit process looks like end-to-end. We do a mock audit of ENS to show you how to do it.
We had the pleasure of interviewing Tincho on his exact audit process he uses to make web3 more secure.
You can watch the summary video here:
Additionally, if you’d like to watch the full interview, you can find that on my YouTube as well.
Tincho broke down his process for us to get some context. However, one thing he was adamant about was the following:
There is no silver bullet for auditing.
This was something that was repeated throughout our interview. Every auditor is going to learn to approach problems differently, and his methodology might not be the same as one you might invoke. Find what works for you, and go to town!
But here is the summary of how Tincho approaches his audits. We did a mock audit of the ENS protocol to showcase exactly the steps Tincho takes to do an audit.
1. Get Context
Read the documentation.
Read. The. Docs.
Before he even starts looking at code, he makes sure to get an understanding of what the protocol is supposed to do. 80% of all bugs and exploits come from business logic exploits, so if you don’t understand the business logic of the code, it will be impossible to find exploits!
He may also read reports on previous audits, get familiar with similar protocols, etc. Anything to prime himself for the security journey he is about to take.
2. Bring your tools
The next step he takes is to download the code to his local environment and bring his tools. For working with ENS, Tincho git-cloned the GitHub repo and then created a foundry project. ENS is a hardhat-based project, but Tincho has been working with Foundry recently due to its speed, so he spun up a small Foundry project where he would run little tests against the repo.
3. Get your scope
The next step Tincho takes is to use either cloc or solidity metrics to get the scope of the project he is going to audit, and place them into a sheets/excel folder organized by size.
On the right, he will make a status column so he can keep track of what he has audited. He usually starts from the least complex or the “little legos” and works his way up. Understanding the smaller pieces gives him context on how everything fits together when he gets to the more complex contracts.
Additionally, if your audit calls for only reading specific contracts, you may remove them from your sheet, so you know what you shouldn’t spend your time on. A file like this is especially important when working with teams, as you can know what everyone is working on.
4. Start taking notes on/in the code
Now that you know what the code is doing, you should constantly be thinking, “how can I break this?” or “does this do what it should be doing?”. Tincho will leave comments right in the code to let him know he was there.
Additionally, he has a file that he uses just to dump ideas, thoughts, and keep track of any issues/findings he has.
5. Remember, audits are time-boxed
It’s very easy to fall deep down the rabbit hole on something, and you can always re-read a line of code and re-validate something works the way it can. But you’ll need to remember to come up for air.
6. Keep a line of communication with the developers
Developers have worked on this code for much longer than you have and you ever will have. They have more context than you ever will have. Use the developers who wrote the code to your advantage and ask them questions.
Additionally, if you’re a developer and you’re getting an audit, remember, ultimately, you are responsible for your code, so making yourself available to the auditor will make their lives much easier.
7. Audit a lot
The best way to start having a “feel” for vulnerabilities is to do a lot of audits, read audit reports, read post-mortems, and digest as much security-related information as you can.
Every auditor on the planet, at some point, will miss something. Don’t let that stop you. Always focus on doing the best job that you can, and never become content with your skill level.
Always be growing and learning.
As they say:
Repetition is the mother of skill.
Some of my favorite resources:
8. Take a lot of time to write your reports
If you find a million vulnerabilities, but you don’t communicate them effectively, you essentially didn’t find any vulnerabilities.
An audit is more than just the report; you are responsible for keeping your client safe and teaching them how to be more secure with their code. So make sure you take the time to write reports that articulate issues so that they can learn.
9. Remember, an audit is more than the report
I finished the call by asking, “What happens if you audit a contract, and the protocol gets hacked, and you end up on rekt?”.
A question a lot of auditors have that makes them nervous. He responded by saying:
- An audit is more than whether or not you find all the bugs
- An audit should provide value regardless
- Every auditor on the planet who is worth their salt doesn't have a perfect track record
When auditing, you should be not only finding bugs but:
- Teaching best practices
- Helping them understand attack vectors
- Showing effective testing practices
It’s your job to level up the client as a group and find bugs. And no matter how amazing of an auditor you are, sometimes a protocol will get hacked. You need to take accountability, learn why you made this mistake, and learn and grow from it. Ideally, this doesn’t happen, but when it does, do your best to help the client with any mitigation.
Summary
There is no one silver bullet to auditing, but hopefully, seeing behind the curtain gives you more context as to what goes on in an audit and how you can start your journey!
😸😸Follow Patrick!😸😸
Book a smart contract audit: Cyfrin
