Falsos positivos en bug bounty: cómo reducirlos sin rechazar reportes válidos

Por Kike Gandia · Co-Fundador y CEO, OSCP

Un falso positivo en un programa de bug bounty es un reporte que describe un comportamiento que parece una vulnerabilidad pero no lo es: comportamiento diseñado del sistema, problemas de configuración del entorno del researcher, o vulnerabilidades teóricas sin impacto práctico en tu entorno. Gestionarlos mal —rechazando sin argumentos técnicos o ignorando sin respuesta— es una de las formas más rápidas de destruir la reputación de tu programa.

Por qué los falsos positivos son inevitables en cualquier programa

Los investigadores de seguridad trabajan con información limitada sobre tu entorno. No conocen tus controles compensatorios, tu configuración interna ni el contexto de negocio detrás de cada decisión de diseño. Es razonable que reporten cosas que desde dentro no parecen vulnerabilidades.

Las categorías más comunes de falsos positivos:
• Comportamiento diseñado interpretado como vulnerabilidad (rate limiting agresivo, mensajes de error sin datos sensibles).
• Vulnerabilidades que requieren condiciones imposibles en tu entorno (acceso físico, privilegios muy elevados).
• Hallazgos fuera de scope reportados por desconocimiento de las reglas.
• Configuraciones de seguridad estrictas que parecen fallos desde fuera.

Cómo responder a un falso positivo sin dañar la relación con el investigador

La respuesta a un falso positivo debe cumplir tres criterios: ser técnicamente sólida, ser rápida y ser respetuosa.

Estructura recomendada:
1. Agradece el tiempo del investigador.
2. Explica técnicamente por qué no es una vulnerabilidad válida en tu entorno.
3. Si es un comportamiento diseñado, explica el razonamiento de seguridad detrás.
4. Si es fuera de scope, señala exactamente qué parte de las reglas lo excluye.
5. Invita al investigador a seguir participando.

Lo que nunca debes hacer: rechazar sin explicación técnica. "No válido" sin contexto es la respuesta que hace que los mejores researchers abandonen tu programa para siempre.

Cómo reducir la tasa de falsos positivos desde el diseño del programa

Muchos falsos positivos son consecuencia de un scope mal definido o unas reglas ambiguas. Mejoras preventivas:

Scope específico y detallado: lista exacta de dominios, URLs y APIs en alcance. Evita formulaciones genéricas.
Ejemplos de vulnerabilidades fuera de scope: si hay tipos de hallazgos que recibes frecuentemente pero no son válidos, listarlos explícitamente.
FAQ del programa: preguntas frecuentes sobre qué se considera válido.
Entorno de pruebas: si puedes ofrecer un entorno de staging a los researchers, reduces drásticamente los reportes basados en comportamientos de producción.
Documentación de seguridad pública: publicar tu política de headers de seguridad o configuraciones reduce los reportes sobre "missing security headers" que en realidad están configurados correctamente.

El coste real de los falsos positivos en tu programa

Cada falso positivo tiene un coste operativo directo: el tiempo del analista que lo revisa y el tiempo que tarda en comunicar el rechazo. En programas con alta tasa de falsos positivos (>60%), el equipo puede estar dedicando más tiempo a gestionar reportes inválidos que a trabajar en las vulnerabilidades reales.

El coste indirecto es mayor: los investigadores de calidad llevan un registro mental de los programas donde sus reportes reciben respuestas pobres. Si tu tasa de rechazo es alta pero las explicaciones son malas, los mejores researchers se van a programas que les tratan mejor.

FAQ

¿Cuál es una tasa de falsos positivos normal en un bug bounty?

Depende del sector y la madurez del programa. En programas bien gestionados con scope claro, la tasa de falsos positivos suele estar entre el 30% y el 50% del total de reportes recibidos. En programas nuevos o con scope ambiguo, puede superar el 70%. El objetivo no es cero falsos positivos, sino gestionarlos bien y reducirlos progresivamente.

¿Cómo diferencio un falso positivo de una vulnerabilidad que no entiendo?

Si tienes dudas sobre si un reporte es un falso positivo, la respuesta segura es reproducir el ataque. Si no puedes reproducirlo con los pasos del investigador, pide más información antes de rechazarlo. Rechazar sin haber intentado reproducir el hallazgo es un error habitual que daña la reputación del programa.

¿Puedo marcar como inválido un reporte sin pagar si no lo puedo reproducir?

Sí, pero con cuidado. Si el investigador proporciona evidencia clara (capturas, tokens reales, datos de la respuesta del servidor) y no puedes reproducirlo, lo correcto es comunicarlo y pedir pasos más detallados. Solo si después de un intercambio razonado sigue sin ser reproducible está justificado cerrarlo como no válido.