So you have a free weekend, and you're up to do some bounty hunting.
However, you quickly run into an issue; what code are you even going to look at? Here are some guidelines that you might use to select your next target:
Pick a target that interests you.
This might not matter to you, but to me, bounty hunting is a passion project. So I like to pick targets where I'll know I'll be enjoying learning about the technology.
rabbit hole - Remember the last time you got into a rabbit hole and learned a bunch of things about some random esoteric topic? You might be able to harness your inner rabbit 🐰 by picking a target that matches your interest.
flow - Interest and novelty are factors that get us in a flow state, which will allow you to be super productive.
Interest and motivation can be a super helpful tool to make you effective and enjoy the bounty hunting process!
Pick a target that matches or just exceeds your skill level.
In anything, including bounty hunting, it's important to pick a challenge that matches your skill or that just exceeds it.
flow - Having a challenge that pushes you to the limit of your current ability is critical for getting you in the flow state! A target that's too easy will be boring, while a target that's too difficult will lead to frustration.
learning - A challenge that's right at your skill level of just above is also what enables you to learn faster! Learn from gym bros and apply the approach of progressive overload: gradually push yourself towards more challenging targets.
motivation - Don't try to stick to something too difficult; you'll just wear yourself out.
Sometimes it makes sense to go for targets that do not have (a large) bounty awards or to go for a CTF challenge or two!
Pick a target that you can feasibly understand given the time available to you.
You should pick your targets based on how much time you have available. Trying to take on an incredibly complex system like geth (go Ethereum) in just one day probably won't amount to much.
Pick a target with complexity that matches your available time! Only have a few days? Pick some simple DeFi lego. Have you got an entire month or more available? Have a look at bridging software, maybe an L1 implementation, or one of the more complex DeFi protocols.
I often do a quick "scoping" session when I'm considering putting some time into reviewing a target. I skim the documentation and implementation and let that inform how much time I think I'd need to find something cool.
This scoping also depends on how familiar you are with the type of technology that your potential targets are implementing. Familiarity with the technology or approach will save you time and allow you to dive in deep right to the parts that matter!
A key thing to keep in mind for bounty hunting: You don't need to look at all the code! You're allowed to be efficient with your time and focus on the risky areas. If you don't find anything and feel like this target is pretty secure, don't feel like you have to stick to it! Nobody is keeping you from moving on!
Pick a target that makes your desired payout feasible.
If you're a professional bug hunter, meaning that bounty payouts are your primary source of income, then it is essential not to waste time.
I've found that there are roughly two ways to waste time:
- Hunting in projects whose code is super clean and secure where it's unlikely that you'll find anything.
- Hunting in projects that are unlikely to pay out (much) if you find something.
Finding Enough Bugs
I already mentioned that some quick scoping might be worth it in the previous section. Here I'll say it again, but for a different reason.
Look at two different aspects of the bounty programme:
- The offered bounty awards ( often relative to liquidity in the system ).
- Code quality ( after looking at code for a while, you get a spidey sense for code that probably has some vulnerabilities ).
These two factors allow you to get a sense of the expected payout if you review this code.
Avoiding Dishonest Projects
Some teams are awful at bounty programs. They might be unprofessional, slow, haggling, etc. They might just forget about a critical vulnerability report!
It's not always easy to avoid these projects, but there are a few things that you can do.
- Look for teams that don't just have big payouts for Critical vulnerabilities but adequately award mediums and lows.
- Look for projects that have shown quick response times and good bounty payouts.
- Submit your first bug as soon as you find it instead of continuing your review until you have several. This will allow you to test the project team's behaviour. Move on as quickly as possible if they don't behave honestly!
Pick a target that too many others haven't reviewed.
The idea behind this strategy is straightforward, by picking projects that have been looked at by fewer security people, you have a higher chance that there are still bugs for you to find!
New Bounty Programs - New bounty programs are launched all the time! These provide fresh hunting grounds where others haven't gone before. This can be very useful as your chances of finding a valid bug will decrease as more and more people have had a look at the code.
No Audit - Projects that haven't been audited will likely have some bugs in there for you to find! However, an un-audited project is a pretty big red flag that the team behind the project isn't willing to invest much in security. There is a chance that they won't pay out the promised bounty awards
Complex Systems - People have short attention spans, and skilled bounty hunters are in short supply. These factors have an interesting effect. Namely, a complex system will attract relatively few people, even though that same complexity makes it more likely that there are bugs for you to find!
Niche Systems - There are a lot of systems that use niche technologies and ideas. For example, there might be mechanisms involving cryptography, economics and game theory, or the system might implement novel consensus mechanisms. Each of these fields requires particular knowledge that not every bounty hunter has! Looking for targets that your specific experience gives you an edge for can be very effective!
Picking projects that have seen fewer reviews can be super effective. However, don't be too discouraged to go after projects that don't meet this criteria. You have a unique way of looking at code and can find things that others have missed. I know I have!
Still have trouble deciding which target to pick? Here are some (sometimes dumb) ways I've selected projects to target:
- Did this project do anything to contribute to the community or you?
- Do any of your friends work on this project?
- Did you just meet someone at a conference who boasted about their code, and you made a bet that you could find something and they would drink vodka shots, film it and put it on YouTube?
- Does this project have a cool logo, name or art?
- Just pick one at random. Analysis paralysis is real 😂.