Set bounty rewards by impact tier, fund them from a stated budget, and write the rules for duplicates, partial reports and edge cases before launch. Pay quickly and consistently. A modest reward paid fast beats a large one that is argued over. OWASP says a bounty needs defined reward amounts and how they are decided.
Start from the requirements
OWASP's disclosure guidance lists what a bounty needs: defined scope, eligible vulnerability types, safe harbor terms, reward amounts and how they are decided, and response and payout timelines. Reward design sits in the fourth item, and it depends on the others.
Step 1: Choose tiers by impact
Use a small number of tiers, based on what the attacker gains, not on the bug class name. For example:
- Critical: account takeover at scale, remote code execution, access to all customer data.
- High: access to another customer's data, privilege escalation to admin.
- Medium: limited data exposure, meaningful but constrained abuse.
- Low: minor issues with small impact.
Define each tier in a sentence with an example. If you use CVSS as input, label the score and adjust for your environment, since FIRST says the Base score is severity and not risk.
Step 2: Set amounts and a budget
You choose the numbers, based on what you can afford and what your market expects. This post does not give figures, since they vary widely. Practical rules:
- Start with a total budget for the quarter, and a cap per report.
- Make the gap between tiers meaningful, so researchers know it pays to find the serious problems.
- Review after six months using real data.
If money is tight, run a smaller program or stay with a disclosure policy plus credit. OWASP lists credit, discounts, swag and a hall of fame as ways to reward researchers without a bounty.
Step 3: Write the edge case rules
Put these into your terms:
- Duplicates: the first valid report is rewarded. Say how you decide who was first.
- Chained issues: pay for the combined impact, or for the highest single bug, but say which.
- Partial reports: what you do when a report lacks reproduction steps.
- Known issues and out of scope items: no reward, but a polite reply.
- Variants: how you treat a new bug in the same root cause.
- Tax and identity: what you need to pay someone. Check with finance and counsel.
Step 4: Promise timelines you can meet
OWASP lists response and payout timelines as required content. Pay within a stated period after the fix or the validation. Delays cause more bad feeling than small amounts.
Step 5: Plan for the first month
Expect a surge of low quality reports, as OWASP notes smaller organisations can struggle with triage volume and junk. Before launch:
- Staff triage with named people.
- Prepare reply templates.
- Keep fix capacity free for a few weeks.
- Start with a smaller scope, or invite only researchers.
Avoid these mistakes
- Paying for every report regardless of impact, which trains people to spam.
- Changing the rules after a report arrives.
- Using the bounty to replace internal testing.
- Rewarding only what is easy to explain.
Review every quarter
Look at total paid, time to triage, time to fix, share of valid reports, and which tiers drew reports. Adjust tiers and scope. Share a short summary with researchers so they see you take the program seriously.
Quick check
Do we have to publish reward amounts?
Many programs do, since it attracts researchers and avoids disputes. OWASP says reward amounts and how they are decided should be defined.
Can we change rewards later?
Yes, for future reports, with notice. Apply changes going forward, not to reports already in progress.
Sources
Last reviewed: 19 October 2026.
