Bug bounty
A program that rewards outside researchers for responsibly finding and reporting real security holes in systems you put in scope.
See it
What it is
A bug bounty promises money or another reward when an outside researcher reports a valid vulnerability under published rules. Programs can be private and invitation-only or public, and platforms such as HackerOne and Bugcrowd handle researcher identity, submissions, triage, and payouts. Netscape ran the first one in 1995, paying for bugs in the Navigator 2.0 beta.
Start one when you already have a disclosure channel, someone who can triage reports quickly, and engineers available to fix what arrives. Define the exact assets in scope, allowed testing, severity method, duplicate policy, response targets, and reward bands before inviting researchers.
The gotcha is thinking the crowd replaces your security program. Researchers follow incentives and visible attack surfaces; they do not guarantee coverage of quiet internal risks. A vague scope also creates arguments about ownership, duplicates, and payout. Begin privately, measure triage capacity, and never invite testing on a system your team cannot safely receive or repair.
Ask AI for it
Design a private bug bounty program on HackerOne for this product. Produce an asset table with exact in-scope domains, APIs, and mobile apps; list out-of-scope assets and prohibited tests; add safe harbor for good-faith research; define duplicate, disclosure, and eligibility rules; and set first-response and triage service levels. Build a reward table tied to validated impact and CVSS v4.0, with discretionary adjustments explained in writing. Add submission fields for endpoint, account role, reproducible steps, request and response evidence, and impact. Finish with the internal triage workflow, payout approval path, remediation owner, retest step, and criteria for expanding from private to public.