Duplicados en bug bounty: cómo detectarlos y comunicarlos correctamente

Por Kike Gandia · Co-Fundador y CEO, OSCP

Un reporte duplicado en un programa de bug bounty es un hallazgo que ya ha sido reportado previamente por otro investigador y está en proceso de resolución. Gestionarlos bien —con transparencia y equidad— es fundamental para mantener la confianza de los researchers y la integridad del programa.

Por qué los duplicados son inevitables en bug bounty

En un programa de bug bounty activo, especialmente cuando es público, es completamente normal que varios investigadores encuentren la misma vulnerabilidad al mismo tiempo o con pocas horas de diferencia. Algunos tipos de vulnerabilidades son mucho más fáciles de encontrar —XSS en formularios públicos, IDOR en parámetros obvios— y atraen a muchos researchers a la vez.

La tasa de duplicados varía entre el 10% y el 40% del total de reportes en programas públicos maduros. En programas privados, la tasa es menor porque hay menos researchers.

Cómo detectar un duplicado durante el triage

La detección de duplicados requiere un proceso sistemático:

1. Busca en el histórico de reportes activos y cerrados: por tipo de vulnerabilidad, URL afectada, parámetro vulnerable y tipo de payload.
2. Compara el impacto: dos reportes pueden describir vulnerabilidades diferentes en el mismo endpoint.
3. Verifica la fecha: el primer reporte en llegar tiene prioridad, independientemente de la calidad del informe.
4. Considera la calidad del reporte: si el primer reporte es tan pobre que no permitió la validación y el segundo lo aclara, evalúa si merece reconocimiento.

En programas de alto volumen, herramientas como las que ofrecen HackerOne y Bugcrowd detectan posibles duplicados automáticamente usando similitud semántica.

Cómo comunicar un duplicado al investigador

La comunicación de un duplicado es uno de los momentos más delicados en la gestión de un programa. Los investigadores saben que los duplicados pasan, pero necesitan sentir que el proceso es justo.

Elementos de una buena comunicación de duplicado:
• Confirma que el reporte ha sido recibido y revisado.
• Explica que la vulnerabilidad ya estaba siendo investigada/resuelta.
• Da el mayor contexto posible sobre el estado del reporte original: ¿ya está parcheado? ¿En proceso?
• Agradece el trabajo del investigador aunque no reciba bounty.
• Si el programa tiene política de reconocimiento de duplicados, aplícala.

Lo que nunca debes hacer: cerrar como duplicado sin dar ningún contexto al investigador.

Política de duplicados: cómo definirla en las reglas del programa

Incluye en las reglas de tu programa una sección clara sobre duplicados:

Define qué se considera duplicado: misma vulnerabilidad en el mismo endpoint, no solo mismo tipo de vulnerabilidad.
Establece si hay reconocimiento parcial para el segundo reporter: algunos programas dan un porcentaje del bounty o reconocimiento en el Hall of Fame al segundo reporter si el reporte contribuye a la resolución.
Define el plazo en que un reporte se considera "nuevo" aunque sea la misma vulnerabilidad: si ya está parcheada y alguien la reporta, ¿es un duplicado o un bypass del parche?

Esta claridad en las reglas previene conflictos y establece expectativas correctas.

FAQ

¿Debo pagar al segundo investigador que reporta la misma vulnerabilidad?

La práctica estándar es que solo el primer reporte recibe el bounty completo. Sin embargo, algunos programas dan un reconocimiento parcial (10-25% del bounty) al segundo reporter si el reporte es de alta calidad y contribuye a la resolución. Esto es una decisión de política del programa.

¿Qué pasa si el segundo reporte tiene más detalle o mejor PoC que el primero?

El segundo reporte no desplaza al primero en cuanto a prioridad de bounty, pero sí puede contribuir a la resolución. En ese caso, lo más justo es reconocerlo en el changelog o en el Hall of Fame, y considerar un pago simbólico si el programa tiene presupuesto para ello.

¿Cuánto tiempo debo mantener un reporte como "duplicado activo" antes de cerrarlo?

Un reporte marcado como duplicado debe cerrarse cuando se cierra el reporte original: cuando la vulnerabilidad está parcheada y verificada. Mantener los reporters informados del estado del original (de forma genérica, sin revelar detalles del reporte de otro investigador) es una buena práctica.