The 10 rules to be successful in your bug bounty career

Hello everyone,

My name is Ariel Garcia, I’m from Buenos Aires, Argentina. I have been doing bug bounty since 2017, and I have 7+ years of experience doing pentesting full time. For those who don’t know me, I have been working at HackerOne since June, 2019. I’m part of the community team and I have been working with hackers from all different experience levels, a lot of different nationalities, backgrounds and skills. Yes, that guy in the middle of a mountain in Vancouver with a HackerOne hoodie it’s me. Cool pic, right?

One of the most common questions I have seen since I started is “how do I get started in bug bounties’’. Of course, a lot of people ask that from a technical perspective, which the webs3c community will help with. But what I have noticed is that not a lot of people share recommendations related to soft skills or how to deal with the pressure, frustration, and all the different components that the bug bounty life comes with, I think these recommendations might be as important as the technical side of things, not only for the beginning of your career, but for your entire process while bug bounty hunting.

Before moving forward, I would like to make sure everyone understands that this post shares my views only, and not the views of my employer.

So, having said that, here are what I call “The 10 rules to be successful in your bug bounty career”. Yes, I just made that title up, but I think it’s pretty cool right? and even if you won’t find technical content in this post, I hope you will find these recommendations useful and will help you get started and/or improve your bug bounty career.

Rule #1: Always be respectful and professional

Being professional is one of the most important things in this career. You need to understand that behind the screen there is another human being. Always make sure to respect the triagers, respect the program staff, respect the support teams and respect anyone you are interacting with. I have read many many tweets, blog posts, and emails of people frustrated, calling Bug bounty a scam, and being disrespectful to others online. Let me say that I understand the frustration. I have been there, I have had reports that were not paid in the past (even if those should have) but please understand that going on twitter, or youtube or any forum talking badly about programs, triagers and platforms won’t help you at all. Your peers and other bug bounty hunters won’t see that as something good, most of the people reading that will see it as negative. At the end of the day, it won’t help you in your professional career as a whole, not just your bug bounty career alone. Also, platforms have code of conduct and track in-platform behavior. Before being disrespectful to others, think twice. Remember there is a human being on the other side and is trying to help you and be nice to each-other. There is always a way to ask the same questions being polite and professional and it will make you look way better, and will help you build your reputation.

Rule #2: The 24 hour rule

Very related to Rule #1. If you receive a response that was not satisfactory for you, and you are angry or frustrated about it, don’t jump right away to answer that. Take your time, maybe even have some sleep before responding to that. Wait 24 hours and think about what you are going to say and avoid responding angry or in the wrong state of mind. Taking the time will help you see things with a different and fresh perspective and will allow you to be more professional and provide better answers. If needed, do more research or gather more information about the bug or the POC or whatever you are trying to prove, and then respond. Trust me, this will help you a lot.

Rule #3: Bugs Everywhere

One of the most common things I hear from people starting in bug bounty is to go and ask for private invites without even trying to hack on public programs. Many hackers have the incorrect perception that public programs, because of the fact that they are open to everyone, don’t have bugs to be found. Well, let me tell you this, that’s simply not true. There are bugs everywhere, in public programs, in private programs, in challenges, everywhere. Vulnerability disclosure programs also have a lot of bugs to be found, VDPs are the bug bounty programs that don’t offer bounties, which might be a good opportunity to learn in the first stages of your career. What all types of programs have in common is that you just need to sit in the chair and invest the time. Have you ever thought about the amount of lines of code that a huge company like Yahoo, Alibaba, Epic Games and others push daily? Thousands for sure! Each submission might be adding a new bug to their codebase and is for you to find that bug. If you can get a private invite, then it is great, but don’t get discouraged if you don’t. Pick a public program and spend time on it, there are many amazing public programs to hack and I can promise you will find bugs if you invest time and try hard enough.

Rule #4: Never give a bounty for granted

My former boss used to say very often, “Key of frustrations is unmet expectations”. And even if I heard that so many times to a point that was a little bit annoying, I consider that to be very true. Frustration comes when you are expecting something and you don’t get it. Bug bounty is like that, the sooner you understand it, the better. Never give a bounty for granted, never think about the money you are receiving after submitting a bug. never plan what you are going to buy with that, or how much reputation you will get, or anything. There is always a chance your report can change status or things can’t go as planned, managing expectations will help a lot to avoid frustration. Sometimes reports can be marked as duplicate or info even after a triage status, it’s weird, but sometimes it might happen. Sometimes triage validates your bug and the program decreases the severity, these are things that could happen, and many times happen with justification. Sometimes what you think it has massive impact for a customer, might not be the case, since they might have circumventing controls or protections around it. Understand that the bounty is yours when it’s paid, otherwise you don’t have a bounty. I know it might be hard, especially if you are a little bit anxious, but keep this in mind and frustrations will be less frequent.

Rule #5: Keep moving forward

After reporting something don’t wait for the response, the triage status, or the bounty, just move on to the next bug. When you find a bug and report that, keep the adrenaline going, keep looking for more bugs, don’t stop being satisfied with one bug (whenever time and energy allows it of course) and don’t stop after a submission waiting for the triage or for an update, just keep moving forward to the next bug. It’s very important to avoid asking for updates consistently or frequently, give triagers a couple of days to communicate with the program and come back. Or give some days to the program to figure out things, some companies are insanely huge and your bug might be affecting a different team, department, and sometimes even a team can be in a different country. Understand this and give them some time to work while you keep hunting for the next bug. Of course, if multiple days passed by and you got no response, then politely ask for an update to see if there are any news, but don’t get too noisy, since this will just probably waste triager’s time and sometimes program members’ time, which won’t help.

Rule #6: RTFM

Even if many policy pages look the same, it’s important to read those very carefully. The policy has important details, Scopes, limitations, and requirements from the programs, even the safe harbor, this is what makes sure you are safe while hacking on these programs. Don’t hack on things out of scope, and if you do, understand that the program might not accept the bug, might not pay for it, or even worse, you might get in trouble, receiving a not applicable report will hurt your stats, but some programs might not like it and might get mad. If you find something out of scope and want to report it, understand the risk, and never expect a bounty, otherwise, you will get disappointed very often. Furthermore, after you sign up on HackerOne you need to understand the terms and conditions, the code of conduct, and the rules. Read that in hackerone.com/policies. Sometimes, hackers think they can disclose bugs or information about vulnerabilities because they are mad or the program doesn’t want to fix something they have reported. Well, unfortunately that’s not real and you agreed on not doing it when you submitted that report to the program, so understand the guidelines and terms and avoid even mentioning that you are going to make a report public, since you agreed not to.

Rule #7: POCs and CVSS are VERY important

One of the best things you can do to improve your reports is to learn how to calculate CVSS score properly. Make sure you understand it fully and feel comfortable arguing (politely) a disagreement in the CVSS score with a triager or a program. Avoid marking everything you submit as critical, won’t help you and you might lose some credibility, but learn the CVSS score definitions and understand how to calculate it, and how to demonstrate the severity of your bug based on the CVSS score you calculated. Let’s face it, CVSS isn’t perfect, some points are a little bit ambiguous, but do your best and try to follow that as much as possible, providing the appropriate justification for setting the severity as you did. Always share your point of view and explain your reasoning why you think it is different, always having in mind rule #1. Furthermore, consider that some programs will use their own standardization for severity like Github 2 or Shopify 2, in those cases understand their guidelines and know how they work in advance. Also, the POC is extremely important. Avoid the one liner kind of report and explain how to reproduce your bug even if the bug seems to be obvious in your mind. Sometimes the software, OS, or environment you are using is not the same being used by the triager or the program, this might cause different outcomes. Make sure you detail all your steps, describe which accounts and permissions you were using and even describe your browser version, if that might be impacting something, do this and your reports will be easier to replicate and faster to triage.

Rule #8: The race is against yourself

I have heard many times that hackers feel bug bounty is a competition, that leaderboards are unreachable for them, and a lot of other things. Gamification is a nice component and works for a lot of people. Many feel motivated while competing with others and if that’s something you find motivating, well, go for it. But if not, completely ignore it! The race is against yourself, ignore all leaderboards, compare to yourself, how many bugs or how much in bounties you got last week, month, or year? Set up your own goals and try to overcome yourself and your results. Set new goals every time and try to reach those, and if you don’t, adjust those, maybe you were too optimistic, but don’t get discouraged, you will reach those eventually. Keep working and you will achieve it.

Rule #9: Always keep learning and improving

You never stop learning, actually, I would say that you forget things you learn, so you always need to keep learning new stuff and also refreshing the old knowledge. Try to be up to date with new technologies, new vulnerabilities, and new types of exploits. Learn from other disclosed reports in Hacktivity 5, learn from twitter following good hackers, understand what can be reported and what can’t be reported from others’ examples. Do trainings, get certified, but always keep hacking and improving your skills. If ever in doubt about a bug if that should be reported or not, check hacktivity and other disclosed reports, has your finding been awarded many times in the past? If not, avoid reporting non impactful stuff or things with “Theoretical” impact, you need to demonstrate impact to get paid and you don’t want your stats to get affected. If you are in doubt and want to risk it, it’s ok, maybe a program will consider your bug without impact as an improvement and will pay, but understand that this situation would be very rare, and that this doesn’t mean every program will reward you for that (and you might be risking your stats in the process). If they decide not to pay for the bug, understand that you took the risk, accept it and always remember about rules #1, #2 and #4 and keep moving forward (as stated in rule #5).

Rule #10: Moving on

Each hacker has a favorite program or programs. Some hackers hack only in one program for their entire career. Some others hack on every single program out there. I will tell you, It’s hard to find YOUR program, with the scope you like, the bounties you want and the interaction you expect. Eventually, you will find it, but while you don’t, If you disagree with a program and you are not happy with the results of a report or a bounty in that program, stop hacking on them, move on to a different program, keep looking for what is yet to become your favorite program to hack. No matter how many times this happens, move on until you find the programs you like and you feel comfortable working on. Is the best you can do for yourself and your time.

And that’s a wrap. I hope you had time to read these carefully and hopefully you will find these rules useful.

I wish you the best in your Hacker Journey, and Happy hacking!