How to Build a Vulnerability Disclosure Program or Bug Bounty

A vulnerability disclosure program (VDP) and a bug bounty are related but different commitments. A VDP is a policy document with a communication channel — it tells researchers how to report vulnerabilities and commits the organization to a good-faith response. There are no financial rewards. A bug bounty adds monetary incentives tied to vulnerability severity and scope, typically managed through a platform that also handles researcher vetting, triage, and payment.

For organizations with no existing external security research engagement, start with a VDP before a bug bounty. A VDP surfaces your vulnerability intake process gaps, tests your triage and remediation workflow, and establishes researcher relationships before you are paying for reports. Many organizations discover they receive more reports than their security team can triage within expected SLAs before they are ready for a live bounty program — this is better discovered through a VDP than through a paid program with SLA obligations to researchers.

Bug bounties are appropriate for organizations that have: a defined scope of applications and infrastructure they are comfortable having researchers probe, a triage team (internal or through a platform) able to review and prioritize reports within 72 hours for critical findings, a remediation workflow that can close critical vulnerabilities within 30 days, and budget for researcher rewards at market rates (typically $500-$2,500 for high severity, $5,000-$25,000 for critical/RCE on in-scope assets).

Private bug bounties — invite-only programs available through HackerOne and Bugcrowd — are an intermediate step between a VDP and a public program. They engage a vetted pool of researchers against your scope without the unlimited public inbound volume of a public program.

The most critical element of any VDP is safe harbor language — explicit legal protection for researchers acting in good faith within the program scope. Without safe harbor, researchers cannot be confident that reporting a vulnerability will not result in prosecution under the Computer Fraud and Abuse Act (CFAA) or equivalent statutes in other jurisdictions.

Minimum safe harbor language must include: authorization to access the specified in-scope systems for security testing purposes, commitment not to pursue civil or criminal action against researchers following the program rules, commitment to respond to reports within a defined SLA (72 hours acknowledgment, 14 days initial assessment), and coordination procedure for public disclosure after remediation (standard is 90 days from report, aligned with Google Project Zero).

Scope definition determines what researchers are authorized to test. In-scope: your primary web applications and APIs, mobile apps, and public-facing authentication systems. Out-of-scope: denial-of-service attacks, phishing your own employees, accessing customer data beyond proof-of-vulnerability, physical security testing, and third-party services. Explicit out-of-scope lists prevent researchers from doing things that would create legal liability or operational damage.

Do not use vague language about 'minimal impact' or 'responsible testing' as a substitute for explicit scope — researchers operate under a reasonable interpretation of scope boundaries, and ambiguity leads to disputes. If you do not want researchers testing your production database, say so explicitly, and tell them what testing environment is available instead.

VDP and bug bounty programs can be self-hosted (a security.txt file, a security@ email address, and a ticketing system) or managed through a platform (HackerOne, Bugcrowd, Intigriti, Synack).

Self-hosted VDPs are appropriate for organizations with a small in-scope attack surface and adequate internal security team capacity to triage reports. Required components: a security.txt file at /.well-known/security.txt with your policy URL and contact, a published policy page, a dedicated email address or web form with acknowledgment receipts, and a ticketing system integration for triage. This costs essentially nothing and satisfies CISA BOD 20-01 requirements.

Managed platforms provide: researcher vetting and fraud prevention, triage-as-a-service (Bugcrowd and HackerOne both offer platform-level triage that filters duplicates and assesses validity before reports reach your team), researcher reputation systems that improve report quality, payment processing for bounties, and program analytics. HackerOne and Bugcrowd are the two largest platforms, with the largest vetted researcher communities.

Intigriti is the leading European platform, important for GDPR-compliant programs where researcher data residency matters. Synack offers the most restrictive researcher vetting model (employed researchers, background-checked) appropriate for financial services, healthcare, and government programs where regulatory scrutiny of who has access to systems is significant.

For budget-constrained teams, a self-hosted VDP with a security.txt file and security@ email is a completely viable starting point. Migrate to a managed platform when report volume exceeds what the internal team can triage or when you are ready to launch a paid bounty.

The most common failure mode for new VDPs is poor researcher communication — reports acknowledged but never resolved, remediation taking months without updates, duplicate reports handled dismissively. Researchers talk to each other. A program with poor communication gets a bad reputation in the research community and stops receiving reports.

Triage SLAs for viable programs: acknowledge receipt within 24-72 hours, provide initial validity assessment within 14 days, provide remediation timeline within 30 days of valid report. For critical findings (RCE, authentication bypass, mass account takeover), all three happen within 72 hours.

Duplicate handling is a common point of friction. When a report duplicates an already-known vulnerability, tell the researcher whether the issue is already known internally and under active remediation or whether it was unknown before their report. Researchers receiving 'duplicate — not eligible for reward' with no context feel exploited. If their report identified an issue you were already working on, tell them that — researchers generally accept this with a courtesy acknowledgment.

Coordinated disclosure timing: standard industry practice is 90 days from report to public disclosure, regardless of whether the organization has remediated. This creates deadline pressure on remediation teams. If you need more than 90 days, communicate with the researcher early and negotiate an extension — researchers will usually grant 30-day extensions for complex vulnerabilities when asked respectfully and given evidence of active remediation work.

A vulnerability disclosure program is table stakes for any organization with a public attack surface — it is not a luxury or a statement about maturity. Start with a security.txt file, a security@ email, a one-page policy with safe harbor language, and a clear scope definition. This takes a day to stand up and is immediately meaningful. Add a managed platform and financial rewards when your team has the triage capacity and remediation velocity to honor them. Researchers who trust your program will bring you vulnerabilities before attackers exploit them.