Bug bounty program metrics: the KPIs that actually matter
By Kike Gandia · Co-Founder & CEO, OSCP
Measuring the success of a bug bounty program by the number of reports received is like measuring the quality of a pentest by the thickness of the report. What matters isn't volume — it's quality: how many real vulnerabilities were found, how quickly they were handled, and what impact they had on the company's security posture.
Volume and report quality KPIs
- Reports received per month: trend (growing, declining, stable). A declining trend may signal that researchers are losing interest in the program.
- Validation rate: percentage of reports that turn out to be real vulnerabilities. Target: >30%. If it's very low (<15%), there's a scope or researcher-quality problem.
- Severity distribution: how many criticals, highs, mediums, lows. A healthy program should find a broad spectrum.
- False positive rate: complementary to the validation rate. If it exceeds 70%, review your scope and rules.
- Duplicate rate: normal range is 10-40% for public programs.
Time and triage efficiency KPIs
- TTFR (Time To First Response): time from receiving the report to the first acknowledgment sent to the researcher. Standard: under 24 hours on business days, under 48 hours including weekends.
- TTV (Time To Validate): time from receipt to the full technical verdict. Standard: under 7 days for all reports, under 24 hours for criticals.
- TTR (Time To Resolution): time from receipt to a verified patch. This KPI depends more on the development team than on triage, but it measures the effectiveness of the whole process.
These three timers together (TTFR, TTV, TTR) define the researcher's experience. If they're high, your best researchers will stop participating.
Security impact KPIs
- Critical vulnerabilities found per quarter: the most direct indicator of the program's value.
- Estimated cost avoided: calculate the cost of a breach based on the critical vulnerabilities found. Helps justify the program to leadership.
- Scope coverage: what percentage of the scope have researchers actually explored? A poorly explored scope may indicate researchers lack sufficient test credentials or the scope isn't attractive.
- Bounties paid by severity: does the payout distribution reflect the severity distribution? If you're paying a lot for lows and little for criticals, adjust your bounty table.
Researcher community health KPIs
- Active researchers per month: how many unique researchers submitted at least one report.
- Researcher retention rate: are the same researchers still participating month over month? High churn signals problems with the program experience.
- Researchers with valid reports: how many of the active researchers found at least one valid vulnerability.
- Researcher NPS (if you measure it): some platforms let you survey researchers about their experience. Very revealing.
FAQ
How often should I review the program's metrics?
A real-time metrics dashboard is ideal for the operational team. For strategic reviews, a monthly report is enough. If the program is small (fewer than 20 reports a month), biweekly or monthly reviews work fine.
What TTFR should my researchers see for the program to stay attractive?
The best programs in the market keep TTFR under 4-8 hours on business days. Going over 48 hours for the first acknowledgment is a factor that makes researchers flag the program as low priority. Response speed is one of the most important reputation factors.
How do I measure the ROI of my bug bounty program?
Compare the total program cost (management + bounties) against the estimated cost of the vulnerabilities found if they had been exploited. Use the average cost of a data breach in your industry as a benchmark (IBM's Cost of a Data Breach is the most widely cited study). Most programs show a positive ROI once they find at least one critical vulnerability per year.
Related service
bug bounty program management service