Programa de Recompensas Cancelado

Por qué he decidido cancelar mi programa de Bug Bounty

Después de un año completo manteniendo activo un programa de recompensas por bugs en Monitorator, he tomado la difícil decisión de cancelarlo. Como desarrollador indie que maneja este proyecto en solitario, creo que mi experiencia puede resonar con otros que están en la misma situación.

El contexto: un side project con buenas intenciones

Monitorator es mi proyecto personal. Lo desarrollo en mi tiempo libre, me encargo de todo: el código, el marketing, el soporte, las finanzas. Como muchos desarrolladores indie, la seguridad siempre ha sido una preocupación, pero los recursos son limitados.
Implementar un programa de bug bounty parecía la solución perfecta: obtener ayuda externa para encontrar vulnerabilidades sin tener que contratar un equipo de seguridad. En teoría, brillante. En la práctica, se convirtió en mi peor pesadilla.

El tsunami desde el primer día

A la semana de publicar el archivo security.txt, mi tranquilo side project se convirtió en un campo de batalla. Aparentemente, hay sistemas automatizados rastreando constantemente Internet en busca de estos archivos, y cuando encuentran uno nuevo, comienza el asedio.
De repente, estaba dedicando más tiempo a gestionar reportes falsos que a desarrollar nuevas funcionalidades. Para alguien que hace esto en su tiempo libre, fue devastador.

Los números de un año

Durante todo este tiempo:

• Reportes recibidos: Cientos
• Vulnerabilidades reales: Una (1)
• Cuentas spam eliminadas: Más de 50 en el peor mes
• Horas perdidas: Incontables respondiendo correos sin sentido

Lo más frustrante: incluso el único pago legítimo se convirtió en un problema. Después de semanas esperando, recibí la factura y la pagué inmediatamente. Luego mi gestor me informó que no era válida. Cuando pedí una factura correcta, el investigador desapareció, dejándome con un lío fiscal.

El patrón que destruye proyectos personales

He identificado un ciclo tóxico que cualquier desarrollador indie reconocerá:

• Lunes: Recibes un reporte vago que podría aplicarse a cualquier web
• Martes: Respondes educadamente explicando por qué no es una vulnerabilidad
• Miércoles: Recibes una respuesta más agresiva con argumentos sin sentido
• Jueves: El intercambio continúa, robándote tiempo de desarrollo
• Viernes: En lugar de lanzar esa nueva feature, sigues en el ping-pong de emails

Multiplica esto por varios "investigadores" simultáneos y entenderás por qué mi proyecto casi se paraliza.

Casos reales que desafían toda lógica

"Borrado crítico de cuentas"

Alguien creó una cuenta test (nombre contenía "test"), y desde el mismo email me pidió eliminarla. Era una cuenta de menos de 6 horas, sin contenido ni suscripción. Como administrador, la eliminé como haría con cualquier spam. Luego reclamó €500 alegando vulnerabilidad crítica porque había borrado "su" cuenta cuando él mismo la pidió.

"Falta de límite en intentos de login"

Bombardearon el formulario de login con miles de peticiones automatizadas. Alegaron tener "contraseñas de usuarios" (imposible, uso magic links sin contraseñas). El único impacto real: me cuesta dinero cada email enviado, pero no es un problema de seguridad.

"Acceso de administrador con emails corporativos"

Reportaron que registrarse con @monitorator.com da acceso de administrador (totalmente falso). Cualquier registro entra como usuario básico sin permisos especiales, y sin acceso al email no puedes hacer login por los magic links.

"Redirección maliciosa (Open Redirect)"

Un usuario puso links externos en campos de su propio perfil (que solo él ve) y lo reportó como vulnerabilidad. Esto no es un open redirect - es contenido controlado por el propio usuario en su espacio personal.

"Tokens de sesión persistentes"

Después de varios emails, enviaron un video "demostrando" que el logout no funcionaba. Al revisarlo, vi que hacían mal el logout intencionalmente. Cuando les señalé el error paso a paso, admitieron que "tal vez" no lo habían hecho bien.

"Race condition en proyectos"

Violando las reglas del programa (no hacer peticiones concurrentes), intentaron crear múltiples proyectos simultáneamente. Puede ser un problema de lógica de negocio menor, pero no es seguridad. Me amenazaron cuando rechacé el pago.

El único bug real: "Exposición de información"

Nombres de usuario visibles en URLs cuando no deberían. Esperé casi un mes por la factura, cuando llegó la pagué inmediatamente. Después mi gestor me informó que la factura no era válida/real y necesitaba una correcta para temas fiscales. Cuando pedí al investigador una factura válida, desapareció. Me quedé con el problema fiscal y el pago ya realizado.

El factor IA: cuando los bots responden a los bots

Mi sensación es que la inteligencia artificial ha empeorado exponencialmente la situación. Recibo correos claramente generados por IA, y cuando respondo, las contestaciones también parecen generadas automáticamente. Es un ping-pong absurdo donde:

• Los reportes iniciales son plantillas genéricas con modificaciones mínimas
• Mis respuestas técnicas reciben contraargumentos vagos que ignoran completamente mis puntos
• Las conversaciones pierden coherencia después de 2-3 intercambios
• En muchos casos, las respuestas ni siquiera tienen sentido en el contexto

Además, hay bots (con o sin IA) que ejecutan las pruebas de seguridad más básicas contra cualquier web. En mi caso, al usar software establecido y bien mantenido, estos "bugs" ya están solventados desde la base. Lo único que consiguen estos ataques automatizados es:

• Múltiples solicitudes concurrentes desde varias IPs
• Picos de CPU superiores al 80%
• Consumo excesivo de memoria RAM
• Navegación agresiva por todas las URLs que encuentran

Son básicamente ataques de denegación de servicio disfrazados de "investigación de seguridad".

Una conclusión inesperadamente positiva

Irónicamente, este año de tortura me ha dado algo valioso: confirmación de que mi software es seguro.
Si de casi 200 reportes solo uno era real (una mala configuración menor en URLs de perfil), puedo concluir que:

• Mi forma de trabajar produce software bastante seguro
• Las decisiones arquitectónicas que he tomado son sólidas
• El nivel de "pruebas" que están haciendo es tan bajo que me da confianza

Si estos son los ataques que intentan, y solo encontraron una configuración menor mal puesta, me pregunto qué están encontrando en otros proyectos. La calidad de estas "pruebas de seguridad" es tan pobre que, paradójicamente, me han confirmado que estoy haciendo las cosas bien.

El verdadero coste para un desarrollador indie

Cuando manejas todo tú solo, cada hora cuenta. El impacto real ha sido:

• Desarrollo paralizado: Las horas dedicadas a responder reportes falsos son horas que no dedico a mejorar el producto
• Burnout acelerado: La sensación constante de ser manipulado mientras intentas mantener la profesionalidad
• Motivación destruida: Ver cómo tu proyecto de pasión se convierte en una fuente de estrés constante
• Problemas legales: Incluso cuando intentas hacer las cosas bien, terminas con líos fiscales

Mi nueva aproximación

He cancelado el programa público de recompensas definitivamente. Mi enfoque ahora es:

• Canal abierto: Mantengo [email protected] para reportes genuinos, pero sin recompensas predefinidas
• Sin obligaciones: Si alguien reporta algo real y se comunica profesionalmente, podría considerar una compensación, pero sin compromiso alguno
• Código seguro: Continúo enfocándome en escribir código seguro desde el principio, como siempre he hecho
• Aprendizaje continuo: Sigo aprendiendo de otros proyectos indie sobre mejores prácticas de seguridad, rendimiento y protección de datos

He quedado profundamente desencantado con los programas de recompensas y todas sus consecuencias. No volveré a implementar uno.

Consejos para otros desarrolladores indie

Si estás considerando un bug bounty para tu side project:

• Piénsalo tres veces: El coste en tiempo y salud mental puede matar tu proyecto
• Si lo haces: Sé ultra-específico sobre qué aceptas como vulnerabilidad válida
• Prepárate para el spam: Tendrás bots desde el día uno
• Alternativa recomendada: Intercambia revisiones de seguridad con otros desarrolladores de confianza
• Protege tu tiempo: Es tu recurso más valioso como indie

Reflexión final

Los bug bounties nacieron para mejorar la seguridad de Internet. Es triste ver cómo se han convertido en un vector de ataque contra proyectos pequeños.
A los investigadores legítimos: sé que existís y valoro vuestro trabajo. Lamento que otros hayan corrompido el sistema.
A quienes ven los side projects como blancos fáciles: están matando la innovación indie. Cada desarrollador que abandona su proyecto por vuestra culpa es una idea menos en el mundo.

El camino continúa

Monitorator seguirá adelante, más fuerte y con las lecciones aprendidas. A veces, decir "no más" es la decisión correcta para proteger aquello que construyes con pasión.
Si eres un desarrollador indie en situación similar, no estás solo. Protege tu tiempo, tu energía y tu proyecto. Son demasiado valiosos para desperdiciarlos en quienes no respetan tu trabajo.

Robert Menetray
Desarrollador Indie y creador de Monitorator
Septiembre 2025