Bug Bounty Operations for Vibe Projects: From Pricing to Payout

On October 1, 2026, Google announced it was pausing new product-vulnerability submissions to its Open Source Software Vulnerability Rewards Program (OSS VRP). The reason was a single sentence: "This pause is due to a significant rise in automated submissions, the vast majority of which are not valid." TechCrunch's October 4 coverage added the context: Google engineers and open-source maintainers had been overwhelmed by invalid reports and hallucinated vulnerability write-ups. The lesson even Google couldn't dodge: the real cost of a bug bounty program was never the bounties paid out — it's the human effort required to triage every single report. This guide doesn't cover defensive implementation techniques (that's the territory of the Vibe Project Web Security Baseline Guide) — it covers the operating machinery of a bounty program: when to launch, how to price, how to write scope, how to triage, how to filter AI-generated slop reports, and how to pay out. A solo or small team can follow it to build a bounty system that neither drowns in reports nor gets scared by the bill.

1. When to Launch: Three Signals and Two Alternatives

First, a counterintuitive conclusion: a bounty program is not the starting point of your security work — it's an amplifier. It amplifies a security response process that already works: someone who can read reports, someone who can reproduce them, someone who can schedule fixes. If nobody does those three things, a bounty program will only bury you in reports while burning your budget.

Three signals that it's time:

1. You handle real users' data or money. Paying users, a login system, a payment flow, user-uploaded private data — at that point the cost of one undiscovered vulnerability already exceeds the cost of running a bounty program. Conversely, if your MVP is still validating PMF, all users are test accounts, and the database holds barely any real records, don't launch. Reports will arrive faster than you can fix them, and hunters will conclude you're unprofessional.

2. You've done at least one round of basic security homework. Run dependency scanning, sweep the OWASP Top 10 basics yourself, ideally get one external pentest. Bounty hunters excel at finding what you didn't think of, not what you didn't bother fixing. If launch day brings a pile of "missing security headers" and "cookie without HttpOnly" reports, you launched too early — those should have been handled internally, and each one still eats your triage time.

3. Someone can respond — even if it's just you. The hidden cost of a bounty program is labor: reading reports, reproducing, grading, communicating, scheduling fixes. Industry data puts a new program's first-year bounty budget at $30,000–$100,000, and that doesn't include your own time. A one-person team can still run one, but the scope must be kept very small (see Section 3), and slower responses are acceptable — as long as the response SLA is written into the policy (see Section 4).

If only one of the three signals is true, take an alternative route:

Alternative A: Start with a VDP (Vulnerability Disclosure Policy), no bounties. A VDP is a public statement: "If you find a vulnerability in our systems, tell us through this channel; we promise to respond within X days and won't pursue good-faith researchers." It costs nothing and builds the "someone is willing to tell you" channel first. Many teams run a VDP for six months, accumulate report volume and triage experience, then convert to a paid program — with pricing and scope backed by data instead of guesswork.

Alternative B: Periodic pentests plus automated dependency scanning. Hire an external pentest every quarter (or buy a one-off testing service from a crowdsourced platform), paired with automated dependency updates like Dependabot or Renovate. For vibe projects with small codebases and fast iteration, this route often costs less per unit and produces more predictable output than bounties.

The gradual path in summary: VDP (free, build the channel first) → private bounty program (invite-only, small-scale pilot) → public bounty program (fully open). Each step is decided with data from the previous one, so neither budget nor labor spirals out of control.

2. Bounty Pricing: Four Tiers and a Low-Budget Start Strategy

Pricing is the easiest part of a bounty program to guess at — and the easiest to get wrong. Price too high and the bill explodes; price too low and good hunters stay away while AI-generated bulk reports flood in. Here's a starter pricing table for startups and small teams, mapped to CVSS 3.1 base scores:

Severity	CVSS range	Typical examples	Starter bounty (USD)
Critical	9.0–10.0	Unauthenticated RCE, payment bypass, bulk leakage of arbitrary users' data	1000–3000
High	7.0–8.9	Authenticated privilege escalation, stored XSS leading to admin, unauthorized access to sensitive APIs	300–1000
Medium	4.0–6.9	Reflected XSS requiring user interaction, CSRF with real impact, non-sensitive information disclosure	100–300
Low	0.1–3.9	Missing security headers (standalone), version disclosure, minor info leaks	0–100

Three rules govern pricing — all three are required:

First, benchmark the market, but don't copy the giants. Mature programs' public pricing is a good anchor: GitHub's public program, after its July 2026 repricing, pays $10,000 / $5,000 / $2,000 / $250 across the four tiers (with a higher invite-only VIP tier); Google's OSS VRP historically ranged from $100 to $31,337. You don't need to match that scale — hunters judge whether pricing fits your project's size. A vibe project with a few thousand daily users offering $2,000 for a Critical is reasonable; offering $20,000 would attract more report volume than you can handle.

Second, work backward from the budget, not forward from ambition. The formula is simple: annual bounty budget ≈ expected valid reports × weighted-average bounty. A new program's first quarter is usually the report peak (hunters sweep everything once), then volume tapers. Vendr's HackerOne transaction data puts new programs' first-year bounty budgets at $30,000–$100,000 — but those are mid-market companies. A vibe project can start at $5,000–$15,000 for year one; the key is writing "pricing is reviewed quarterly" into the policy, so you tighten scope or downgrade tiers when volume overshoots instead of toughing it out.

Run the numbers concretely: say your year-one bounty budget is $8,000. Based on new-program distributions — 5% Critical, 20% High, 45% Medium, 30% Low — and tier midpoints ($2,000 / $650 / $200 / $50), the weighted average per valid report is about $335. $8,000 covers roughly 24 valid reports, i.e. about 2 per month on average. That number tells you two things: the scope must be small enough to keep monthly volume in the single digits, and duplicate rules must be strict, or the budget runs dry by Q3. Using the budget formula in reverse is how you justify scope design — a calculation many teams do for the first time here.

Third, four concrete low-budget start strategies. One, go private first: invite 20–50 hunters with proven track records, keep it unlisted; volume stays controllable and per-report pricing can be slightly generous. Two, start low and publicly commit to raising: write "this program is in its early stage; pricing will be raised quarterly as the program matures" into the policy — hunters tolerate raises far better than cuts. Three, fill the gap with non-monetary incentives: a public Hall of Fame, attribution rights on disclosed write-ups, reference letters — real value for many hunters. Four, duplicates and known issues get thanks, not bounties — this must be in the policy, or duplicates will eat half your budget.

3. Defining Scope: In-Scope / Out-of-Scope Templates

The scope document is the most important legal and operational file in a bounty program. It decides three things: where hunters test, why you pay for a report, and what governs disputes. The principle: start narrow and widen gradually; never start wide and tighten later — tightening scope reads to the community as a prelude to stiffing people.

In-scope template (ready to use):

Asset type	Example wording	Notes
Web app	app.example.com (including all subpaths)	State whether the marketing site is included
API	api.example.com/v2/*	Pin the version; address old versions separately
Mobile	iOS app v3.2+ / Android app v3.2+ (latest store versions)	Pin minimum versions; older versions not accepted
Test accounts	Dedicated test accounts and staging environment provided	Real user data must not be used in testing

Out-of-scope and explicit exclusions (every item must be written down — there is no "excluded by default"):

1. Third-party services and components. Vulnerabilities in payment gateways (Stripe / Alipay), CDNs, or your cloud provider's console are not yours to fix or pay for. Wording: "Issues in third-party infrastructure should be reported directly to the respective vendor." But note: if the issue is your misconfiguration of a third-party service (e.g. a public S3 bucket), that's your responsibility — in scope.

2. Denial of service and brute-force testing. DoS/DDoS, brute-forcing login endpoints, blindly sweeping the site with automated scanners — these hurt real users and must be explicitly prohibited. What's allowed is a single PoC demonstrating missing rate limiting, not actually taking the service down.

3. Social engineering. Phishing, impersonating support, targeting employees — excluded, no exceptions. This is the reddest of red lines; writing it into the policy blocks a whole class of disputes.

4. Known vulnerabilities (N-days) and theoretical-only reports. A dependency with a public CVE you haven't patched yet is your ops debt — hunters may get thanks but usually no bounty (unless your policy explicitly pays). Reports with no PoC and only "theoretically possible" claims are closed as invalid.

5. Low-impact singletons. Standalone missing security headers, clickjacking with no impact chain, version disclosure, missing SPF records — either bucket these into a "hardening suggestions" category with a fixed small bounty, or list them as not accepted. Otherwise your triage queue fills with exactly these, which is also where AI slop concentrates.

Also handle the gray areas in writing. Example: your vibe project uses Supabase / Firebase as the backend, and a hunter reports a "Supabase configuration issue" — yours or Supabase's? The rule: whoever can fix it owns it. A toggle you misconfigured in your console is your in-scope issue; a vulnerability in the Supabase platform itself is out of scope — ask the hunter to report it to Supabase's program. Document one example per common gray area in a policy FAQ; it saves half of all future arguments.

4. Security Policy and Disclosure Channels: security.txt, PGP Email, and SLA Commitments

A bounty program needs a "front door": somewhere a hunter can find, within 30 seconds, where to report, who to contact, and how fast to expect a reply. The front door has three parts — miss one and reports leak away, and leaked reports don't disappear; they become public zero-days.

1. security.txt (RFC 9116). Place a security.txt at the site root and under /.well-known/:

Contact: mailto:security@example.com
Contact: https://example.com/security-policy
Expires: 2027-06-30T00:00:00.000Z
Encryption: https://example.com/pgp-key.asc
Preferred-Languages: zh, en
Policy: https://example.com/security-policy
Hiring: https://example.com/jobs

Four details matter: Expires is mandatory and must be under a year out — renew before it lapses or the policy reads as expired; serve security.txt with Content-Type: text/plain so it stays readable as plain text; Encryption points to your PGP public key so hunters can encrypt sensitive details; Contact should include both the email and the policy page URL, because the email alone can get eaten by spam filters.

2. A dedicated security email plus PGP. Use security@yourdomain, never the founder's personal address — handoffs during personnel changes are a disaster otherwise. Publish the PGP public key on the policy page and Keybase (or via WKD), with the fingerprint in security.txt. Practical tip: give this mailbox its own inbox rules and auto-reply ("received, response within 48 hours") so it doesn't drown in daily mail.

3. Write the response SLA into the policy page. A hunter's first filter for "is this shop legit" is the SLA — the only verifiable signal of reliability. Recommended commitments:

Milestone	Commitment
First response (acknowledgment)	Within 48 hours
Initial triage (valid / invalid)	Within 7 days
Remediation schedule communicated	Within 14 days of triage
Bounty payout	Within 30 days of verified fix

The SLA is only credible because of the earlier judgment call: if you can't manage a 48-hour first response, you're not ready for a program — fall back to a VDP. An SLA is a promise, not an aspiration. The first time you break it, hunter-community reputation collapses, and reputation is a small team's only acquisition channel.

5. Choosing a Platform: Join One or Build Your Own

Four routes, ordered from highest to lowest cost and effort:

	HackerOne	Bugcrowd	Intigriti	Self-hosted (email + form)
Platform fee	~$50k–$150k/yr (self-managed); ~$100k–$250k managed	Similar order to HackerOne	Lower, often volume-based	~$0
Bounty budget	Separate (new programs typically $30k–$100k yr 1)	Separate	Separate	Your call — can start at a few thousand
Triage service	Yes (managed plans include human triage)	Yes (crowdsourced triage is its strength)	Yes	All on you
Hunter traffic	Largest	Large	Strong in Europe	Zero — build reputation yourself
Best for	Well-funded, wants scale	Wants fast triage	Budget-sensitive, European users	Small teams, annual budget < $10k

(Fee figures from Vendr's HackerOne transaction data and 2026 industry reports; check each platform's current pricing.)

The recommendation for vibe projects is blunt: self-host if your annual budget is under $10,000. The platform fee alone would consume the entire budget before a single bounty is paid. Self-hosting boils down to four tasks: write the policy page (adapt a platform template), build a report form (mandatory fields in Section 7), set a fixed weekly triage slot, and have PayPal / Wise ready for payouts. The real gaps are two: no hunter traffic, so you must actively invite hunters via X / Discord / security communities at first; and no platform credibility, so the SLA must be over-delivered to earn a reputation.

Where do the first hunters come from for a cold-started self-hosted program? Three free channels: search the "bug bounty" topic on X for active researchers and DM invitations; post in Discord security communities (e.g. CTF team channels); submit your VDP link to the public directories on HackerOne / Intigriti (directory listing only, no paid plan). Make invitations specific: "We're a SaaS in the XX space, core asset app.example.com, starting bounties at $2,000 for Critical, 48-hour response" — hunters get flooded with invites; only specific ones with scope and response commitments get opened.

With $10,000–$50,000, choose a platform's private program: unlisted, invite-only for hunters with track records. Volume stays controllable (usually single digits per month), and the platform's triage service filters ~80% of invalid reports — the best-spent money for a small team. Go public above $50,000. Remember the order: prove you can handle reports with a self-hosted VDP before paying for platform traffic — reversed, platform traffic only drowns you faster.

6. Triage and Deduplication: CVSS in Practice and Duplicate Rules

Triage is the most technical — and most argument-prone — part of a bounty program. Rules must come first and be applied consistently; otherwise every High becomes a negotiation for Critical.

CVSS in practice: sweat the big things. A CVSS 3.1 base score comes from three metric groups: exploitability (attack vector — network vs local, attack complexity, privileges required, user interaction), impact (confidentiality / integrity / availability), and scope (does it affect systems beyond the vulnerable component). Vibe teams don't need to memorize every metric — use this simplified judgment:

Start with the attack vector: remotely exploitable with no login starts at High. Then impact: shell access, payment bypass, or bulk data exfiltration means Critical; read-only or self-only impact starts at Medium. Finally scope: a flaw in one component that affects the whole system (e.g. SSRF reaching the intranet) moves up one tier. Run the score through NVD's CVSS calculator and publish the score-to-bounty mapping in the policy — hunters can pre-grade their own reports, cutting disputes in half.

A full worked example: a hunter reports broken access control in your SaaS app — a regular user changes order_id in the order API and sees other people's orders with shipping addresses. Scoring: attack vector network (AV:N), low complexity (AC:L), low privileges required — just a normal account (PR:L), no victim interaction (UI:N); confidentiality impact high (C:H — other people's private data), integrity none (I:N), availability none (A:N), scope unchanged (S:U). The CVSS 3.1 calculator gives 6.5 — upper Medium. Your policy maps Medium to $100–$300; with the "other people's private data" impact premium, $250 is fair. Reply with this reasoning, not just the score — what hunters want isn't a high grade, it's evidence their report was actually read.

Fix the triage workflow at three steps: initial grade within 48 hours of receipt (a "pending reproduction" state is fine); final grade after technical reproduction; once the final grade is issued, it doesn't change without new technical evidence. Flip-flopping kills triage credibility faster than anything.

Duplicate rules — the budget's gatekeeper:

1. Same root cause counts as one report. Hunter A reports the SQL injection on the login endpoint, hunter B on the registration endpoint, and the root cause is the same unparameterized code — that's one report; the bounty goes to A, who arrived first. The test is "does the fix touch the same code," not "is the exploit path identical."
2. First come, first served, by report timestamp. Down to the minute — platforms log it automatically; self-hosted setups use email/form timestamps. Ties broken by PoC completeness.
3. Merging "already being fixed" reports. Keep an internal known-issues list (no need to publish details, just IDs). New reports matching a known issue are marked duplicate; notify the reporter it's already being fixed, and give a small thank-you bounty (e.g. a flat $50) or Hall of Fame credit — not the normal tier payout. This rule must be in the policy, or hunters will read it as stiffing.
4. Rewarding variant reports. If a second report demonstrates a significantly more damaging exploit chain for the same root cause (e.g. escalating from read-only to write), upgrade the original report's grade and pay the difference — don't open a new report. This detail is what keeps top hunters around.

7. Fighting AI Slop: The October 2026 Lesson

This is the new reality every bounty operator has faced since the second half of 2026. The timeline is crisp: end of January 2026, curl's Daniel Stenberg ended the paid HackerOne bounty entirely, citing AI-generated invalid reports; March, Google said its OSS VRP was hit by a "massive surge" of AI-generated reports — some hallucinated vulnerabilities, some real code issues that weren't exploitable under the project's security model — and responded by tightening evidence requirements, with certain memory-corruption reports for top-tier projects now requiring exact OSS-Fuzz reproduction steps or a merged patch; May, HackerOne reported industry-wide report volume up more than 100% year over year; July, GitHub halved public bounties (Critical from $20,000+ to $10,000) while opening an invite-only VIP tier at higher rates; October 1, Google paused new OSS VRP product-vulnerability intake, promising an update in Q1 2027. Bugcrowd's triage team coined a word for these reports: "sloptimism" — submitted fast and hopefully, the author trusting the model's output more than the evidence.

One more set of numbers worth remembering: Google paid a record $17.1 million to 700+ researchers in 2025, up 40% from $12 million in 2024 — bounty spending rose while triage headcount didn't, which is the structural reason slop could flood the channel. HackerOne's 2025 report also noted confirmed-valid AI-assisted reports rose 210% that year, with fully autonomous "hackbots" submitting 560+ valid findings — AI itself isn't the enemy. The problem was always unverifiable reports consuming the triage resources that valid reports deserved.

The core contradiction, stated plainly: LLMs didn't produce more real vulnerabilities — they made plausible-looking reports nearly free to produce. Triage is fundamentally manual: read the report, attempt reproduction, render judgment. Submission cost went to zero while triage cost stayed put; a team of Google's scale got overwhelmed. Without filtering, a small team launching a program is opening the floodgates.

The filter has three layers, matching the funnel below:

Layer 1: The format gate — mandatory PoC fields. Make the report form unsubmittable without: affected product and version, numbered reproduction steps (every step required), PoC code or request payloads, an impact statement ("what the attacker actually gains," not "could be dangerous"), and the test environment. This is where most AI-generated reports die: vague reproduction steps, a PoC that errors on run. This isn't gatekeeping for its own sake — HackerOne began requiring severity ratings on some programs in September 2026; the industry direction is consistent: put the burden of proof back on the submitter.

Layer 2: Reproduction check — no reproduction, no triage. Write it as a hard rule: "We only triage reproducible reports." Unreproducible reports get bounced with your reproduction environment notes and one chance to supplement; still unreproducible after that, closed. The key here is speed — slop reports all look alike; batch-process them instead of agonizing thirty minutes over each one.

Layer 3: Validity triage — only confirmed reports enter the bounty flow. Only reports that survive reproduction get CVSS grading and enter payout. Copy Google's March 2026 lesson: issues that are real but "not exploitable under your security model" are explicitly marked "outside the security model" — no bounty. This must be in the policy, or hunters will invoice you for every static-scanner warning one by one.

Templated rejection wording (ready to use, in both languages):

Chinese: "感谢提交。经复现，该报告描述的问题在我们当前版本中无法复现（详见附件复现记录）。根据我们的报告政策，可复现是定级的前提。如果你能提供在 X.Y.Z 版本、按附件环境可稳定复现的步骤，欢迎重新提交。"

English: "Thanks for the submission. We could not reproduce the described issue on our current version (see attached reproduction notes). Per our policy, reproducibility is a prerequisite for triage. If you can provide steps that reliably reproduce it on version X.Y.Z in the attached environment, feel free to resubmit."

One final principle: don't punish hunters who use AI as a research aid. Google itself acknowledges AI can accelerate discovery — the issue was never "used AI" but "unverifiable report." The policy wording should be "We welcome AI-assisted research, but all reports must meet our reproducibility evidence standard" — not "AI-generated reports are banned." The latter is unenforceable and drives away exactly the skilled people you want.

8. Hunter Communication SOP: Five Milestones, Templates, and Timelines

Hunters judge you half on bounty amounts and half on communication. Small teams can't outbid the giants on money; communication is the one arena you can win. Five milestones, one template and one timeline each:

Milestone 1: First response (within 48 hours). One purpose: let the hunter know the report didn't fall into a black hole. Template: "We've received your report (#2026-XXXX) and will complete initial triage within 7 days. We may need additional information during reproduction — please watch your email." The ID matters — everything after it is traceable, and hunters read it as professionalism.

Milestone 2: Triage confirmation (within 7 days). Valid: "Reproduction confirms this issue is valid, initially graded High (CVSS 7.5). It has entered the remediation queue, expected fix within X weeks." Invalid: "Reproduction shows this report is out of scope for our program (reason: out-of-scope / not reproducible / known issue); not accepted this time — see attached notes." Invalid verdicts must always carry a specific reason — "doesn't meet policy" says nothing and is the top source of disputes.

Milestone 3: In remediation (update every 2 weeks after triage). Many teams go silent for two months here, then get publicly called out. Template: "#2026-XXXX is still being fixed. Current status: root cause identified / patch in development / internal testing. Expected release by X." Even "not scheduled yet" must be said. Silence is the worst communication.

Milestone 4: Fixed (within 7 days of release). "#2026-XXXX was fixed and released on X. We invite you to retest within 14 days to verify the fix." The retest invitation is standard practice — respect for the hunter's work and a free quality gate.

Milestone 5: Payout (within 30 days of verified fix). "#2026-XXXX is graded High with a bounty of $800, to be paid via PayPal / Wise within 30 days. Please reply confirming your payout account and Hall of Fame credit name (anonymous OK)." Amount, method, and timeline in one message — not three separate emails.

The standard dispute flow for grading disagreements: when a hunter disputes a grade, ask them to score it with the CVSS calculator and justify each metric; respond to each disputed metric point by point (most disagreements land on "attack complexity" and "scope"). If no agreement is reached, escalate to a pre-designated external arbiter (e.g. the platform's triage service or an independent researcher you trust); the arbiter's call is final. Put this flow in the policy and disputes turn from "arguments" into "process."

Three iron rules: keep everything in writing (email or in-platform messages — never negotiate grades over instant messaging); never argue technical details in public (take disagreements back to email; nobody wins a public fight); stay courteous even on invalid reports — today's templated-rejected slop submitter may be tomorrow's top hunter, and community reputation is computed on your worst interaction, not your best.

9. Remediation SLA and Retesting: Timelines, Process, and the Hall of Fame

Triage decides "how severe"; the SLA decides "how fast it gets fixed." A bounty program without an SLA turns reports into a never-scheduled backlog, and backlogs are where disclosure disputes breed. Recommended remediation targets (counted from triage confirmation):

Severity	Fix target	Notes
Critical	7–15 days	Consider temporary mitigations first (WAF rules, disabling the feature)
High	30 days	Normal scheduling, within the next two iterations
Medium	60–90 days	Can align with release cadence
Low	Fixed with the next release	No dedicated scheduling, but set explicit expectations

Mind the wording: write "targets," not "guarantees," in the policy. Vibe projects often have one person wearing every hat; "target 15 days for Critical, delays communicated proactively" beats "guaranteed 15 days" followed by a miss. Hunters want predictability, not miracles.

A practical trick: align SLA timelines with your release cadence. If you ship every two weeks, the 30-day High target is exactly two iterations; the 7–15 day Critical target maps to one hotfix window. Once aligned, remediation scheduling needs no extra project-management overhead — bounty reports flow into your existing development rhythm, which is the only way a small team keeps up.

The retest flow, in four steps: notify the reporter after release with a 14-day retest window; the reporter confirms the fix (or presents a bypass — treated as new evidence, escalated accordingly); run internal regression tests to make sure the patch introduced nothing new; close the report and move to payout. If the reporter doesn't respond within 14 days, treat it as tacit confirmation and close — this too must be in the policy, or reports never close.

The Hall of Fame is a low-budget team's most important non-monetary incentive, and it's trivial to run: a table on the policy page with year, credit name (hunter's choice, anonymous OK), vulnerability type, and severity. The bar is "valid report," not Critical. Its value is chronically underestimated: many hunters put Hall of Fame screenshots on their résumés, especially students and newcomers — precisely the demographic that powers small-team bounty programs. Archive by year and publish an annual thank-you each January: maximum ceremony, zero cost.

10. Common Pitfalls: Disclosure Windows, Legal Safe Harbor, and Internal Rules

Pitfall 1: The disclosure window for hunters publishing details. The standard is coordinated disclosure with a default 90-day window — the industry norm set by Google Project Zero: the vendor fixes within 90 days of the report, after which the reporter may publish details. Your policy must state three things: the default 90-day window; extensions must be negotiated in advance (no unilateral extension announcements); details may not be published early without your written consent. The most common dispute is a hunter publishing on day 60 because you're "too slow." Prevention isn't threats — it's Milestone 3 from Section 8. Hunters routinely grant extensions to vendors who communicate and are visibly fixing.

Pitfall 2: The legal safe-harbor clause. The policy must contain an authorization statement, roughly: "Security research conducted within this policy's scope and rules will not be subject to legal action by us, and we will attest to its authorized nature if needed." Without it, testing your systems may technically constitute "unauthorized access," and nobody takes that risk. Have a lawyer review this paragraph before publishing — don't draft it yourself; a botched clause is the same as none. The US DOJ has a policy against prosecuting good-faith security research; the EU and China have their own frameworks — localize the wording.

Pitfall 3: Internal staff and affiliated participation rules. Write three lines in stone: company employees (including part-timers and interns) may not claim bounties — fixing your own code's bugs is the job; departing employees get a 6–12 month cooling-off period, during which reports earn thanks but no bounty; contractors are excluded for related projects during the contract term. Without this, you're paying your own people to find bugs they should have fixed, and inviting "were those bugs left deliberately" suspicion.

Pitfall 4: Payout logistics. Test PayPal / Wise availability to target regions before the first payout; sort out tax treatment for large bounties (some jurisdictions require withholding); pay only to the reporter's own verified account — no "send it to my friend." Run through these details before the first payout is due, not when a hunter starts chasing payment and you discover Wise doesn't support their country.

Pitfall 5: Scope so wide the bill explodes. The most common way new programs die: scoping "*.example.com," then receiving 40 reports in week one — 30 of them N-days in the marketing site's WordPress plugins. Countermeasure: first phase covers only the core product domain; the marketing site, docs site, and staging are explicitly out of scope. After a quarter of volume and quality data, widen gradually. Scope is a valve, not a manifesto.

Pitfall 6: Treating the bounty program as a marketing stunt. "We've launched a bug bounty program with rewards up to $100,000!" — while the scope covers only the marketing site and the core product is excluded. Hunter communities are brutally sensitive to this; one instance lands you on a blacklist. The marketing value of a bounty program is real (it signals "we take security seriously" to customers), but only if the program itself is real: scope covers core assets, SLAs are kept, bounties are paid on time. Marketing is a byproduct of good operations, not the goal.

Closing: Build the Channel First, Talk Bounties Later

Compress this guide into an action list: today, set up security.txt and the security mailbox, and publish a VDP; next month, finish one pentest round and compile the known-issues list; the month after, open a private bounty program with this guide's starter pricing and scope limited to the core domain; after a quarter of report volume and triage practice, decide whether to go public or join a platform. Google's pause of a four-year-old program tells us: a bounty program lives or dies not on how much you're willing to pay, but on whether you can process every report at a reasonable cost. Build the channel first, talk bounties later — get the order right and neither budget nor labor spins out of control.