Insights · Buyer guide

Bug bounty and vulnerability disclosure platforms explained

A bug bounty pays outside researchers for valid findings, a vulnerability disclosure programme (VDP) only gives them a safe and documented way to report, and a pentest is a time-boxed test by a team you choose. Platforms host any of these. For most organisations the sensible start is a VDP with a security.txt file, and a paid bounty comes once triage and fixing run reliably.

Updated: 6 November 2026

Bug bounty, VDP and pentest: the differences

A vulnerability disclosure programme is a published policy. It tells anyone who finds a security flaw where to send it, what you will do with it and what you promise in return. It normally offers recognition rather than money. It is open all year and has no fixed end.

A bug bounty builds on that policy and adds rewards. Researchers are paid for valid, in-scope findings, usually on a scale linked to severity. A pentest is different in kind: you hire a defined team for a defined period and scope, and you receive a report. It gives you predictable coverage, while a bounty gives you continuous coverage whose results vary from week to week.

Many buyers combine them: a pentest before launch, a VDP as the permanent front door and a bounty on the assets they most want examined.

Private or public, managed or self-managed

A public programme can be joined by any registered researcher. It brings the most eyes and the most noise. A private programme invites a limited group, often selected by the platform on skill or track record, and suits teams that want fewer, better reports or that are not ready for open traffic. Many organisations start private and open up later.

Managed versus self-managed describes who does the work around the reports. With platform-managed triage, the provider's staff check incoming reports, remove duplicates and invalid findings, and pass on a validated case. With self-managed operation you receive the raw reports and decide everything yourself, which costs less money and more internal time. Ask each provider exactly which steps are included, who sets severity and where your data is stored.

The main platforms at a glance

The list below is alphabetical, not a ranking. Descriptions and locations follow what each provider states on its own website as of November 2026. Where a site names no headquarters, none is given here. Check scope, pricing and contract terms with the provider directly.

• Bugcrowd: crowdsourced bug bounty, VDP and penetration testing; San Francisco, USA, and Sydney, Australia.
• HackerOne: bug bounty, VDP, pentesting and continuous testing on one platform with a researcher community; headquartered in San Francisco, USA.
• Intigriti: bug bounty, VDP, pentest as a service and live hacking events with EU data hosting; offices in Antwerp, Belgium, and London, UK.
• Open Bug Bounty: a non-profit coordinated-disclosure platform for web vulnerabilities found without intrusive testing; the site does not state a location, and rewards are optional.
• Synack: pentesting with a vetted researcher network plus AI-assisted testing, attack surface management and a VDP offering; global headquarters in Redwood City, California, USA.
• YesWeHack: bug bounty, VDP, vulnerability management and exposure management tools with integrations into ticketing systems.
• Yogosha: bug bounty, VDP, pentest as a service and special operations such as red teaming; headquartered in Paris, France.
• Zerocopter: coordinated vulnerability disclosure, bug bounty, pentesting and reconnaissance; office in Groningen, Netherlands.

security.txt and the ISO standards

RFC 9116, published in April 2022, defines security.txt, a small text file that tells researchers how to reach you. It is an informational RFC, not an Internet standard. The file must contain a Contact field and an Expires date, it is served over HTTPS at /.well-known/security.txt, and it should be renewed before it expires. The German BSI also recommends publishing one, together with a functional mailbox such as psirt@ and an OpenPGP key.

ISO/IEC 29147 describes how a vendor receives vulnerability reports and publishes advisories. ISO/IEC 30111 covers what happens in between: investigating, fixing and verifying. Both are in their second edition (2018 and 2019) and ISO lists both as current and due for revision.

On the EU side, Article 12 of the NIS2 Directive makes each Member State name one national CSIRT as coordinator for coordinated vulnerability disclosure. The coordinator can act as a neutral intermediary between reporter and vendor, and ENISA maintains a European vulnerability database.

EU Cyber Resilience Act: duties and dates

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), applies to manufacturers of products with digital elements sold in the EU. According to the European Commission it entered into force on 10 December 2024. The reporting obligations apply from 11 September 2026, and the main obligations from 11 December 2027.

Since 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product, or of a severe incident affecting its security, must report it through ENISA's Single Reporting Platform, which went live on that date. The notification reaches the CSIRT of the Member State of the manufacturer's main establishment. The deadlines are an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days after a fix or mitigation is available (for vulnerabilities) or within one month of the 72-hour notification (for severe incidents).

From December 2027 the vulnerability-handling requirements in Annex I also apply. Among them are a coordinated vulnerability disclosure policy and a contact address for reports. A bug bounty is not required by the CRA, but a VDP, a security.txt file and a working intake process are a practical way to meet those points. Ask legal counsel which of your products are in scope.

Legal safe harbour

Researchers worry that good-faith testing could be treated as unauthorised access. A safe harbour clause in your policy states that you will not take legal action against people who follow the rules. It does not change the law and it cannot bind prosecutors or third parties, but it removes a major reason for researchers to stay silent.

The non-profit disclose.io offers open, vendor-neutral policy templates and safe harbour language. Platforms typically provide their own standard terms as well. Have your counsel review the wording against national law, especially when you operate in several countries, and cover third-party systems, personal data and what researchers may do after finding access.

Preparing before you launch

Most failed programmes fail on operations, not on technology. Settle the following before you invite anyone.

• Scope: list the domains, apps and APIs that are in scope and name what is excluded, such as production data, denial of service, social engineering and third-party services.
• Triage capacity: decide who reads reports, how fast you acknowledge them and who can fix the findings. Confirm that engineering has time reserved.
• Rewards policy: choose a severity scale, ranges per level, a payout process and a rule for duplicates. If you cannot pay yet, run a VDP first.
• Rules of engagement: define test accounts, rate limits, data handling and disclosure timing.
• Legal and communication: add safe harbour, name the contact, and prepare the internal escalation path for critical findings.
• Asset hygiene: fix known weaknesses first, because a bounty on an unpatched system is an expensive way to find what a scan would have shown.