Bug Bounty and VDP Platform Buyers Guide

Buying a bug bounty or vulnerability disclosure platform is easy; buying one that sends you valid, deduplicated reports your teams can fix, without exposing your data or your researchers, is harder. Platforms sell some mix of intake, triage, researcher community, payments, workflow integration and reporting, and they differ most in the parts that matter after launch: triage quality, data handling and how well reports reach the engineers who fix them. This vendor-neutral guide helps security, product security and procurement teams decide whether they need a platform at all, define requirements, compare offerings and run a pilot. Programme design itself (scope, safe harbour, rewards and disclosure timelines) is covered in the Bug Bounty and Vulnerability Disclosure Guide; this page assumes you have read it.

Key takeaways

Fix capacity comes first: a platform increases report volume, so buy only when you can triage and remediate what arrives within your published window.
A VDP may not need a platform: a policy, a security.txt file under RFC 9116, a monitored mailbox or form and ISO/IEC 30111 style handling are enough for many organisations.
Triage quality is the product: measure validity, duplicate handling, severity accuracy and time to first response in the pilot, not researcher counts on a slide.
Reports are sensitive data: platforms hold detailed exploit paths, screenshots and sometimes customer data or credentials found by researchers, so treat the platform as a high-risk supplier.
Integration decides whether bugs get fixed: reports must flow into the ticketing system and the owning team's backlog with severity, asset and SLA attached.

What the category does

Platforms provide some or all of the following. Self-run programmes provide the same functions with your own staff and tools.

Function	What a platform provides	Self-run equivalent
Intake	Hosted submission forms, programme pages, report templates, encrypted attachments	Web form or mailbox, security.txt, PGP key via the RFC 9116 Encryption field
Triage	First-pass validation, reproduction, deduplication, severity scoring, often by the platform's own analysts	Your PSIRT or AppSec team
Researcher community	Access to registered researchers, invitations to private programmes, reputation systems	Only researchers who find your policy
Payments	Researcher identity, tax forms, sanctions screening and payouts in many countries	Finance processes you build
Workflow	Status tracking, researcher messaging, retest requests, disclosure coordination	Ticketing system and email
Reporting	Programme metrics, trend and benchmark views, compliance reports	Your own dashboards
Adjacent services	Time-boxed crowdsourced tests, attack surface discovery, pentest as a service	Separate procurement

Programme types you may buy: a VDP (no rewards, always on), a private bounty (invited researchers, defined scope), a public bounty (anyone can participate) and time-boxed crowdsourced tests. Bounties and tests are not a substitute for penetration testing under NIST SP 800-53 CA-8; they complement it. For buying testing services, see the Penetration Testing Provider Buyer's Guide.

Define requirements

Do you need a platform?

You probably do not yet if you only need a VDP, have low report volume, and have a team that can acknowledge and assess reports. The NCSC vulnerability disclosure toolkit sets out the essentials: a dedicated contact route, a clear policy, a security.txt file, prompt acknowledgement, no non-disclosure agreements for finders, updates and recognition.
You probably do if you want to pay rewards across many countries, need triage capacity you do not have, want to invite researchers to private scope, or receive high volumes of low-quality reports that swamp your team.
Public sector: US federal agencies must meet CISA BOD 20-01. It requires that the policy does not require personally identifiable information and accepts anonymous reports, authorises testing by the general public rather than only vetted or registered parties, and includes a commitment not to pursue legal action against good-faith research that follows the policy. A platform that forces researcher registration may not fit a BOD 20-01 VDP on its own.

Requirements to write down

Scope: which domains, applications, APIs, mobile apps, devices and cloud tenants, and which are excluded.
Programme types: VDP only, private bounty, public bounty, time-boxed tests.
Triage model: fully managed, partially managed or self-triaged; hours of coverage; languages.
Targets: acknowledgement, initial assessment and resolution targets. CISA recommends acknowledgement within 3 business days, assessment within 7 days and resolution within 90 days for BOD 20-01 programmes, which are reasonable starting points elsewhere too.
Integrations: ticketing, chat, SIEM, vulnerability management, asset inventory, single sign-on and SCIM for your users.
Data requirements: where report data is stored, retention, who at the platform can read it, and how researcher-found secrets and personal data are handled.
Legal and finance: safe harbour wording, researcher terms, tax and sanctions handling, budget model.

Small organisations should start with a self-run VDP and the Vulnerability Disclosure Policy Template, then consider a private bounty on one or two key applications. Large enterprises often run a VDP across everything plus a private bounty on crown-jewel applications. The Vulnerability Disclosure Maturity Model helps place your programme.

Capability areas

Intake and security.txt support: a programme page and form you can reference from the Policy and Contact fields of security.txt, encrypted submissions, anonymous submission where your policy needs it.
Triage service: reproduction, deduplication across your history, severity scoring with a documented method (for example CVSS), clear rationale and escalation for critical issues outside business hours.
Researcher management: invitations, scope per researcher group, conduct enforcement, removal of abusive researchers, and identity checks where you require them for private programmes.
Payments: reward tables by severity and asset tier, budget caps and approvals, tax and sanctions screening, and payment audit trails.
Workflow integration: two-way sync with your ticketing system, mapping of reports to asset owners, retest requests and closure rules.
Disclosure coordination: support for coordinated publication, CVE requests where you are or use a CNA, and acknowledgements pages.
Security of the platform: SSO and MFA for your staff, role-based access per programme, audit logs, encryption, data residency options and a strong vulnerability disclosure programme of its own.
Reporting: volume, validity, duplicates, severity mix, time to acknowledge, time to triage, time to fix, payouts by asset.

Where identity fits

Many valid reports involve identity: leaked API keys, tokens in mobile apps or public repositories, broken authorisation and exposed service accounts. Ask how the platform handles a report that contains a live secret: whether it is redacted from researcher-visible views, how fast your team is alerted, and whether researchers are told not to use found credentials beyond proof of validity. Rotation must happen immediately, before triage finishes. The API Key Management Guide covers rotation; integration API tokens between the platform and your ticketing system are themselves NHIs that need scope limits and rotation.

Evaluation criteria

Criterion	Weight (suggested)	How to assess
Triage accuracy	High	In a pilot, compare platform severity and validity decisions with your own review of every report
Signal to noise	High	Percentage of reports forwarded to you that are valid, in scope and not duplicates
Response times	High	Measured time to acknowledge and to triage, including weekends and critical escalations
Data protection	High	Review data residency, retention, staff access, encryption, certifications and the platform's own incident history
Integration	High	Test two-way ticketing sync with your real tracker and asset owners
Researcher fit	Medium	Ask for researcher skills that match your stack (mobile, API, cloud, hardware), not total headcount
Legal terms	Medium	Check safe harbour support, researcher terms and whether they conflict with your policy or BOD 20-01
Payments	Medium	Confirm countries, tax handling, sanctions screening and audit trail
Cost model	Medium	Platform fee, triage fee, reward pool handling, and what happens to unspent reward funds
Exit	Medium	Export of all reports, attachments and researcher communications in a usable format

Framework mapping

Framework	Reference	What a platform supports
NIST SP 800-53 Rev 5	RA-5(11) Public Disclosure Program; RA-5; CA-8; SR-6	A public reporting channel, vulnerability handling, complementary testing, supplier review of the platform
NIST CSF 2.0	ID.RA-08	Processes for receiving, analysing and responding to vulnerability disclosures
ISO/IEC 29147 and 30111	Vulnerability disclosure and vulnerability handling processes	External disclosure interface and internal handling (see the ISO/IEC 29147 and 30111 Guide)
RFC 9116	security.txt Contact, Expires, Policy, Encryption, Acknowledgments	Discoverable reporting route
CISA BOD 20-01	VDP requirements for US federal agencies	Public authorisation, anonymous reports, scope growth, metrics

Questions to ask vendors

Who triages our reports, where are they located, what are their working hours, and how are critical issues escalated out of hours?
What were your median times to first response and to triage last year, and how do you measure them?
How do you deduplicate against our previous reports and against reports submitted outside the platform?
Where is report data stored, how long is it kept, and which of your staff can read it?
How do you handle reports that contain live credentials, customer personal data or regulated data?
Can researchers submit anonymously, without registering, if our policy or BOD 20-01 requires it?
How do your researcher terms interact with our safe harbour and policy, and which takes precedence?
Which ticketing systems do you sync with both ways, and how are tokens for that integration scoped?
How are reward funds held, and what happens to unspent funds at renewal or exit?
How do we export everything if we leave, and in what format?

Deployment and integration

Prepare internally: name a programme owner, agree severity definitions, remediation targets and a budget, and confirm each in-scope asset has an owning team.
Set up access safely: connect SSO with MFA, apply least-privilege roles per programme, and scope the ticketing integration token to the projects it needs.
Start private and small: launch on one or two applications with a small invited group, then widen scope as remediation keeps pace.
Publish the route: update security.txt Policy and Contact fields on every domain you serve it from (RFC 9116 applies per domain, not to subdomains) and set Expires less than a year ahead.
Run handling drills: walk a critical report from submission to fix and disclosure, including out-of-hours escalation and secret rotation.
Review and expand: every quarter review metrics, reward table and scope, and move to a public programme only when remediation meets your published targets.
Plan the exit: test a full export before renewal, so that switching or bringing triage in-house is possible.

Budget for internal effort as well as fees: even with fully managed triage, your engineers still reproduce, fix and retest every valid report, and your programme owner still handles disputes, payments approval and disclosure decisions.

Measure: valid report rate, duplicate rate, median time to acknowledge, median time to triage, median time to remediate by severity, percentage of reports meeting target, and spend per valid high or critical finding.

Red flags

Researcher headcount as the main pitch: large numbers say nothing about skills on your stack or triage quality.
Opaque triage: no named process, no severity rationale, or triage staff locations and access undisclosed.
Terms that undercut safe harbour: researcher terms that conflict with your policy or demand non-disclosure the NCSC advises against for finders.
Weak data controls: no data residency options, unlimited retention or broad internal access to reports.
No export: reports, attachments and messages that cannot be fully exported.
Severity inflation: triage that routinely rates findings higher than your own review, which inflates payouts and distorts remediation priority. Ask how severity disputes are resolved and who has the final say.
Bounties used as hush money: any suggestion that a payment can be tied to silence about a real breach. Bounty payments reward research under a policy; they never replace incident response or legal notification duties.
Launch pressure: pushing for a public programme before your remediation capacity is proven.

Proof of concept

Agree a 60 to 90 day pilot on a private programme with one application and a small researcher group.
Define pass criteria in advance: valid rate, response times, severity agreement and ticket sync.
Review every report forwarded, and a sample of those rejected, against your own triage.
Submit a seeded test report containing a dummy secret to check redaction and escalation.
Test two-way ticketing sync, retest flow and closure.
Run a payment end to end, including tax and sanctions checks.
Export all pilot data and confirm it is complete.
Hold a review with the engineering teams who fixed pilot findings and ask whether the reports were clear enough to act on without follow-up.

Buyer checklist

Remediation capacity and targets agreed before launch.
Decision made on self-run VDP versus platform, with reasons.
Scope, programme type and reward table documented.
Triage quality measured in a pilot, not taken from marketing.
Data handling, residency and staff access reviewed as a supplier risk.
Safe harbour and researcher terms aligned.
Ticketing integration tested with scoped tokens.
security.txt updated on every domain, with Expires set.

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for vulnerability disclosure and bug bounty programmes, including the handling of leaked keys and tokens that researchers report. Browse vendors in our NHI and AI products directory or contact us.

Bug Bounty and VDP Platform Buyers Guide: Choosing Triage, Payouts and Researcher Reach