skip to Main Content

Topic: Program Management

Bug Bounty KPIs: Response Time

There are many key performance indicators (KPIs) of a successful bug bounty program–some that matter more to program owners, and some that matter more to researchers. At bugcrowd we aim at aligning the importance of these KPIs between all involved parties to articulate better what is most helpful and valuable to each.

In this post, we will explore the ever important metric, response time. This value is a key factor in both maintaining a healthy and successful program, as well as keeping researchers engaged and involved. Communication, both in swiftness and effectiveness, is key to staying on the same page throughout the vulnerability reporting and review process. Our recent post regarding proper escalation paths when communication falls through is proof of that.

Read More

All You Need to Know About Bug Bounty Testing Environments

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.

Read More

4 Common Business Drivers for Launching a Bug Bounty

In the past several years, bug bounties have evolved from the open-to-everyone contests they once were, becoming more nuanced with the ability to meet various organizational goals and objectives. While some reasons for starting a bug bounty program may be more obvious than others, there are multiple business goals or drivers that organizations, including your own, may identify when looking into launching a bug bounty program.

Read More

OSS Security Maturity: Time to Put On Your Big Boy Pants!

Earlier today we joined Jake Kouns, CISO of Risk Based Security, and Christine Gadsby, Director of Product Security at BlackBerry for a guest webcast. They gave their Black Hat 2016 talk ‘OSS Security Maturity: Time to Put on Your Big Boy Pants’ which analyzes the real risks of using OSS and the best way to manage its use within your organization.

This post is a high-level review of that presentation–you can watch the recording here and download their slides here.

Read More

Essential to a Successful Bounty Brief: Exclusions

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. 

Read More

How to Write a Clear and Thoughtful Scope, A Deep Dive

We recently published a comprehensive but abbreviated guide ‘Anatomy of a Bounty Brief’ which explores each part of a bounty program brief and how organizations can write them more clearly and thoughtfully.

Once you’ve identified that you and your organization are ready to commit the necessary time and resources to running a bug bounty program, it’s time to start building out your program brief – the first step of which, is setting the program scope.

Read More

[Guest Blog] Skyscanner’s Adventures in Bug Bounties

Posted originally on by Stuart Hirst on Skyskanner’s Code Voyager Blog

Skyscanner has a culture of innovation and continuous improvement. For our IT security function, the ‘Security Squad’, it is no different. External security testing had previously taken the form of standard penetration testing, which brought considerable value and helped improve security posture. However, our Squad wanted to look at new ways of testing the products that we help secure on a daily basis. In early 2015, we began to investigate the possibility of a crowd-sourced testing mechanism.

Read More

When to Reward a Bug Bounty Submission

We’re regularly asked how Bugcrowd determines if a bug bounty submission is rewardable. Today, as we approach 10,000 submissions, and as part of Bugcrowd’s commitment to transparency, we’re shedding some light on our submission evaluation process. Its important to note…

Read More
Back To Top