skip to Main Content
Attack surface has grown exponentially for many organizations, and with it, their susceptibility to weaknesses. To combat this reality, security teams utilizing crowdsourced security solutions have expanded their program scopes to include more and more of their ever-evolving assets. Notable…
As the quote goes, “if you don’t know where you’re going, you’ll end up someplace else”. This cliche, yet valid aphorism runs doubly true when running a crowdsourced security program. If we don’t have a clear idea of what success…
“What reward ranges should I set for my program?”, “How much should I pay for a given finding?”, and “What should my organization’s reward budget be for a successful program?” At Bugcrowd, we hear these questions time and time again…
Once you’ve launched your program, things are far from over - in fact, they’re just beginning. And that’s not a bad thing. Depending on the scope, the number of participating researchers, and other factors, some programs will start seeing vulnerability…
Running a successful bug bounty program starts far before the actual program launch date, and is a continuous and iterative process of improving and growing over time. The workflow and lifecycle of a managed bug bounty program can typically be…
A growing number of organizations across various industry sectors are adopting crowdsourced security, making it clear that this model is no longer just the future of cybersecurity - it is the here and now. Crowdsourced security is driving organizations to…
Bug bounties have continued to grab headlines over the years – as evidenced by the fact that we’ve seen a 40% growth in program launches over the last year alone. As bug bounty programs move towards becoming more of a…
Over the past year, we’ve spent some time diving into many of the different aspects relating to setting up a successful bug bounty program. Previously we’ve covered setting your scope, and the importance of focus areas, as well as some considerations to make around setting exclusions and provisioning your testing environment. Additionally, we’ve also taken a brief look at reward guidelines and disclosure policies, and how they can be used to both enhance your program and increase visibility.
By way of a quick refresher, in regards to setting up a bug bounty program, we’ve already covered step zero, setting your scope, and the importance of focus areas, as well as some considerations to make around exclusions on your program.
Now that we’ve covered most of what goes into writing a bug bounty brief, including rewards and disclosure policies, let’s take a look at what environment you’ll be providing for researchers to test against. Regardless of how you decide to set up your application(s), it’s important to remember that our goal is to attract great talent from the crowd, sustain activity, and ultimately minimize the challenges of setting up and running a bug bounty for you and your internal teams.
In continuing our series on building a bounty brief, we’ve already covered step 0, creating a scope, and also touched briefly on focus areas. Now that you have the foundation of what you want researchers to be testing, it’s now time to turn your attention to what you don’t want them to be testing – which is just as, if not more important, as clearly stating what you do want to be tested. We do this by explicitly noting and drawing the researcher’s attention to our exclusions.
Why is it so important? Simply put, it’s a matter of respecting researchers’ time and effort. If we take a moment to look at this from a researcher’s point of view, every issue that we clearly exclude on the bounty brief is something they won’t/don’t need waste their time testing for and/or reporting. A brief that doesn’t contain explicit exclusions runs the risk of receiving issues that the program owner may not care for – resulting in wasting the time and resources of both the researcher and the program owner. To clearly document these exclusions, we’ve identified five of the most common categories to consider for exclusions when building your program: low impact issues, intended functionality, known issues, accepted risks, and issues resulting from pivoting.
