Beyond “Just Read the Code”: Auditing Strategies & Tactics

DeFi Security Summit at Devconnect Argentina 2025 · November 2025 · 5:01

Nisedo, a blockchain security engineer at Trail of Bits, rejects the idea that top auditors simply read the code and breaks down what they actually do. The talk lays out auditing strategies and tactics, including how to find bugs that other reviewers miss, and compares the craft to elite athletes whose skill is invisible in a one-line summary.

Speakers

Topics

From DeFi Security Summit at Devconnect Argentina 2025, hosted by DeFi Security Summit.

Transcript

else. To go what I call beyond just reading the code. Um because if you've been in our industry I think I will go Sorry for the delay. Okay. Going over. Because I think if you've been in our industry long enough, uh you might have seen this meme quite a few times. Uh this is usually what you will get when you just starting out and you're asking, "Okay, uh how should I do uh to tackle this complex code base? How should I um go uh

how have you find these very interesting bugs?" Um this meme, as funny as it gets, it's quite far from the truth. Uh it's really simplistic and uh in my opinion, it doesn't help that much. Because if reading the code was the only thing we should be doing, uh we will all be finding the best bugs, we will all be finding all the bugs, we will all be understanding the most complex code bases at the same path. So, I've been wondering quite a while um and asking myself and some of the top auditors out there, how do they do and what do they do to find the best bugs that I'm not doing uh by just reading the code?

And I've been gathering most of these resources, their answers, and everything that I could find online on that topic in a repo that is publicly available, which is called awesome audit methodologies. And for the purpose of this talk, I picked one symbol simple but very, very effective technique that I will be presenting um in two different ways that you can implement yourself in your audit process. The first one, very simple, you go over every single line of code of the code you are trying to um go through and you translate every every single line of code as a plain English comment explaining in a very simple way, not using technical jargon, and this will force you to take a step back and understand what is the code doing, why

is it doing it, uh what were the development assumption while doing it, and this is the kind of thing you might not think at first pass um on the code you are reading if you are just like pouring reading through it and passively reading. This, of course, uh was a very simple code snippet. Uh this might not be the most relevant to do it on because it takes some time, but trust me that on complex flows uh this tedious process is very, very helpful. The second one is by rubber ducky, so it's kind of the same technique as the first one, but it's different way to implement it. Basically, um first step you get a rubber duck. Amazon has plenty of them. You put it on your desk. You find a contract, a function, a piece of code, whatever, uh that you

want to understand deeply. You read it, and then you go through the tedious process of explaining it out loud to the duck. The out loud part is very, very important because there is quite a few studies that prove explaining things out loud are way more effective than um uh writing them or explaining them in in your head. Was it only me? Am I the lucky guy of the day? I think it's dying.

Or the next speaker will hate me. You can you can pick it up otherwise. How much time could I take? I'm going to make some enemies today. Uh sorry for the other. I was saying explaining thing explaining things out loud is way more effective than writing them down or explaining it in your head. And by By through this tedious process, you will naturally find gaps in your understanding. You will struggle to explain some very complex thing. Uh you will be using the technical jargon, which you should not, to make this technique effective. And so, then you will have to revisit the

code to basically resolve these gaps. This is very effective, and if it usually takes you five, 10 passes, whatever, to go over a piece of code, this might help you get it to the same deeper or deeper level of understanding way quicker. This process um um makes uh use of what we call metacognition, which is the process of thinking about our own thought. And by doing so, you will have to take a step down, as I was saying earlier. It will make you slow down. It It will make you think about all the small thing that you think you did understood, but you didn't understand quite enough.

Thank you. That's all. If you want to see all the other 50-ish resources that I've been gathering on the auditory methodology, you might have the link here. And uh if you have any questions, please reach out uh after the talk. >> Thank you so much. >> You're welcome. >> Thanks.