When we talk with CISOs and security staff who are unfamiliar with the concept of crowdsourcing, one of the first topics they bring up is trust. After all, it’s reasonable to question the vetting of, and controls around, talented hackers who are paid to find often-critical security vulnerabilities using adversarial techniques. During such conversations, we always start with the most obvious fact: threat actors are looking for vulnerabilities in your assets every day. Furthermore, they are not limited by any vetting or controls. The only way to beat them to the punch is via offensive testing done by a trusted crowd in a fully managed, secure, and transparent way. Better yet, engage a crowd that is augmented by customized AI models for scale and efficiency. (To better understand what motivates the Crowd to do what they do, consult our annual Inside the Mind of a Hacker report.)
From there, the conversation gets more detailed. We dive into how Bugcrowd creates mutual trust between program owners and the Crowd, with the Platform providing more controls for secure access and visibility into activity when they’re required. Here are the top trust-related questions we get, along with answers:
No, bug bounty engagements can be private (by invitation only) or public. In both cases, security researchers must agree to Bugcrowd’s Standard Disclosure Terms and Code of Conduct before they can participate.
Private bug bounty engagements are invite-only and not publicly advertised. Only Bugcrowd-vetted researchers are invited, offering customers more control and limited scope to grow their engagements gradually. Public bug bounty engagements are promoted in Bugcrowd’s public directory, allowing a much larger pool of researchers to participate. This provides greater insight, scale, and speed; helps customers proactively market their security operations; develops community relationships; and elicits the maximum number of vulnerability submissions.
In contrast, penetration testing and red team engagements are always private, while vulnerability disclosure programs are always public.
Yes—by default, all discovered vulnerabilities in crowdsourced security engagements must be kept confidential. Customers can choose to allow public disclosure of general-interest vulnerabilities after mitigation, but they are not required to do so (although in most cases, disclosure is inevitable because it’s in the customer’s best interests).
Hackers build trust on the Bugcrowd Platform incrementally based on a consistent track record of skill and professional behavior—what we call the “trust journey.” Our data-driven vetting process, the intensity of which often surpasses most organizations’ own employee-vetting processes, is a critical part of our AI-augmented approach to crowd curation and activation (CrowdMatch AI).
As researchers progress on their trust journeys, they become eligible for public, then private (including penetration tests), and finally restricted engagements, leading to increased impact and rewards.
For customers with specific requirements (e.g., geolocation restrictions, special security clearances, or specific certifications), we also offer the following:
Anyone who violates Bugcrowd’s rules face consequences, including removal from eligibility for engagements, forfeiture of payments for found vulnerabilities, and loss of access to community resources. We continuously monitor the activity of even our most trusted testers.
When needed, the Bugcrowd Platform also provides secure, controllable access to internal and external targets, as well as visibility into which targets have been accessed and by whom, via a Cloudflare Zero Trust secure gateway. This approach adds an additional security layer between your curated testing team and your infrastructure, giving you and your testers more control and increasing safety. With this easy-to-configure, easy-to-manage approach, you can suspend/restore an individual’s access to targets or remove that target from your scope entirely—without affecting the rest of the engagement.
Even highly trusted researchers are not automatically eligible to join our elastic pentester bench. We evaluate them against additional benchmarks first, including the following:
New pentesters must also demonstrate skills and a track record with a specific asset type (e.g., mobile apps, APIs, or IoT devices) before being matched to an engagement. They are also subject to a probationary period after joining the bench.
In addition to the controls that apply to hackers and pentesters, we validate the employment histories and skills of red team members through technical interviews and operator simulations. During engagements, we implement active risk-management procedures, attack approval chains, and logging to ensure operators stay within defined boundaries.
We believe that rewarding the vital contributions of our global security researcher community should be a straightforward, trustworthy process for everyone. Our payment system prioritizes trust, simplicity, and transparency. It was built with robust security and compliance at its core. For example, we implement FedRAMP-inspired architectures and automatically disqualify researchers from banned countries per OFAC, EU, OSFI, and HMT watchlists.
Now that you know a lot more about how Bugcrowd fosters trust, secures access, and provides visibility into activity, it’s time to Get To Know The Crowd!