Your Guide to Hacking with Bugcrowd and Why You Should Get Started Today

What is Bugcrowd?

Simply put, Bugcrowd is a crowdsourced security knowledge platform – connecting hackers/researchers to organizations (and vice versa) in a variety of ways, the most popular of which being via bug bounties (we’ll talk more about the different ways in just a bit). The platform facilitates and augments those connections with the richest security knowledge graph in the industry–knowledge that, for example, drives our CrowdMatch™ recommendation engine to ensure productive experiences for researchers and customers alike.     

We work with members of the crowd (you!/hackers/researchers) to help secure hundreds of organizations across nearly every conceivable industry (automotive, fintech, e-commerce, banking, IoT, etc) around the world. And across the programs we run for those organizations, there’s all sorts of targets for researchers to hack on, including Web Applications, APIs, iOS and Android Apps, Automotive Targets, Binaries, Recon engagements, and more! With a diverse range of opportunities for hackers to hack on (and the ability to surface them at scale via CrowdMatch), industry leading triage (we’ll talk more about what triage is in a moment), a community that cares, and a superb support team with access to data about vulns, environments, and targets developed over a decade and 1000s of programs run for organizations – Bugcrowd’s goal is to provide the best possible experience on our platform for everyone involved. 

What You’ll Find at Bugcrowd

There’s something for everyone at Bugcrowd. No matter your skill level, interests, or ambition when it comes to hacking, we’ve got something for you. Looking to hack and make serious money while doing so? Want a safe and nurturing community to practice your skills? Interested in making the internet a safer place? Or maybe you’re looking for ways to get into hacking (possibly even making it into a career), and need a way to get started? 

Whatever your goals are, read on to learn more about what we offer:

Bug bounty

What if I told you that you could hack on hundreds of thousands of targets for major companies and organizations (Tesla, Department of Homeland Security, Indeed, Dell, Comcast, and more) and get paid for it?

Well, that’s what a bug bounty is! Like the name implies, it’s bounties for bugs… if you are able to identify a security vulnerability on an in-scope target, you can get paid for it (provided you were the first to find the issue). If this sounds a little too good to be true, it’s not. Granted, there are some important pieces to be aware of, which we’ll cover in an example below:

Note: as mentioned above, bug bounties on Bugcrowd are only for security vulnerabilities. Non-security bugs should be reported to the support team for the given organization, but not through Bugcrowd.

• Step zero: make an account on Bugcrowd.
  • Go here to get started. Simple enough.
• Step one: pick a target to hack on. 
  • To keep things neutral, we’ll say we’re going to pick ‘bugcrowd.com’ from the program here. This page is referred to as the “bounty brief” – which has all of the information you need to get started hacking on a given program. Each brief has critical information about the program including (but not limited to) scope, credentials, access, information around the targets, rewards, and any other specific program info. Always read the program brief entirely before submitting… few things are worse than investing time and effort, only to realize later that the item you’ve been testing is out of scope. You can see all public bounty programs here.
• Step two: find & report a vulnerability.
  • For the sake of simplicity, we’ll say we found a reflective XSS vulnerability (RXSS) on the target where we’re testing. We click the “submit report” button, fill out the details and hit submit. For tips on how to write a great report, we recommend checking out this blog. Some things to always keep top of mind when creating a report are:
    • Keep it professional. It can be tempting to toss together a few sentences rife with typos and call it good enough – but a well-written report has a lot of advantages… it’ll get your sub triaged more quickly since there’ll be less back and forth/confusion around replication, and it’ll get you more private invites more quickly. It’s worth being aware that we keep track of testers who write good reports, and the good ones get more invites because of the higher quality work they produce. 
    • Always express the impact. If there’s one thing most people forget to include in their reports, it’s to clearly articulate the impact of the issue. Sure, it’s cool we got an alert box, but what can you do with the XSS finding? Show impact, show value, and the rest of the process will move more smoothly – and may even net a higher payout, since most reward amounts are in a range. Things at the top of the range are typically going to be well-written reports that clearly explain the impact and value of the finding. 
• Step three: work with Bugcrowd’s triage team to validate.
  • At Bugcrowd, we have a world-class team of security engineers who review every finding that gets submitted to the platform. They check to make sure the finding is (a) in scope; (b) is a valid vulnerability; (c) has sufficient replication steps; and (d) is not a duplicate. Provided the report passes all of those checks, it will then be passed along to the client for them to accept and reward the finding. In the event that the report is:
    • Out of scope: the Bugcrowd ASE will mark it as ‘out of scope’, with a note as to why.
    • Isn’t a valid vulnerability: the Bugcrowd ASE will advise the reporter that it’s not a vulnerability, and mark the finding as ‘not applicable’.
    • Lacking sufficient replication steps: the Bugcrowd ASE will let the researcher know that they’re unable to replicate, and will ask for more details in a comment. From here the researcher (you) and the Bugcrowd ASE will work together to make sure each side is getting the same outcome to provide the organization with usable replication steps. In the event that it cannot be replicated after multiple attempts, the ASE will mark the submission as Not Reproducible with a note as to why.
    • Duplicate: the Bugcrowd ASE will mark the finding as a duplicate of the original submission. You’ll be able to see the title and timestamp for the parent submission, but no additional information will be provided. Duplicates are an unfortunate part of bug hunting; the best advice we can give around duplicates is “don’t stop” – getting duped can be deflating, but persistence is key. Over time, you’ll develop your own methodology and way of finding bugs that nobody else does. Or you’ll find them faster, or look in places that everyone else skips. That’s the thing about bug hunting – everyone does it differently, and it’s exactly that reality that gives you a chance to make a mark of your own. 
• Step four: Get paid. 
  • Provided your finding makes it past all of the above steps, it’s now on the client to accept the finding, which most do within 14 days. At the point where it’s accepted, it’s also typically rewarded!
  • But wait… how do you know how much you can expect to get paid? For this, every program has a reward range listed on their program brief – usually by priority – e.g. P1/2/3/4. But how does one know what P-level a specific finding is? To help with this, Bugcrowd has created a robust Vulnerability Rating Taxonomy (VRT) that enumerates every common vulnerability we typically see come into the platform, and gives it a rating by technical severity. We do this for a couple of reasons:
    • It gives researchers and organizations a shared language and point of reference. If all parties are aligned on what’s a critical (P1) finding from the start, then things are much more straightforward when it comes time to reward a finding. Before the VRT, there would often be disputes where the researcher would think something was a P1, and the organization would say it was a P2… which was never ideal for either party. By creating a shared and clearly defined taxonomy, that confusion is a lot more rare these days – allowing for less friction, and quicker payments. Everyone wins!
    • It’s fluid/open-source. We’re constantly updating the VRT with new entries for new vuln classes, or revising items up or down in priority, based on emerging evidence. If you don’t agree with where something sits on the taxonomy, you can create an issue on the Github repo to make your point and you may get it changed universally!
  • If we refer to the VRT for our RXSS finding, we can see it’s a P3, and now know what we can expect (as a range) for our reward. As noted above, reports that are well-written and that demonstrate impact are going to be more likely to get on the higher end of a reward range (compared to hastily written reporting).
  • As a note, in addition to getting monetary compensation, points are also given out based on the priority level of the finding. These points allow you to gain a higher ranking on the platform, relative to other testers, etc.
• And that’s it. There can be more nuances to the process, but in general, the above is roughly in line with what one can expect for any given submission. Good luck and happy hunting!

VDP

Another type of program you’ll encounter on the Bugcrowd Platform are VDPs, or Vulnerability Disclosure Programs, which are (more or less) exactly what the name implies. These programs are a place where researchers can responsibly disclose vulnerabilities to the organization running the program. These programs are different from bug bounties in the following ways:

1. They do not offer rewards or any incentives to participate (if/where a program offers some sort of incentive, it’s then a bounty, as opposed to a VDP).
2. Points are not awarded for participating in a VDP program.

In every other way, VDPs function largely the same as a bug bounty: scope, creating a submission, getting it reviewed/accepted, etc.

Said differently: VDPs are meant to be a “see something, say something” place for people who encounter vulnerabilities in the wild to be able to report them responsibly. For example, imagine you’re using a webapp and stumble upon a vulnerability of some sort. How can you make sure that issue gets into the right hands to make sure its impact is understood, and that it gets remediated? This is exactly what a VDP is for – it gives security researchers the license to investigate for vulnerabilities (e.g. if you think there’s a vulnerability there, but don’t want to get into trouble for testing, a VDP with safe harbor enables you to test without fear of prosecution), and an official channel to report the issue.

To be supremely clear, VDPs are not unpaid bug bounties – they are simply a safe space to securely and responsibly report vulnerabilities with no expectation of payment. In other places these may be called RDPs (Responsible Disclosure Programs), but because we’re specifically dealing with vulnerabilities (and RDP is more commonly used to refer to Remote Desktop Protocol), we use the term VDP on the Bugcrowd Platform.

Now, just because they’re unpaid programs, that doesn’t mean they don’t offer potential value to an aspiring security researcher/hacker. If you’re just getting started with appsec, VDPs can actually be a great place to test your skills in the wild. There are plenty of sites where you can practice your skills (Hack the Box, Pentesting Lab, etc), but few things are as useful as cutting your teeth on real-live targets. Because VDPs tend to have very wide scopes that include the entire organization, there’s typically more attack surface than a bug bounty, and because it doesn’t offer rewards, it’s less likely to be picked clean by other security researchers. Said differently: there’s a greater chance of finding a valid vulnerability via a VDP, than a bug bounty. Again, there’s no rewards, but VDPs can be a great place to practice finding issues against real-world targets before moving onto bug bounties. You can see available VDPs here.

Private Programs

Bug bounty and VDP are the two main types of programs on the Bugcrowd Platform, and are the only ones that you can get started on out-of-the-gate, no experience required. There are other engagement types, but we’ll cover those in more depth later.

What enables one to start hacking on these programs without any prior experience or rating on the Bugcrowd Platform is that they’re “public”. Public programs are exactly what they sound like – programs that are open to the public, and as such, anyone can participate on them. You can view all public bounty and VDP programs here. All you need to start hunting on anything there, is just an account… nothing else is needed!

Once you build enough proven capabilities on the platform, you may start getting invited to private programs. These programs are reserved for people who have shown value (via finding valid vulnerabilities) and demonstrated trust (by not testing out of scope, creating escalations, or violating the code of conduct) on the platform. Once you’ve done that to a reasonable degree (specifics are outlined below), then you’ll start getting invites to private programs to which CrowdMatch has matched your skills and abilities. To get matched to private programs, make sure your resume, availability, and preferences are updated regularly, and that you stay active on the platform (e.g. submitting valid findings). CrowdMatch identifies who to put on which program and takes all of these values into account when selecting researchers (skills, availability, background, etc.), so keeping that data up to date is essential for earning unique testing opportunities. 

The minimum criteria to qualify for private programs are

• ID verification completed or background check (this way people can’t create a bunch of sockpuppet accounts and try to game the system by creating 30 accounts with the same bugs across all of them)
• Average accuracy 75% or higher (All time accuracy)
• No active escalations and adherence to Platform Behavioral Standards
• At least one valid and unique (non-duplicate) P3 or higher (even if it’s against a VDP)
• At least four valid (e.g. in-scope, replicable) findings (dupes are included here) 

So why should you care about private programs? Simply put: less competition. Less competition = more opportunities for you to find a valid vulnerability. If it’s you vs. the world, it’s going to be a lot harder to find something thousands of other people have missed, as opposed to finding something on a program with 25 or 50 people. Sometimes you’ll get invites to programs that just started, but most of the time you’ll get invites to programs that may have started a while ago – but don’t despair! Even if you’re not the first or if you’re the 50th, you’re still competing against a smaller pool of testers than if it were a public program. Additionally, if it started a while ago, go check for changelogs and updates for things that have been modified since the program started – it’s possible that there’s been a complete rewrite of the app, and maybe there’s still fresh fruit to be found!

The more you find and the more active you are, the more likely you are to get invites, since you’ll have demonstrated competency across a wide range of targets, making you more likely to be selected for a new target that has similar characteristics. Additionally, the more money you earn, the more invites you get as well. If you want invites to more nuanced programs, it pays to submit against target types that are less common – such as mobile apps (Android/iOS) or APIs, or binary/hardware targets. Building skill banks there will put you on the shortlist to getting invites when those target types come around again for a new program. Private programs are the bulk of all Bugcrowd programs, representing over 70% of the opportunity (where the other 30% is public), so it’s a good place to be, if you can make it there.

Joinable and Waitlisted Opportunities

Often, organizations will have limitations in terms of how many people can participate on their program – whether due to infrastructure, credentials or other control. In these situations, they’ll setup a Joinable or Waitlisted program that reveals a small amount of information about the program, which allows people at a certain level (e.g. X number of submissions, Y level of average priority, etc) to gain access once they hit that level. Think of it like unlocking certain powers in a game: once you reach that level, you access those programs. You can view the specific requirements on any joinable program, to know exactly what you’re missing to get there. Joinable programs can be found here.

Waitlisted is roughly the same as Joinable, but instead of reaching a certain level and immediately gaining entry, individuals instead have to apply for the program. This can be a great way to get access to programs that require niche skills, provided you have those niche skills (e.g. if the program needs people who can hack IoT space toasters, and that happens to be what you wrote your PHD dissertation on). No need to slow-roll it, you just apply, state why you’re the best person on the planet for this target/scope, and if it checks out compared to the other candidates (say, for instance, if we only have ten available seats we may need to be stingier than if we had five hundred), then you’ll be notified if you’re accepted. Waitlisted programs can happen both pre and post-launch – meaning that sometimes the program you’re applying for hasn’t even launched yet! As an important caveat, please don’t spam all Waitlisted programs in an attempt to get access to one – it won’t work. If a program is Waitlisted, it’s because there’s limited seats, and we have to give those to the best possible candidates – so, please only apply for Waitlisted programs where you’re uniquely qualified to be one of the best possible persons to test on the program. You can view Waitlisted programs here – check back often, as new ones pop up all the time!

Pen Test

What if bug hunting isn’t your speed? What if you’re a better fit for grinding out a methodical approach to checking a specific list of tests against a given target? Not everyone is cut out for the world of bug hunting where there’s mega-highs when you find something after hunting for hours or days, and deep-lows when you haven’t found anything after hunting for hours or days. Some prefer the even-keeled consistency of doing a task without any of that added pressure, and still others like to do all of it. 

For people in this vein, we have what we call “pay-for-effort” engagements, which are most typically pen tests. The tester/researcher will get a certain rate up front, and then follow a specific methodology, documenting every test and outcome along the way. It’s grindy and methodical, but it’s also consistent and reliable, as opposed to the ups and downs that come with bug hunting. If this is your speed, you can apply to perform pen test engagements here: <LINK>. However, do keep in mind that these jobs are in extremely high demand, and there’s a limited number of them every week, so for as much as we’d love to give pen tests out like candy, we unfortunately have an extremely high bar for getting into this group, and aren’t often accepting new talent. That said, it never hurts to throw your hat in the ring if you’re an OG pentester that’s down to pick up some work on the side, or are looking to go completely freelance. 

NOTE: we’re currently not adding anyone to our researcher pen test bench, but will likely be adding people later in 2022. Feel free to apply now, but do be aware that you may not get an update for many months due to demand. Thanks!

Why Hack At All?

A lot of people hack for a lot of different reasons… some like the fame of being a top hacker, some do it for the money (many have made six figures, and a few elite hackers have hit seven figures), other hackers do it for the fun of it, some for the community (it really is a great and supportive community), some to practice skills in the wild, some to build their hacking skills (over 80% of researchers surveyed a few years ago said that bug hunting helped them in their careers), and finally – some do it just to make the internet a more secure place today than it was yesterday. Whatever your reason, we invite everyone and anyone to experience what Bugcrowd has to offer, and what it can do for you. To summarize, here is a non-exhaustive list of why people may hack:

• For fun
• For fame
• For money
• For the community
• For practice
• For building skills / getting into cybersecurity
• To make the internet a safer place
• Fill in your own reason here ___________

Whatever your reason, you can find your hacking inspiration with Bugcrowd! 

Why Should YOU Hack on Bugcrowd?

We’ve covered why people would choose to hack on bug bounties as a general concept, but there’s a number of platforms out there that offer bounties as well. Why should you hack on Bugcrowd specifically? 

We like to think there’s a lot of really good reasons for choosing Bugcrowd over the alternatives, and below are a few of our top ones.

1. Triage & validation.
   1. Expert And Experienced Triage. As a researcher, the single most important aspect of hunting is what happens after you submit the report. Does it sit for weeks to months without getting touched? Is it duped without an explanation? Is it paid the right amount? And so on. A lower paying program that builds relationships with the researchers is often preferential to a higher paying one that ignores or is dismissive of the people trying to help make them more secure. We take a great deal of pride in our triage and validation team being the first point of contact for 99% of all submissions to the platform. It’s a team that is made up of current and former bug hunters themselves (led by @codingo) – so they know what it’s like to be in the shoes of someone who is submitting bugs, and treat researchers with the professionalism and respect they deserve. Our ASE (Application Security Engineer) team spans the entire globe to support all timezones, and are all entirely staffed in-house (where other platforms may use 3rd parties to do triage and validation, which can create inconsistency, delays, and a less-than-ideal experience). We understand the researcher’s experience innately, and do our best to make sure researchers get the best possible outcome in our interactions and to learn from our mistakes. 
   2. Managed By Bugcrowd. As mentioned above, 99% of all tickets into the platform are managed and triaged by Bugcrowd. There are a small number of clients who triage their own submissions for one reason or another, but for the vast majority of programs, if you make a submission, it’s going to be handled by a Bugcrowd ASE first – one who is knowledgeable of the bug hunting experience, capable of delivering the highest quality of support, and who has access to the full power of the Bugcrowd Platform and its rich security knowledge graph.
   3. 99% First Touch SLO. Additionally, while some platforms offer variable support in terms of when they get to your reports, Bugcrowd’s ASE team has an industry leading 99% adherence to our SLOs (Service Level Objectives) when it comes to getting to your findings. For P1 findings, it will get a response or action from our ASE within a single business day, and for P2-5 reports, our SLO for first touch is three business days (business days at Bugcrowd are defined as 9am-5pm, Pacific Time). There are other SLOs we have for our triage team, but this is the main one – that you will get a response to your initial submission within these timelines. No other platform can offer that; but we do. 
   4. Appeals. As mentioned above, our stalwart ASE team deals with hundreds of thousands of tickets, and if you do anything hundreds of thousands of times, there are bound to be some hiccups along the way. We make mistakes, we’re human; that’s a fact. But we’re also willing and able to own those mistakes – if we miss something or mess it up, we have an official appeals process that you can follow by sending your concern to support@bugcrowd.com. We review each and every appeal directly. That said, due to the amount of time an investigation can take, we don’t have an SLA for appeals, but we do process every single one. And if we’re in the wrong, we’ll take the appropriate corrective actions to make it right. 
2. Make-it-Right (MiR). Sometimes things go awry and we make a mistake – and when we do, we correct it as best we’re able – going so far as to pay out of our own pocket. We specifically have a fund set aside where, in situations where Bugcrowd is at fault, we make sure the researcher is fully compensated for the finding. For instance, if we mark something as Not Applicable, but later realize after a subsequent submission gets paid out for the same issue, that we were wrong in marking it as NA. Since the other finding has already been rewarded, the program owner/organization is unlikely to be willing to pay for the same issue twice, even if the original submission was the one that should have been paid. In that case, Bugcrowd will admit our mistake in putting the original sub to NA, and then “make-it-right” by paying out that researcher the amount that they would have been rewarded otherwise because we’re committed to doing right by the crowd.
3. VRT / consistency. We talked earlier about our Vulnerability Rating Taxonomy and its value to both organizations and researchers, and that’s another really big reason why thousands of researchers choose to hack on Bugcrowd. Most testers have had one situation or another where there’s a dispute over the priority of a finding, many times originating as a result of using a system that seems like it’d breed consistency, but instead often creates confusion due to variable layers of interpretation and context (see: CVSS). Wondering how you and your finding are going to be treated from person to person and organization to organization is no way to operate, and at Bugcrowd we aim to provide consistency and predictability all the way through the cycle – from how things are rated, to the timeline you can expect them to be actioned on, to the experience in working with one of our in-house ASEs. Consistency is key, and something we look to provide all researchers as part of our best-in-class experience.
4. Templates. Improving the researcher experience is something we never stop doing at Bugcrowd, and our just-released templates are one more way to improve the consistency that researchers experience on the platform – saving you time, and helping craft more professional and impactful writeups when creating reports! If you haven’t already, we recommend checking it out, and hopefully it can help you create reports more quickly (nobody likes report writing) that drive higher payouts via demonstrated impact. Did we also mention that in order to help with submission quality, ASEs also have the ability to edit (so as to improve) your submissions too? ​​This allows us to not only correct some of your heat-of-the-moment mishaps, but also shows you the changes so you can improve your reporting skills! 
5. CrowdMatch. We probably don’t talk about it enough, but we’re constantly working in the background to create better and better matching algorithms to place the right researchers on the right programs at the right times. We’re still in the early stages of testing for our new machine-learning matching, but initial data shows that when we invite researchers with our new matching model, on average, individuals make over twice as much money compared to older matching models. Of course, it’s early and only being used currently on a small portion of programs – but we’re optimistic for the results. And while we’re building that, we’re still doing everything in our power to put the right testers on the right programs at the right time, so you can make the most of the time and opportunities in front of you. Said differently: when Bugcrowd can pair you with the programs that you’re most likely to be successful on, you’re more likely to find valid issues, and in doing so, make more money as well. Said more simply: our algorithm helps you make money.
6. Support. To start here, let’s give a huge shout-out to our Support team here at Bugcrowd. Working Support can be a thankless job. Sadly, nobody messages Support because things are going well; instead, it’s only when things are going wrong (usually very wrong) that one ends up messaging Support. So before going in too deep, I do want to remind everyone to exercise kindness and empathy when working with support at any organization. Additionally, it’s worth being aware that Support often isn’t able to affect outcomes directly – most of the time they’re waiting on program owners or organizations to respond, that may be slower to reply. Those caveats being said, our Support team is 100% here to help, and cares about helping researchers get the service and outcomes they need. If you reach out to support@bugcrowd.com, your ticket will get reviewed and it will get actioned, even if it may take a while to reach the desired end-state. You can learn more about how to work with Support here.
7. Community. One of the best parts of being part of the crowd is the community. Whether on Twitter, YouTube, Discord, Slack, Forums, or elsewhere, there’s no shortage of people who are willing to share their time and knowledge with people looking for answers. If you’re looking to learn and interact with like-minded hackers, we recommend checking out the Bugcrowd Discord. Come hang out, ask some questions, and pass it on to the next generation. Additionally, every so often Bugcrowd runs a virtual conference called LevelUp, and the videos from those talks are available here. Even better, if you get the chance, we highly recommend attending (or even speaking at) a LevelUp. And finally, Bugcrowd routinely tries to share valuable tips/tricks on our blog and Twitter, so we recommend following both streams to make sure you’re catching everything we have to share (we like to give back too!).
8. Opportunities. At the end of the day, a platform without opportunities to hack on, is a platform you’re unlikely to really engage with. Fortunately, Bugcrowd has hundreds and hundreds of programs for you to work on, regardless of what you’re looking for from a skill/target/type perspective, there’s something for everyone! 
   1. As a note, if you don’t like the invite you’ve been given for any reason, you can always choose to decline the invitation after reviewing the program brief. Additionally, there’s also the ability to leave feedback on a program at any time – information which is actively used by the receiving organization and Bugcrowd to improve the brief and overall experience for everyone involved. It may not be actioned immediately, but the information is seen by a real human who takes the feedback into account when making recommendations and adjustments for the program.

Getting Started is Easy

So now you know why one would want to hack, and more specifically, why one would want to hack on Bugcrowd. So where do you start? First, set up your researcher portal. After you log in, don’t wait to set up your profile – this includes your Payment details, Security, Skills & Interests, and Resume. Then head on over to our Discovery Page and start your hacking journey with Bugcrowd!

Final Thoughts

There’s a place for everyone at Bugcrowd: any skill set, skill level, or stage in your cybersecurity journey. From the altruistic individual looking to make the internet a safer place, to the prolific full-time bug hunter, to the person who has yet to submit their first but… whoever you are and wherever you’re at, we hope you’ll find a home with Bugcrowd. 

Follow us on Twitter and Discord. Don’t forget to drop us a line if you have any questions at support@bugcrowd.com. Good luck, and happy hunting!