Updated live from approved reviews
The state of bug bounty
These numbers come from 102 reviews of 9677 programs. Researchers who filed reports wrote the reviews, and an admin approved each one. None of the data comes from the companies.
9,677
Programs listed
102
Approved reviews
7
Verified researchers
36%
Would submit again
Grade distribution
1 graded, 9676 not yet ratedSo far 1 program has enough reviews for a grade. The distribution appears once ten programs are graded.
A program needs three reviews for a grade. Review one you have worked.
Time to first response
7 reviews reportingPaid the advertised range?
97 reviews reportingMost-reported practices
Top strengths
+
Credits researchers
7 reports
+
Clear, honest scope
6 reports
+
Responsive communication
4 reports
+
Clear, current policy
4 reports
+
Respectful & professional
4 reports
Top concerns
−
Slow to pay
4 reports
−
Downgrades severity
2 reports
−
Slow to first response
2 reports
−
Auto-closes valid reports
1 report
−
Disputes valid scope
1 report
Deduced from platform data, updated hourly
Intelligence
6,356 programs trackedWorked out from metrics snapshots, thanks leaderboards, researcher profiles and advisory credits. Click a row to see the steps behind it.
- Reports (90-day window)
- 129,483
- Lifetime resolved
- 227,240
- Bounties paid (lifetime)
- $157.1M
- Median critical payout
- $5,000
- Avg response efficiency
- 78%
- Invite-only programs
- 0
Launch surges
4 programs under 30 days oldPrograms that launched recently and are taking reports faster than they can process.
1.First seen in metrics 9 days ago → program is ≤9d old
2.reports_received_90d = 182 (a rolling window, but the program is only 9d old, so this is the full total)
3.Intake rate = 182 ÷ 9d = 20.2 reports/day
4.resolved_report_count = 3 (lifetime monotonic counter)
5.Estimated backlog = 182 − 3 = 179 unresolved
⇒ At 20.2/day intake with 179 unresolved, this program is taking in reports faster than it resolves them.
1.First seen in metrics 28 days ago → program is ≤28d old
2.reports_received_90d = 398 (a rolling window, but the program is only 28d old, so this is the full total)
3.Intake rate = 398 ÷ 28d = 14.2 reports/day
4.resolved_report_count = 0 (lifetime monotonic counter)
5.Estimated backlog = 398 − 0 = 398 unresolved
⇒ At 14.2/day intake with 398 unresolved, this program is taking in reports faster than it resolves them.
1.First seen in metrics 7 days ago → program is ≤7d old
2.reports_received_90d = 86 (a rolling window, but the program is only 7d old, so this is the full total)
3.Intake rate = 86 ÷ 7d = 12.3 reports/day
4.resolved_report_count = 1 (lifetime monotonic counter)
5.Estimated backlog = 86 − 1 = 85 unresolved
⇒ At 12.3/day intake with 85 unresolved, this program is taking in reports faster than it resolves them.
1.First seen in metrics 28 days ago → program is ≤28d old
2.reports_received_90d = 146 (a rolling window, but the program is only 28d old, so this is the full total)
3.Intake rate = 146 ÷ 28d = 5.2 reports/day
4.resolved_report_count = 4 (lifetime monotonic counter)
5.Estimated backlog = 146 − 4 = 142 unresolved
⇒ At 5.2/day intake with 142 unresolved, this program is taking in reports faster than it resolves them.
Crowding signals
30 programsHow fast the 90-day report count is changing. A positive number means intake is higher than it was 90 days ago.
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = +77.0 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = +12.7/day
5.Large positive Δ = intake is well above the rate 90 days ago → surging
⇒ Vercel is surging. Intake is higher than it was 90 days ago.
Vercel Open Source
Cooling off
3,027 reports, 936 researchers
-62.5reports/day Δ
+5.0researchers/day
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = -62.5 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = +5.0/day
5.Negative Δ = intake declining vs 90 days ago
⇒ Vercel Open Source is cooling off. Intake is lower than it was 90 days ago.
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = -46.3 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = 0.0/day
5.Negative Δ = intake declining vs 90 days ago
⇒ Wolt is cooling off. Intake is lower than it was 90 days ago.
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = -34.2 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = +0.2/day
5.Negative Δ = intake declining vs 90 days ago
⇒ HackerOne is cooling off. Intake is lower than it was 90 days ago.
Abercrombie & Fitch Bug Bounty
Cooling off
968 reports, 88 researchers
-31.5reports/day Δ
+0.3researchers/day
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = -31.5 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = +0.3/day
5.Negative Δ = intake declining vs 90 days ago
⇒ Abercrombie & Fitch Bug Bounty is cooling off. Intake is lower than it was 90 days ago.
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = +29.5 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = +1.0/day
5.Large positive Δ = intake is well above the rate 90 days ago → surging
⇒ Twilio is surging. Intake is higher than it was 90 days ago.
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = +27.2 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = 0.0/day
5.Large positive Δ = intake is well above the rate 90 days ago → surging
⇒ Arc is surging. Intake is higher than it was 90 days ago.
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = -26.2 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = +0.5/day
5.Negative Δ = intake declining vs 90 days ago
⇒ Elastic is cooling off. Intake is lower than it was 90 days ago.
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = +24.3 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = +1.0/day
5.Large positive Δ = intake is well above the rate 90 days ago → surging
⇒ Stripe is surging. Intake is higher than it was 90 days ago.
Expedia Group Bug Bounty
Surging
1,301 reports, 527 researchers
+18.3reports/day Δ
+1.8researchers/day
1.reports_received_90d is a rolling window, the count of reports in the last 90 days
2.Δ(R90) / Δt = r(now) − r(90 days ago) → this measures the rate difference between now and 90 days ago
3.Measured Δ = +18.3 reports/day between snapshots
4.participants_count (monotonic lifetime): growth = +1.8/day
5.Large positive Δ = intake is well above the rate 90 days ago → surging
⇒ Expedia Group Bug Bounty is surging. Intake is higher than it was 90 days ago.
Resolution velocity
25 programsNet flow = intake rate change minus resolution rate.
U.S. Dept Of Defense
Clearing backlog
32,082 resolved all time, 1,368 in the 90-day window
8.0resolved/day
-9.0net flow/day
1.resolved_report_count = 32,082 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 8.0 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = -9.0/day
⇒ Resolving faster than new intake is growing → clearing backlog.
Adobe
Clearing backlog
8,973 resolved all time, 904 in the 90-day window
6.1resolved/day
-16.7net flow/day
1.resolved_report_count = 8,973 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 6.1 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = -16.7/day
⇒ Resolving faster than new intake is growing → clearing backlog.
MariaDB
Clearing backlog
188 resolved all time, 99 in the 90-day window
3.5resolved/day
-4.7net flow/day
1.resolved_report_count = 188 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 3.5 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = -4.7/day
⇒ Resolving faster than new intake is growing → clearing backlog.
1.resolved_report_count = 3,913 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 2.7 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = -1.7/day
⇒ Resolving faster than new intake is growing → clearing backlog.
Vercel
Falling behind
354 resolved all time, 4,002 in the 90-day window
2.6resolved/day
+74.4net flow/day
1.resolved_report_count = 354 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 2.6 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = +74.4/day
⇒ Intake growing faster than resolution → falling behind.
hostinger
Clearing backlog
1,039 resolved all time, 415 in the 90-day window
2.2resolved/day
-3.5net flow/day
1.resolved_report_count = 1,039 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 2.2 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = -3.5/day
⇒ Resolving faster than new intake is growing → clearing backlog.
Instacart
Clearing backlog
563 resolved all time, 263 in the 90-day window
2.2resolved/day
-2.5net flow/day
1.resolved_report_count = 563 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 2.2 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = -2.5/day
⇒ Resolving faster than new intake is growing → clearing backlog.
Epic Games
Steady
2,622 resolved all time, 1,237 in the 90-day window
2.0resolved/day
-1.0net flow/day
1.resolved_report_count = 2,622 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 2.0 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = -1.0/day
⇒ Resolution roughly matches intake changes → steady state.
Exodus
Clearing backlog
123 resolved all time, 568 in the 90-day window
2.0resolved/day
-14.8net flow/day
1.resolved_report_count = 123 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 2.0 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = -14.8/day
⇒ Resolving faster than new intake is growing → clearing backlog.
Amazon Vulnerability Research Program
Falling behind
2,733 resolved all time, 1,789 in the 90-day window
1.8resolved/day
+6.3net flow/day
1.resolved_report_count = 2,733 (a lifetime counter that only goes up, so its change is the true rate)
2.Resolution rate = Δ(resolved) / Δt = 1.8 reports/day
3.Intake rate change = Δ(reports_received_90d) / Δt (rolling window derivative)
4.Net flow = intake_Δ − resolution_rate = +6.3/day
⇒ Intake growing faster than resolution → falling behind.
SLA accuracy (deduced)
50 programsEstimated from the time between when we first saw the program and when it first thanked a researcher, compared with its stated SLA.
1.Declared SLA threshold_new = 1 days (24h)
2.response_efficiency_pct = 88% (platform-reported SLA compliance)
3.40 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
⇒ The available data suggests triage is close to the SLA limit.
Vercel
Not enough data
SLA: 1d first response, 95% eff., 222 thanked
–deduced triage
3,965est. backlog
1.Declared SLA threshold_new = 1 days (24h)
2.response_efficiency_pct = 95% (platform-reported SLA compliance)
3.222 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
⇒ The available data suggests triage is close to the SLA limit.
1.Declared SLA threshold_new = 1 days (24h)
2.response_efficiency_pct = 84% (platform-reported SLA compliance)
3.971 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
5.Observed first-thank timestamp vs first-metrics-snapshot = 161h actual triage time
6.Declared SLA = 24h vs deduced = 161h → exceeds SLA by 137h
⇒ Actual triage appears to exceed the declared SLA threshold.
1.Declared SLA threshold_new = 1 days (24h)
2.response_efficiency_pct = 79% (platform-reported SLA compliance)
3.318 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
5.Observed first-thank timestamp vs first-metrics-snapshot = 186h actual triage time
6.Declared SLA = 24h vs deduced = 186h → exceeds SLA by 162h
⇒ Actual triage appears to exceed the declared SLA threshold.
1.Declared SLA threshold_new = 1 days (24h)
2.response_efficiency_pct = 93% (platform-reported SLA compliance)
3.11 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
5.Observed first-thank timestamp vs first-metrics-snapshot = 716h actual triage time
6.Declared SLA = 24h vs deduced = 716h → exceeds SLA by 692h
⇒ Actual triage appears to exceed the declared SLA threshold.
1.Declared SLA threshold_new = 1 days (24h)
2.response_efficiency_pct = 79% (platform-reported SLA compliance)
3.267 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
5.Observed first-thank timestamp vs first-metrics-snapshot = 195h actual triage time
6.Declared SLA = 24h vs deduced = 195h → exceeds SLA by 171h
⇒ Actual triage appears to exceed the declared SLA threshold.
1.Declared SLA threshold_new = 2 days (48h)
2.response_efficiency_pct = 95% (platform-reported SLA compliance)
3.232 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
5.Observed first-thank timestamp vs first-metrics-snapshot = 192h actual triage time
6.Declared SLA = 48h vs deduced = 192h → exceeds SLA by 144h
⇒ Actual triage appears to exceed the declared SLA threshold.
Amazon Vulnerability Research Program
Missed
SLA: 1d first response, 58% eff., 1,427 thanked
174hdeduced triage
1,523est. backlog
1.Declared SLA threshold_new = 1 days (24h)
2.response_efficiency_pct = 58% (platform-reported SLA compliance)
3.1,427 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
5.Observed first-thank timestamp vs first-metrics-snapshot = 174h actual triage time
6.Declared SLA = 24h vs deduced = 174h → exceeds SLA by 150h
⇒ Actual triage appears to exceed the declared SLA threshold.
Crypto.com
Missed
SLA: 3d first response, 100% eff., 669 thanked
162hdeduced triage
1,490est. backlog
1.Declared SLA threshold_new = 3 days (72h)
2.response_efficiency_pct = 100% (platform-reported SLA compliance)
3.669 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
5.Observed first-thank timestamp vs first-metrics-snapshot = 162h actual triage time
6.Declared SLA = 72h vs deduced = 162h → exceeds SLA by 90h
⇒ Actual triage appears to exceed the declared SLA threshold.
Vercel Sandbox
Missed
SLA: 1d first response, 90% eff., 60 thanked
220hdeduced triage
1,277est. backlog
1.Declared SLA threshold_new = 1 days (24h)
2.response_efficiency_pct = 90% (platform-reported SLA compliance)
3.60 researchers thanked → cross-ref their total reports to this program
4.Assuming every report from a thanked researcher was triaged gives an upper bound on the triage count
5.Observed first-thank timestamp vs first-metrics-snapshot = 220h actual triage time
6.Declared SLA = 24h vs deduced = 220h → exceeds SLA by 196h
⇒ Actual triage appears to exceed the declared SLA threshold.
Payout fairness
30 programs ±30%+ from peersAverage critical payout compared with the median for programs in the same industry.
1.Industry: Computer Software → 62 programs with critical payout data
2.Industry median critical payout = $4,375 (sorted middle value)
3.Shopify avg_bounty_critical = $102,055 from 41 critical reports
4.Deviation = ($102,055 − $4,375) / $4,375 = +2,233%
⇒ Pays 2,233% more than industry peers.
Vercel Sandbox
+1,043%
Computer Software, 62 peers, 0 critical reports
$50,000pays
$4,375industry median
1.Industry: Computer Software → 62 programs with critical payout data
2.Industry median critical payout = $4,375 (sorted middle value)
3.Vercel Sandbox avg_bounty_critical = $50,000 from 0 critical reports
4.Deviation = ($50,000 − $4,375) / $4,375 = +1,043%
⇒ Pays 1,043% more than industry peers.
Coinbase
+895%
Financial Services & Insurance, 13 peers, 22 critical reports
$100,000pays
$10,050industry median
1.Industry: Financial Services & Insurance → 13 programs with critical payout data
2.Industry median critical payout = $10,050 (sorted middle value)
3.Coinbase avg_bounty_critical = $100,000 from 22 critical reports
4.Deviation = ($100,000 − $10,050) / $10,050 = +895%
⇒ Pays 895% more than industry peers.
Epic Games
+477%
Computer Software, 62 peers, 187 critical reports
$25,250pays
$4,375industry median
1.Industry: Computer Software → 62 programs with critical payout data
2.Industry median critical payout = $4,375 (sorted middle value)
3.Epic Games avg_bounty_critical = $25,250 from 187 critical reports
4.Deviation = ($25,250 − $4,375) / $4,375 = +477%
⇒ Pays 477% more than industry peers.
1.Industry: Computer Software → 62 programs with critical payout data
2.Industry median critical payout = $4,375 (sorted middle value)
3.GitLab avg_bounty_critical = $24,852 from 114 critical reports
4.Deviation = ($24,852 − $4,375) / $4,375 = +468%
⇒ Pays 468% more than industry peers.
1.Industry: Computer Software → 62 programs with critical payout data
2.Industry median critical payout = $4,375 (sorted middle value)
3.Snapchat avg_bounty_critical = $23,000 from 27 critical reports
4.Deviation = ($23,000 − $4,375) / $4,375 = +426%
⇒ Pays 426% more than industry peers.
CoinSpot
+398%
Financial Services & Insurance, 13 peers, 4 critical reports
$50,000pays
$10,050industry median
1.Industry: Financial Services & Insurance → 13 programs with critical payout data
2.Industry median critical payout = $10,050 (sorted middle value)
3.CoinSpot avg_bounty_critical = $50,000 from 4 critical reports
4.Deviation = ($50,000 − $10,050) / $10,050 = +398%
⇒ Pays 398% more than industry peers.
1.Industry: Computer Software → 62 programs with critical payout data
2.Industry median critical payout = $4,375 (sorted middle value)
3.Slack avg_bounty_critical = $16,333 from 61 critical reports
4.Deviation = ($16,333 − $4,375) / $4,375 = +273%
⇒ Pays 273% more than industry peers.
Stripe
+267%
Internet & Online Services, 21 peers, 36 critical reports
$14,495pays
$3,950industry median
1.Industry: Internet & Online Services → 21 programs with critical payout data
2.Industry median critical payout = $3,950 (sorted middle value)
3.Stripe avg_bounty_critical = $14,495 from 36 critical reports
4.Deviation = ($14,495 − $3,950) / $3,950 = +267%
⇒ Pays 267% more than industry peers.
1.Industry: Computer Software → 62 programs with critical payout data
2.Industry median critical payout = $4,375 (sorted middle value)
3.PayPal avg_bounty_critical = $15,350 from 165 critical reports
4.Deviation = ($15,350 − $4,375) / $4,375 = +251%
⇒ Pays 251% more than industry peers.
Ghost programs
20 programsTaking reports but not resolving them.
1.reports_received_90d = 1,810 → the program is taking reports
2.resolved_report_count = 0 (lifetime)
3.last_report_resolved_at = never
⇒ The program takes reports but doesn't resolve them, so submitting here is probably not worth your time.
1.reports_received_90d = 1,628 → the program is taking reports
2.resolved_report_count = 45 (lifetime)
3.last_report_resolved_at = 100 days ago
⇒ The program takes reports but doesn't resolve them, so submitting here is probably not worth your time.
d-you App & German EUDI Wallet Ecosystem
Ghost
Hackerone, Never resolved
1,090reports in
0ever resolved
1.reports_received_90d = 1,090 → the program is taking reports
2.resolved_report_count = 0 (lifetime)
3.last_report_resolved_at = never
⇒ The program takes reports but doesn't resolve them, so submitting here is probably not worth your time.
1.reports_received_90d = 398 → the program is taking reports
2.resolved_report_count = 0 (lifetime)
3.last_report_resolved_at = never
⇒ The program takes reports but doesn't resolve them, so submitting here is probably not worth your time.
1.reports_received_90d = 311 → the program is taking reports
2.resolved_report_count = 0 (lifetime)
3.last_report_resolved_at = never
⇒ The program takes reports but doesn't resolve them, so submitting here is probably not worth your time.
1.reports_received_90d = 301 → the program is taking reports
2.resolved_report_count = 0 (lifetime)
3.last_report_resolved_at = never
⇒ The program takes reports but doesn't resolve them, so submitting here is probably not worth your time.
1.reports_received_90d = 294 → the program is taking reports
2.resolved_report_count = 6 (lifetime)
3.last_report_resolved_at = 115 days ago
⇒ The program takes reports but doesn't resolve them, so submitting here is probably not worth your time.
1.reports_received_90d = 224 → the program is taking reports
2.resolved_report_count = 1 (lifetime)
3.last_report_resolved_at = 121 days ago
⇒ The program takes reports but doesn't resolve them, so submitting here is probably not worth your time.
Add to the data
Every review makes these numbers more accurate.
Rate a program you've worked with, good or bad.