Recently @HatsFinance on hosted a Twitter Space titled "Becoming a Security Researcher". It was extremely informative and came in at 1 hour and 45 minutes, so I figured I'd publish some of my notes from the space for those who may not have gotten the chance to listen to the whole thing. These notes are not comprehensive and contain some of my own thoughts. The Twitter Space should be available for listening at the link above, but if it gets deleted for whatever reason, I've gone ahead and backed it up and it can be found in my Telegram server with the name "Becoming a Security Researcher - HatsFinance".

If you'd like to keep up to date with my posts feel free to follow me on Twitter, and also check out the list of web3 security related accounts that I maintain. In the case that there is any info I missed or got wrong, please reach out to me and I'll correct it right away! Here is a landing page with other ways of connecting to me.

In the space there was:

• @RealJohnnyTime

• @xb0g0

• @dethSCA

• @nmirchev8

• @krikoeth

• @0x_xindaquil98

• @HatsFinance

Prior to working in web3 security a lot of the individuals took different paths to reach where they are now. Some worked in traditional web2 security doing anything from penetration testing to blue teaming, while others worked as blockchain and backend engineers. Others don't even have degrees related to the fields they are currently working in. There isn't one "correct" path to breaking into web3 security, it's just a persistent journey forwards. Some of these progressions weren't quick either, with one of the speakers working in blockchain engineering for three years before making the switch over to security. For example, xb0g0 went from being a blockchain engineer to actively competing in contests in the span of nine months, two of which were dedicated to diving deeper into theory.

Specific backgrounds can aid people getting into security research though. Take for example a previous solidity developer vs. a DeFi financial analyst. The developer may have an easier time finding bugs involving program logic or patterns while the analyst may realize that a protocol is mishandling funds or performing incorrect math when doing calculations. Everyone is different, but any background can be leveraged.

Being a security researcher was summarized as someone who has the ethics and ability to put in the required work to secure their target. This is extremely important especially in web3 to the large amount of money involved with the platforms and protocols being tested. You essentially need to be a very responsible person at your core to even qualify as a security researcher, otherwise the definition surrounding what you do may stray into grayer areas.

Along with that, you always need to be staying ahead of the curve and constantly learning. New protocols, new patterns, new languages, and new bugs are introduced everyday, and part of a security researcher's job is to be deeply knowledgable about these items. On top of that, if you are competing, you need to be constantly evolving to stay ahead of the competition and stay profitable. This can be done many different ways, but a lot of the recommendations were to read articles, reports, and take extra training courses. Always be learning and iterating, even when participating in things like contests. If you missed a finding, ask yourself why, and adjust your methodology to ensure it doesn't happen again.

Discipline and patience are two other attributes that are required. Being a researcher isn't easy; it can involve long days with no bugs found, which can then easily demoralize a person. But someone who can push through those rough days and continue to learn and improve is extremely valuable to the web3 community because at the end of the day their job is to secure funds, contracts, and code, which in turn secures the users. Learning the technical things is also the easy part of auditing, but getting through the hard moments is where a lot of people will fail.

As a warning to new researchers though, you may not be able to 100% know that the codebase you looked at is secure. We are all humans, we make mistakes, things get overlooked, and there isn't always time to go through everything line-by-line. Contests can be time limited, and some private audits are rushed just to get a checkbox on a form. No one is perfect, and that's okay as long as you're doing your best.

The transition from web2 to web3 is a lot easier than it has been made out to be. Despite being the next iteration of the web, web3's building blocks rely on web1/web2. This means security, engineering, code, languages, and theory were all previously created to utilized to lay the foundations of web3. This is also where some developers and security researchers get in trouble, because with web3 coming to the forefront a lot of concepts were either skipped over or thrown out that were already learned in previous iterations of the web, ending up with individuals and companies needing to relearn hard lessons that had already been taught in the first place.

The hacker's mindset is needed if wanting to get into web3 security (or any form of cybersecurity). Despite what some people say, it can indeed be learned, and revolves mostly around not giving up easily and constantly asking edge-case questions. Some of these questions one can ask themselves when examining something like code can be as simple as:

• Why did the developer implement it this way?

• What happens if I pass this disallowed input in?

• Why did this error occur?

• Where does this behavior originate?

• What does the documentation say I should be able to and shouldn't be able to do?

There's so many more questions that can be asked when checking out code and applications though, these are things that are just developed with time and experience. You can read a blurb about the "Hacker Mindset" from HackTheBox.

The other skill needed is to be able to compile and retain all of the learning and knowledge you've gained into an actionable methodology. This means having good note taking and organizational skills while you're learning, then actually using the skills you learn to read and understand reports, then compete in contests. From there it's a feedback cycle that you need to keep iterating through, getting better and better with each new experience. Implementation and usage of your new skills is the biggest hurdle to cross, but once you finally do, everything will start getting easier from there.

Everyone is different, so this timeline can vary highly depending on what you have going on in your life. Most of the speakers made the switch over to web3 security over the course of a year in order to reach a kind of "full-time" status, where the first two to four months were focused on training in order to then participate in contests. During this transitionary period, most of them had full-time jobs they were working while doing web3 security on the side. The first year, and especially the first five competitions, don't worry yourself with the money you are bringing in. Next to nobody starts out in web3 security making $20,000 per contest, and a lot are lucky to get any rewards at all with the first ones they participate in.

This varied due to the different timeframes each researcher came into web3 security at. I'll later release a much more thorough list with a well-reasoned order and extra topics to dig into, but I here I wanted to put one out that is dead simple and easy to follow, while pulling from the experiences of the speakers in the space.

1. Read the book "Mastering Ethereum" by Andreas Antonopoulos and Gavin Wood.

2. Complete all of courses from Cyfrin Updraft.

3. Complete Ethernaut.

4. Complete Damn Vulnerable DeFi.

5. Read five audit reports and develop your own methodology.

6. Perform five shadow audits. (Redo an audit of a previously reported on codebase)

7. Participate in contests on platforms like CodeHawks & code4rena. Preferably start out with a "First Flight" from CodeHawks.

Extra reading on things like tokenomics, previous hacks, and general DeFi finance are always recommended, but not immediately needed. Web3 security is very widespread and can cover a huge amount of topics. There are also paid courses available, but with all of the free content available online there's not really a huge reason to pay for them unless you want a shortcut and to have the resources/teachings directly given to you.

There are absolutely tons of more resources that could be added in here to enhance a person's skills, but you don't want to get stuck in tutorial hell. The whole point of this is to get you plugged in and participating. Getting your hands dirty is the quickest way to success, so you need to actively build a dApp, interact with smart contracts, etc.

Just reading the standards and theory isn't going to be enough. You need to at minimum have basic experience in solidity development to begin having successes in the web3 security space.

Go for small codebases with small-to-medium rewards. It might be tempting at first to look at those potentially huge rewards on large codebases and want to chase after them, but that is a recipe for disaster for newbies. Those codebases are complex and you'll end up burning yourself out in the end.

Start with protocols you're familiar with as well. If you have in-depth experience implementing NFTs and building a dApp or contract that handles them, start out auditing one that's related to them. Your level of familiarity with what the code and documentation is intended for can directly help how deeply you understand it, which could then lead to a higher number of findings.

Knowing Solidity and the basics of each vulnerability is only the beginning of the journey (as mentioned previously). Knowing the economics, logic, processes, and more that make the ecosystem tick are just as important. To fully understand how to break something, you need to understand how it works in the first place. Vulnerabilities can still be nabbed without this, but with this extra knowledge and experience it just makes you that much of a better auditor.

The book "Mastering Ethereum" was already mentioned above, but to get an even deeper dive into the world of decentralized finance try checking out the following books in order:

• How to DeFi (Beginner)

• How to DeFi (Advanced)

• Uniswap V3 Development Book

Once you start becoming more comfortable with competitions and auditing smaller codebases you'll eventually want to start hitting the heavier targets. Bytes032 posted on Twitter an assumed pace of 150 SLOC (source lines of code) per day, and I think this is important to highlight in order to give people an idea of the realistic pace audits can move at. You don't need to try and blow through 2000+ SLOC codebases in a day or two, and you won't fully understand them and their underlying logic and economics if you try to. Make sure to take your time!

Bbl4de.xyz had this to say about the above tweet:

I was reviewing my bookmarks and I found this post. Until now, I've been doing web3sec part time and I always felt like I'm progressing with the SLOC too slowly at the same time missing many findings... This post reminded me how wrong I was - 150 SLOC/day, it's really not that much, especially with moderate complexity. I'm naturally a very "fast" person in terms of completing tasks, mostly because I work until I finish. With audits that's impossible and that's why it's the thing I'm actively working on.

Conclusion - to take it even slower than I do now. I'm convinced that's one of the main reasons why I miss bugs.

When you're looking at a new codebase you need to get into the head of the developers. This means reading and understanding not only their code, but their documentation as well. Again, ask lots of questions:

• What were they thinking about when they wrote this function in a specific way?

• Why is the overall system designed this way?

• Do they break convention anywhere? And if so, why?

Trying to find edge-cases and tracking state changes is now your full-time job. At this point being familiar with all of the potential attack vectors is required so that you can notice them as they appear. It could be all to easy to stumble over a valid bug and not even know it.

There are more protocols and languages being introduced to web3 every day, and this isn't even for L1s. Rust, Sway, Vyper, Go, Cairo, and more are all being introduced and utilized across ecosystems. The more you know, the more opportunities you have to audit. Start out with the basics when learning though, focus on Ethereum and Solidity, and the foundational concepts that underpin the ecosystem. An automated market maker's logic will be handled similarly in a different language, just as an ERC-20 token will be.

At some point in a security researcher's career they may feel like they've been pigeonholed into specific niches of vulnerabilities or that their skills have plateaued. A potentially great remedy to this is working with a team. Find teammates whose incentives align with yours but have specialties other than yours and learn from them. Even the act of having someone else to bounce ideas off of can push you further than you might have on your own.

There's so much value in being a part of a good team, it almost will always beat out the experience of a solo-auditor. Teams that help each other, mesh well, and continue to compete and progress have a much easier time getting ahead.

Engage with the communities across all platforms! Maintain a presence, create the bare minimum of a self-brand, and make it as easy as possible for opportunities to find you. Be friendly, but also genuine at the same time, and always keep an open mind. There are TONS of communities across the web3 space, fragmented across multiple social platforms. I'd say at minimum maintain the following accounts:

• Twitter

• Discord

• Telegram

There are so many communities it would make your head spin, so my personal advice is to pick a few that you think you could learn a lot from and become deeply involved in them. Make friends, learn new things, and enjoy the experience! Don't be afraid to politely reach out to individuals either, the worst they can say is no.

In addition to this, keep a portfolio. That can be something like a GitHub or a blog. It can showcase your notes, findings, reports, and anything else you want to show off. You never know who may come looking.

Here's a list of the communities that I'm aware of on Discord that are either focused on learning web3 in general, or have a focus on web3 security:

• Secureum

• DeFiHackLabs

• Cyfrin

• Alchemy University

• Buidl Guidl

• Hats

• Sherlock

• LearnWeb3

• Defenders Den

I hope that my notes on this Twitter space can be at least somewhat helpful to someone else, as just listening to it was extremely helpful to me! Shoutout to Hats for hosting it, and for all of the awesome researchers that participated in it and passed along their hard-earned knowledge. You're all legends 🙌