Los cazarrecompensas son una figura misteriosa. En la literatura, el cine y hasta los videojuegos, siempre manejan una ambivalencia entre la ambición del dinero manchado y la justicia allí donde el Estado no da una respuesta. Y tienen un correlato en el mundo de los hackers: los “bug hunters”, o cazadores de vulnerabilidades.

Un bug bounty es una práctica mediante la cual se les paga a investigadores y hackers por descubrir problemas en sistemas antes de que los encuentren los atacantes maliciosos. El concepto, inventado en los 90 por Netscape (hoy Mozilla), es hoy usado por gigantes como Microsoft, Google o Facebook dan recompensas por bugs, que pueden ser errores en código fuente, vulnerabilidades u otras “puertas traseras” (backdoors) que habiliten a un ataque. Hoy, OpenAI paga hasta US$ 100.000 por cada vulnerabilidad crítica, lo que hace que muchos hunters vivan de cazar bugs.

El concepto es simple pero disruptivo: invertir en conocimiento “ofensivo” para mejorar las defensas de tu organización. En lugar de esperar que un atacante externo te explote una falla, se contrata a la comunidad hacker para que te la encuentre y, además, se les paga por ello. Es una lógica directa de mercado, en la que quien encuentre más valor para el negocio (en este caso, vulnerabilidades críticas), se lleva una recompensa proporcional.

El bug bounty se puede enmarcar en la creciente evolución del mundo de la ciberseguridad y su consolidación como industria. Las organizaciones suelen comenzar con escaneos automatizados de vulnerabilidades, herramientas que revisan configuraciones de nuestros sistemas. Luego incorporan “pentesting” (penetration tests), es decir, pruebas de intrusión planificadas por consultoras que ofrecen estos servicios. Y, un paso más adelante, nos encontramos con el “Red Teaming”: un equipo rojo que se dedica a atacar para que otros se encarguen de “fixear”. @@FIGURE@@

Hacer un bounty no es “tener un bounty” de manera automática, vale aclarar. Muchas organizaciones confunden marketing con bounties: afirman tener un Red Team cuando sólo hacen pruebas básicas, o dicen tener un programa de bug bounty cuando en realidad no hay reglas, o un alcance definido o mecanismos de respuesta.

Me refiero a que un programa real demanda tres pilares: un “scope” + “reglas” claras, un proceso de triage sólido y la capacidad de remediación efectiva.

El scope define qué sistemas pueden ser testeados, con qué límites y qué tipo de hallazgos son válidos. Sin un scope bien definido, los reportes quedan en una nebulosa. Aquí entra otro actor clave: los triagers, profesionales que analizan cada reporte, validan, evalúan si es reproducible y si merece recompensa. Sin un equipo de triage competente, los hallazgos pueden perderse.

Un buen ejemplo en Argentina lo hicimos en EkoParty 2024 con Banco Galicia, cuando abrimos un bug bounty público dentro del evento. Hackers de la comunidad se anotaron, interactuaron con el equipo de seguridad de la entidad y con los triagers de YesWeHack y recibieron recompensas por vulnerabilidades válidas. Participaron más de 100 hunters globales.

Hay dos modelos: bug bounty cerrado y público. El primero invita solo a investigadores conocidos o preseleccionados, el segundo abre la puerta a toda la comunidad y, en general, se hace en plataformas conocidas como HackerOne o la misma YesWeHack. Con sus pros y contras, ya que el cerrado permite control y foco, mientras que el público amplía el espectro de talento. Elegir uno u otro demanda entender la madurez propia de nuestra organización para enfrentar los potenciales escenarios.

Después del triage viene la pregunta más importante: ¿cuánto se tarda en resolver las vulnerabilidades? Encontrar bugs sin parcharlos rápidamente puede dejar sistemas expuestos más tiempo del deseado. Medir no sólo cuántos bugs aparecen, sino cuánto se tarda en arreglarlos, es tan importante como el propio programa.

Así, mientras avanzamos hacia modelos más colaborativos de seguridad, pagarles a los hackers puede verse, hoy, como una fortaleza de nuestra organización.

El horizonte más ambicioso no es el bug bounty en sí mismo, sino la seguridad desde el diseño: cuando la seguridad está integrada desde la concepción de un producto o servicio, cuando cada línea de código nace con controles y cada arquitectura se piensa con mentalidad defensiva, el bounty deja de ser reactivo para ser una herramienta de validación.

Un programa bien diseñado ahorra varios pasos y dolores de cabeza a futuro. Pero llegar hasta ese punto es como subir la escalera de la que hablaba el filósofo austríaco Ludwing Wittgenstein: hay que subir para luego patearla.

Los pasos del bug bounty son esa escalera que hay que subir para poder ver el paisaje completo, entenderlo, dominarlo, pero no eternizarlo: hay que internalizar el aprendizaje para que lo que hoy resuelven los bug hunters mañana salga ya resuelto desde el diseño.

No pagar más bounties sino tener cada vez menos hallazgos críticos.