Ten Rules to be Successful in Your Bug Bounty Career

Bug bounty life comes with hidden pressures and common frustrations that require soft skills to navigate - which isn't something people often talk about. So, I've come up with "10 rules to be successful in your bounty career.

My name is Ariel Garcia, I’m a Sr. Manager at HackerOne’s community team, and I have been working here since May 2019. 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. During my time at HackerOne, I have been working with hackers from all different experience levels, a lot of different nationalities, backgrounds and skills.

One of the most common questions I have seen since I started at HackerOne  is “how do I get started in bug bounties." Of course, a lot of people are asking for a technical perspective. 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.

Recently, Tarek Bouali pinged me to help with the Webs3c community, a community sharing content, write ups and blog posts about bug bounty, infosec and cyber security (Go check it out!).  Well, Tarek’s outreach was a great opportunity to dive a little deeper in soft skills, which is not something you read every day. I think it’s as important as the technical side of things, you will need both to be successful, not only at the beginning of your career, but for your entire process while bug bounty hunting. 

So, with that in mind I created my version of “The 10 rules to be successful in your bug bounty career." This is basically my opinion and recommendations about how to behave, what to do and what you shouldn’t do in your day to day, in order to have a successful career in bug bounties. Even if you won’t find technical content in this post, I hope you will find these recommendations useful and hope these suggestions will help you get started and/or improve your bug bounty career.

So let’s jump into it!

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 they should have been) 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 a 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. Be nice to each-other. There is always a way to ask the same honest questions while being polite and professional. It will come out looking much better, and it will help you build your reputation.

Rule #2: The 24 hour rule

This rule is tied 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 in the wrong state of mind. Taking the time will help you see things with a different and fresh perspective. It 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 how many lines of code 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 up to 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 take a bounty for granted

My former boss used to say, “The key of frustration is unmet expectations.” I heard this countless times, to the point it became a little bit annoying (Sorry Luke), but I ultimately considered it to be 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 take 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 duplicates or informative 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 scenarios that could happen and many times happen with justification. Sometimes what you think has a 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 agitated, 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 momentum going, keep looking for more bugs, don’t stop the hunt after 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. 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, or is placed with a team in a completely different timezone. Understand this and give them the time to work while you keep hunting. Of course,  if multiple days passed by and you got no response, then politely ask for an update. Don't be too incessant, since this can waste a 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 ensures you're safe while hacking on these programs. Don't hack 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, and some programs might might be angered by your actions. If you find something out of scope and want to report it, understand the risk, and never expect a bounty, otherwise, you will be disappointed 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. Also, avoid even mentioning that you are going to make a report public, since you agreed not to when signing up. 

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, it won’t help you and you might lose some credibility. Learn the CVSS score definitions to understand how to calculate it and better 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 or Shopify, in those cases understand their guidelines and know how they work in advance. Also, a 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- 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. 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 true, then, keep going! If not, completely ignore it! The race is against yourself, ignore all leaderboards. Use your growth as a comparison. How many bugs or how much in bounties did you get last week, month, or year? Set up your own goals and try to overcome yourself and improve your results. Set your goals a little higher each time. Try to reach those, and if you don’t, adjust them. Maybe you were too optimistic, but don’t get discouraged, you will reach them 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 practicing new stuff and 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, follow hackers who post consistently good work on twitter, understand what can be reported and what can't be reported from others' examples. Do some training, get certified, but always keep hacking and improving your skills. If you’re ever in doubt about a bug you believe should be reported or not, check hacktivity and other disclosed reports. It is a good way to find if it has been awarded in the past. If not, avoid reporting non impactful stuff or things with "Theoretical" impact. You must 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 this way (risking your stats in the process). If they decide not to pay for the bug, understand that you took the risk, accepted 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 if you don’t and disagree with a program, stop hacking on them, and 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. It is the best thing 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 useful. 

I wish you the best in your Hacker Journey!