Utilizing the Feedback Loop Properly to Find More Bugs

The feedback loop is something that we have heard about for a long time as security researchers/auditors.

It is the idea that you go back to the drawing board after an audit has been completed during contests or shadow audits to see what was missed and how to ensure you do not miss it again.

But today, I want to take it up a notch.

I want us to look at the feedback loop in a different light. I want us to understand how our brain works and see if we can take advantage of this to get better at what we do.

For the pros, this might not be for you as you have most likely already figured this out, but for the beginners, for those who have struggled to improve or are just joining the security space at a time like this where contests are almost non-existent but desire to grow, this is for you.

I have been doing a lot of thinking and studying lately, and during one of my research, I came across something in the book titled Atomic Habits. I am sure most of you have either heard of or have read this book.

But I am sure most of you read it passively and did not apply one of the key lessons that the book is built upon when talking about habit building. The feedback loop.

It has been proven that the brain essentially builds habits based on four steps: cue, craving, response and reward. A cue draws you in to something that you crave for, and you act in response to that thing and get a reward for it. That reward is now tied to the cue in your brain and the next time that cue is detected, the response time is shortened because your brain already knows what to do.

For someone entering a dark room, the cue would be that the room is dark. The craving would be that they desire to see. The response would be that they flipped the light switch on, and the reward would be that they can now see. You notice that the next time that person enters a dark room, their hand automatically goes to the light switch because it is something the brain does not need to think of again.

The same applies for fighters who have spent days training in the gym, or fire fighters when working to put out the fire from a burning building.

Now, how does this help us as auditors?

Think about what we have always called the feedback loop in this space. You finish an audit, the report comes out, you see what was missed, and you tell yourself you will remember it next time. That is technically a cue and a response, but there is no reward built into it anywhere, so your brain has no real reason to shorten anything. You read the miss, you feel the sting of it, and you move on, and the next time a similar pattern shows up, you are just as slow as you were before.

This is where I think we have been getting it wrong.

What if the goal is not to remember that you missed something, but to deliberately build the loop the way the brain naturally builds it for the light switch, so that catching a pattern eventually stops being something you have to consciously think about.

Here is what that could actually look like.

The cue would not be "I missed this bug." The cue would be the pattern itself, a specific kind of external call, a particular sequence of state changes, a type of access control gap that keeps showing up across different codebases.

Take a function that calls out to something returning two values, and only one of them gets used downstream. I caught this exact pattern in a past audit. The wrong one was used to handle a repayment when a stablecoin was involved, small mismatch, but the kind of thing that quietly drains a protocol if nobody catches it. The first time you see a pattern like that, you have to think about it. The hundredth time, across enough different codebases, you should not have to think anymore, you should just see it.

The craving would be the discomfort of knowing that pattern exists somewhere you have not checked yet.

The response would be going to look for it on purpose, instead of waiting for it to show up in your own work first.

The reward would be catching it, even in a codebase that has already been audited, even when nobody is paying you for it and nobody will ever know you found it.

That self-created reward is what tells your brain the cue is worth responding to faster the next time it shows up, the same way the hand eventually finds the light switch before the person has even thought about it.

I have not tested any of this in a rigorous way. I am writing it because I think it is worth trying, not because I already have results to show you.

If it works the way it is supposed to work for every other habit, the auditors who run this loop deliberately should start recognizing bug classes faster than the ones who read a report once and never go back to it.

That, I think, is the 100x people keep talking about without explaining it properly. It is just your response time getting shorter the more times you deliberately stack the loop.

Some of you are probably already thinking that AI handles this pattern matching for you now, and that building this kind of recognition manually is no longer worth the effort.

I do not think that is true.

AI tools, including the ones some of us are already experimenting with for auditing, are only as good as the questions the person behind them knows to ask. If you do not already recognize the pattern yourself, you will not know what to prompt the AI to look for, and you will not know when it has actually missed something important. The tool can speed up your response once you already know what you are looking for, but it cannot build that recognition for you. That part is still yours to train.

So where do you actually go to do this, especially now that contests are not exactly easy to come by.

What you need is a steady supply of patterns to use as cues, and a habit of rewarding yourself for catching them.

Solodit gives you a searchable archive of real findings sorted by vulnerability type, which is exactly the kind of cue supply this needs.

Code4rena, Sherlock, Cantina, and CodeHawks all have public archives of completed contests, so even though the contests themselves have slowed down, the reports are still sitting there for anyone willing to go through them and drill the patterns inside.

Rekt News and Immunefi's post mortems turn real exploits into cues you can study even though you were never part of the original audit.

DeFiHackLabs lets you reproduce real hacks locally, so the response is not just reading about what happened but actually rebuilding the attack with your own hands.

kadenzipfel's smart contract vulnerabilities repository on GitHub is a categorized list of bug patterns with real examples attached, useful if you want the cues organized for you before you start hunting on your own.

There are also independent researchers who keep public GitHub repos of their private and firm audit findings, and if you search "audits" along with a known researcher's handle, you will find more of these than you expect sitting there for anyone willing to drill through them.

Cyfrin Updraft is useful if you need the bug classes taught to you first, before you can even recognize them as cues at all.

A personal bug journal, even something as simple as a markdown file, gives you somewhere to log every pattern you have drilled and a reason to revisit it on a schedule, and the schedule probably matters as much as the logging itself.

Audit checklists, whether Cyfrin's or Trail of Bits', work as a built in set of cues you run through deliberately instead of relying on memory to surface them.

None of these tools build the habit for you, they just give you a constant supply of cues to work with. The habit still depends on you showing up enough times for the reward to actually wire itself into how your brain responds.

I do not know yet whether this works the way I think it does. But if you have been stuck, if you keep missing the same kinds of bugs over and over, I think it is at least worth trying before deciding you are just not cut out for this.

Let's find out together.