Métricas para programas de bug bounty: los KPIs que realmente importan

Por Kike Gandia · Co-Fundador y CEO, OSCP

Medir el éxito de un programa de bug bounty por el número de reportes recibidos es como medir la calidad de un pentesting por el grosor del informe. Lo que importa no es el volumen, sino la calidad: cuántas vulnerabilidades reales se encontraron, con qué rapidez se gestionaron y qué impacto tuvieron en la postura de seguridad de la empresa.

KPIs de volumen y calidad de reportes

Reportes recibidos por mes: tendencia (creciente, decreciente, estable). Una tendencia decreciente puede indicar que los researchers están perdiendo interés en el programa.
Tasa de validación: porcentaje de reportes que resultan ser vulnerabilidades reales. Objetivo: >30%. Si es muy baja (<15%), hay un problema de scope o de calidad de los researchers.
Distribución de severidades: cuántos críticos, altos, medios, bajos. Un programa saludable debería encontrar un espectro amplio.
Tasa de falsos positivos: complementaria a la tasa de validación. Si supera el 70%, revisa el scope y las reglas.
Tasa de duplicados: normal entre el 10-40% en programas públicos.

KPIs de tiempo y eficiencia del triage

TTFR (Time To First Response): tiempo desde la recepción del reporte hasta el primer acuse de recibo al investigador. Estándar: menos de 24 horas en días laborables, menos de 48 horas incluyendo fin de semana.
TTV (Time To Validate): tiempo desde la recepción hasta el veredicto técnico completo. Estándar: menos de 7 días para todos los reportes, menos de 24 horas para críticos.
TTR (Time To Resolution): tiempo desde la recepción hasta el parche verificado. Este KPI depende más del equipo de desarrollo que del triage, pero mide la eficacia del proceso completo.

Estos tres tiempos juntos (TTFR, TTV, TTR) definen la experiencia del investigador. Si son altos, los mejores researchers dejarán de participar.

KPIs de impacto de seguridad

Vulnerabilidades críticas encontradas por trimestre: el indicador más directo del valor del programa.
Coste evitado estimado: calcula el coste de una brecha con las vulnerabilidades críticas encontradas. Ayuda a justificar el programa ante dirección.
Cobertura del scope: ¿qué porcentaje del scope ha sido explorado por los researchers? Un scope poco explorado puede indicar que los investigadores no tienen suficientes credenciales de prueba o que el scope no es atractivo.
Bounties pagados por severidad: ¿la distribución de pagos refleja la distribución de severidades? Si pagas mucho en bajos y poco en críticos, ajusta la tabla de bounties.

KPIs de salud de la comunidad de researchers

Researchers activos por mes: cuántos investigadores únicos han enviado al menos un reporte.
Tasa de retención de researchers: ¿los mismos researchers siguen participando mes a mes? Una alta rotación indica problemas de experiencia del programa.
Researchers con reportes válidos: cuántos de los activos han encontrado al menos una vulnerabilidad válida.
NPS de researchers (si lo mides): algunas plataformas permiten encuestar a los investigators sobre su experiencia. Muy revelador.

FAQ

¿Con qué frecuencia debería revisar las métricas del programa?

Un dashboard de métricas en tiempo real es ideal para el equipo operativo. Para revisiones estratégicas, un informe mensual es suficiente. Si el programa es pequeño (menos de 20 reportes al mes), puede ser quincenal o mensual.

¿Qué TTFR deberían tener mis investigadores para que el programa sea atractivo?

Los mejores programs del mercado tienen TTFR inferior a 4-8 horas para días laborables. Superar las 48 horas en el primer acuse de recibo es un factor que hace que los researchers marquen el programa como de baja prioridad. La rapidez de respuesta es uno de los factores de reputación más importantes.

¿Cómo mido el ROI de mi programa de bug bounty?

Compara el coste total del programa (gestión + bounties) con el coste estimado de las vulnerabilidades encontradas si hubieran sido explotadas. Usa como referencia el coste medio de una brecha de datos en tu sector (IBM Cost of a Data Breach es el estudio más citado). La mayoría de los programas tienen un ROI positivo cuando encuentran al menos una vulnerabilidad crítica al año.