There is no doubt that the bug bounty industry is growing quickly yet in spite of this (or perhaps because of it) it’s still novel to many. One area especially near and dear to my heart is on the triage side. As the Sr. Director of Security Operations at Bugcrowd, I oversee the team of Application Security Engineers responsible for validation and triage services on our customer’s bug bounty programs.

Bugcrowd has been managing bug bounty programs for the last 6 years – longer than any other platform out there! The following are a few common questions I get about the triage process.

“How qualified is the team triaging the bugs: education, experience in the field, credentials? Are they experienced bug hunters?”
In short, yes! We have a team of diverse industry professionals with various backgrounds, (e.g. vulnerability researchers, pen testers, code auditors, enterprise security, etc.) We hire for current high acumen, aptitude, and critical soft skills, all certainly more important than a laptop with Burp installed. In fact, I’ve touched on who this team is in one of my recent blog posts.

Many of us bug hunt ourselves; however, as I speak to in this post about vulnerability data privacy and policy, we have stringent self-imposed controls around participation on our platform and overall role-based access.

“How do we know Bugcrowd ASEs are not stealing rejected vulns that are legit and feeding them to friends who submit & get $$$?”

A vulnerability is reviewed by the following:

  • Scope
  • Validity
  • Priority per the applicable policy (Bugcrowd’s VRT, the program brief, and potentially CVSS if it applies to the program)
  • Reward, as driven by the priority and existing program policies

We operate on a first-to-find basis. If the vulnerability is in-scope, valid, and first-to-find it will be rewarded. Customers can see all interactions and vulnerabilities via Bugcrowd’s Crowdcontrol dashboard, including any in a non-accepted state. In the process of correlation and de-duplication such a scenario should be prevented and discovered. Lastly, another critical bit also covered in the above blog, any ASE with access to a program may not also participate as a researcher.

“How do we know the ASEs aren’t from foreign countries sharing vulns with their home country?”

Our Security Operations team consists of high-trust security professionals, both background-checked and under NDA. Where desired the assigned ASEs may be geo-restricted as with the participating researchers, however, most of our team is US-based.

“As a researcher, what should I expect in terms of response and process for my submission?”

Our managed validation team has a response time of less than 24 hours for critical issues and only slightly higher for everything that comes into the platform. Submission acceptance and reward can take longer according to customer remediation, policy, and sorting out any questions. In any of these cases an open channel of communications is important for expectation setting and that’s something we drive every day. These interactions are facilitated proactively in our platform on behalf of researchers but also via our support team and process.

If you ever have a question or concern you can always reach out to our support team:

“How do you handle concerns or escalations (e.g. when a researcher disagrees with the submission’s outcome)?”

We pride ourselves on our triage and validation accuracy. In fact, our acceptance rate post-triage to submission resolution is ~ 92%. For all questions, we arbitrate and facilitate mutual-understanding via our process. If the researcher disagrees with the validity determination, acceptance, or reward amount for a submission they are encouraged to open a support ticket. With this process, a few guiding principles:

  • The brief is the final word. We work very closely with our customers to translate bug bounty program goals into policy to avoid ambiguity, encourage testing, and appropriately incentivize with reward amounts. The brief in place at the time of submission applies to the submission.
  • Bugcrowd exists to facilitate successful outcomes for two parties that have not historically worked effectively together: security researchers and companies. We enable and work for both researchers and program owners to support this. We consider both the bug bounty program owner and the researcher our customers.
  • “Touch the code, pay the bug.” If the submission provides actionable value for the program owner it should be accepted for reward based on the program brief policy.
  • We put our words into action by paying submission rewards ourselves, in supplement or fully, where we deem necessary to do the right thing; it’s that important.

As always we earnestly welcome your feedback. My team and I work hard everyday to provide expert technical review, arbitration, and excellent service to both our researcher community and bug bounty program owners. If we can help you directly please contact us via, or if you’d simply like to connect, we’re on Twitter @bugcrowd or you can reach me directly at @digitalwoot.