Cybersecurity9 de junio de 202610 min read

Bug bounty vs pentest: ¿cuál necesita primero su empresa?

La mayoría de los equipos elige primero el modelo equivocado de seguridad ofensiva y lo paga dos veces. Así funcionan de verdad los pentests y los bounties, dónde se rompe cada uno y el orden que acumula resultados.

Por Innovation T Team


Tienen presupuesto para una sola iniciativa seria de seguridad ofensiva este año, y dos bandos ruidosos diciéndoles qué contratar. Uno sostiene que la prueba de intrusión es la base profesional. El otro, que los programas de bug bounty son la forma en que las empresas modernas encuentran vulnerabilidades reales. Los dos tienen parte de razón, los dos se equivocan para muchos equipos, y el orden que elijan importa más que la elección en sí.

Dos modelos, mecánicamente distintos

Quiten el marketing y quedan dos máquinas completamente diferentes. Confundirlas es la razón por la que hay equipos pagando costos de triaje de bounty por hallazgos que un pentester junior habría detectado el primer día.

Qué es realmente un pentest

Un pentest es un ejercicio con alcance definido y tiempo acotado. Un equipo pequeño (a menudo uno o dos analistas) ataca un objetivo concreto durante una ventana concreta, normalmente de una a tres semanas, siguiendo una metodología como PTES o la guía OWASP Web Security Testing Guide. Ustedes reciben:

  • Un alcance definido: hosts específicos, aplicaciones, APIs, rangos de IP, a veces una cuenta cloud o un segmento de red interna.
  • Cobertura metódica: reconocimiento, mapeo, pruebas de autenticación y sesión, controles de autorización sobre cada rol, clases de inyección, abuso de lógica de negocio, y después explotación y postexplotación dentro de reglas de compromiso acordadas.
  • Un informe con pasos de reproducción, severidades (normalmente CVSS más criterio contextual) y guía de remediación.
  • Una ventana de retest en la que se verifican las correcciones.

La propiedad clave: la cobertura es sistemática. Un analista competente recorre toda la superficie de ataque del alcance, incluidas las partes aburridas que nadie cazaría por dinero. Va a probar cada rol contra cada endpoint buscando fallos de autorización, la clase de bug que tratamos a fondo en nuestra guía de seguridad de APIs, porque la metodología lo exige, no porque pague bien.

Qué es realmente un bug bounty

Un bounty es una oferta permanente: un alcance publicado, una tabla de recompensas y unas reglas, alojado en una plataforma como HackerOne, Bugcrowd o Intigriti, o gestionado por cuenta propia. Cientos o miles de investigadores independientes pueden mirar sus activos cuando quieran. Ustedes pagan por cada vulnerabilidad aceptada, única y dentro del alcance.

La propiedad clave: la cobertura es económica, no sistemática. Los investigadores van adonde están el dinero y las probabilidades. Los objetivos populares reciben una avalancha sobre unas pocas clases bien pagadas (cadenas de account takeover, SSRF hacia metadatos cloud, IDOR sobre objetos sensibles) mientras subsistemas enteros quedan meses sin tocar porque parecen poco rentables. Nadie les debe cobertura. Nadie firma un contrato de servicios.

En qué es genuinamente bueno cada modelo

El pentest gana cuando necesitan

  • Garantías y evidencia. Los auditores, los clientes enterprise y marcos como SOC 2, ISO 27001 o, en España, el Esquema Nacional de Seguridad quieren un informe de una firma con nombre y metodología. Un programa de bounty no responde un cuestionario de due diligence, y si venden a banca o fintech en América Latina, los equipos de riesgo de sus clientes van a pedir exactamente lo mismo. Si el motor es el cumplimiento, empiecen por qué exige realmente SOC 2.
  • Cobertura de la superficie sin glamur. Redes internas, clientes pesados, ese panel de administración detrás de la VPN, un Active Directory mal configurado. Los investigadores no pueden llegar ahí y, en general, tampoco se molestarían.
  • Profundidad en lógica de negocio. Un analista que dedica tres días a entender su flujo de facturación va a encontrar el bug del reembolso con cantidad negativa. Un investigador de paso, normalmente no.
  • Una factura predecible. Tarifa fija, fechas conocidas, entregable conocido.

El bounty gana cuando necesitan

  • Presión continua. Ustedes despliegan a diario. Un pentest es una fotografía; su superficie de ataque es un video. Un bounty significa que cada despliegue puede estar siendo observado.
  • Diversidad de técnica. Mil investigadores traen mil cadenas de herramientas, granjas de dispositivos raros, peculiaridades oscuras de navegadores y cadenas de explotación novedosas que ninguna firma mantiene en plantilla.
  • Señal realista sobre su postura externa. Los hallazgos de un bounty les dicen lo que ve un atacante oportunista real, porque los investigadores se comportan como uno, menos el delito.
  • Costo marginal ligado a bugs reales. Sin hallazgos válidos, el gasto se limita a las tarifas de plataforma y a su propio tiempo de triaje.

Dónde falla cada modelo

Esta es la parte que los proveedores se saltan.

Modos de fallo del pentest

  • El analista de checklist. Algunas firmas ejecutan escáneres automáticos, reformatean la salida y cobran tarifas de consultoría. Pidan informes de muestra, nombres y certificaciones de los analistas (OSCP, OSWE, o un historial de CVEs e investigación publicada), y cuánto del tiempo es manual frente a herramientas.
  • Caducidad de la fotografía. El informe es exacto para el commit que se probó. Dos sprints después, la mitad describe otra aplicación.
  • Teatro de alcance. Probar solo la web de marketing mientras la API del producto queda fuera del alcance produce un informe limpio y cero seguridad.
  • Truncamiento por calendario. Los bugs difíciles tardan más que el ejercicio. Una ventana de dos semanas puede terminar justo cuando la cadena interesante estaba cerca.

Modos de fallo del bounty

  • Colapso de la relación señal-ruido. Un programa sin preparación queda sepultado: duplicados, reportes fuera de alcance, spam de escáner y beg bounties ("les falta el registro SPF, páguenme"). En nuestra experiencia, los equipos subestiman la carga de triaje por un múltiplo grande.
  • Pagar por deuda conocida. Si lanzan un bounty sobre una aplicación nunca auditada, pagarán a precio de mercado abierto, reporte a reporte, por bugs que un solo pentest habría enumerado en bloque por una tarifa fija.
  • La confianza del investigador es frágil. Respuestas lentas, severidades rebajadas y duplicados sin pagar terminan en capturas de pantalla compartidas. Un programa con mala reputación atrae investigadores flojos y hallazgos peores.
  • Exposición legal si las reglas son descuidadas. Sin un safe harbor claro y un alcance preciso, invitan a pruebas que no autorizaron sobre sistemas que no pretendían exponer. Y si un investigador accede a datos personales de clientes europeos, la conversación deja de ser de recompensas y pasa a ser de RGPD.

La pregunta de madurez que nadie hace

La verdadera variable de decisión no es el presupuesto. Es si su organización puede absorber un flujo de reportes externos sin verificar.

Un programa de bounty es una bandeja de entrada que se dispara a horas impredecibles con afirmaciones de calidad variable, algunas críticas, y que nunca cierra. Para operarlo necesitan, como mínimo:

  • Un responsable de triaje con nombre y contexto de ingeniería, no un simple enrutador de tickets.
  • Una rúbrica de severidad acordada de antemano, para que las discusiones de pago no se conviertan en debates de política en cada reporte.
  • Un SLA de remediación por severidad, porque un crítico pagado pero sin corregir es el peor de los mundos.
  • Un canal de recepción que funcione de verdad, empezando por un security.txt:
# https://yourdomain.com/.well-known/security.txt
Contact: mailto:security@yourdomain.com
Policy: https://yourdomain.com/security/policy
Preferred-Languages: en, fr
Expires: 2027-06-01T00:00:00.000Z

Si al leer esa lista alguien de su equipo hizo una mueca, no están listos para un bounty público. Es normal. La mayoría de las empresas no lo está, y la solución es la secuencia, no la abstinencia.

La mecánica de costos, con honestidad

Los números varían mucho según región, alcance y firma (no cuesta lo mismo en Madrid que en Ciudad de México o Buenos Aires), así que tomen esto como órdenes de magnitud, no como cotizaciones:

  • Un pentest de calidad sobre una aplicación web suele ser una tarifa fija de cuatro a cinco cifras, en euros o dólares, por una a tres semanas de trabajo, con un costo que escala con la complejidad del alcance, no con los hallazgos.
  • Un programa de bounty cuesta tarifas de plataforma más recompensas. Los pagos individuales van desde unos cientos por hallazgos válidos de severidad baja hasta cinco cifras por críticos en programas maduros. El costo oculto es el tiempo de ingeniería: triaje, reproducción, discutir duplicados y corregir dentro del SLA. Las plataformas, eso sí, resuelven algo nada trivial para equipos de la región: pagar legalmente a investigadores de decenas de países.

La aritmética del fracaso es lo que importa. Lancen un bounty sobre software sin endurecer y convertirán el costo fijo y acotado de un pentest en un flujo ilimitado de pagos por bug más riesgo reputacional. Hagan solo pentests anuales sobre un producto que despliega rápido y convertirán una exposición continua en una fotografía al año. La debilidad de cada modelo es la fortaleza del otro, y ese es exactamente el punto.

El marco de decisión

Recorran esto en orden y deténganse en la primera respuesta.

  1. ¿Nunca han tenido pruebas ofensivas profesionales? Pentest primero. Sin excepciones. No paguen precio de venta al público, bug a bug, por hallazgos que la cobertura sistemática entrega en bloque. Empiecen por cómo funciona un pentest real de principio a fin.
  2. ¿Requisito de cumplimiento o de un cliente en los próximos dos trimestres? Pentest primero. Es el artefacto que el proceso exige.
  3. ¿Superficie crítica inalcanzable desde internet? Pentest (en su variante interna o de brecha asumida). Los bounties no pueden verla.
  4. ¿Pentests anuales que vuelven casi limpios, despliegues semanales, sin pruebas continuas? Añadan ya un programa de divulgación de vulnerabilidades (VDP), y un bounty privado de pago después.
  5. ¿VDP funcionando sin sobresaltos, triaje bajo control, críticos corregidos dentro del SLA? Gradúense a un bounty privado con 20 a 50 investigadores invitados.
  6. ¿Bounty privado estable durante dos o más trimestres, tasa de duplicados a la baja, pagos predecibles? Consideren hacerlo público.
  7. ¿Ya son públicos? Mantengan igualmente pentests anuales o por versión mayor, apuntados a lo que los bounties fallan por estructura: funcionalidades nuevas antes del lanzamiento, sistemas internos, configuración cloud y flujos con mucha lógica.

Acertar con el primer pentest

Un pentest vale lo que vale su definición de alcance. Insistan en:

  • Poner en el alcance las joyas de la corona, no el folleto. La aplicación del producto, las APIs, los flujos de autenticación y la cuenta cloud antes que la web de marketing.
  • Credenciales para cada rol. Probar solo sin autenticar deja fuera los bugs de autorización que dominan las brechas reales. Entreguen cuentas de prueba por nivel de privilegio.
  • Caja gris antes que caja negra en los primeros ejercicios. Compartir documentación de arquitectura e incluso código multiplica lo que un analista con tiempo acotado puede alcanzar. Están comprando hallazgos, no un juego de rol de realismo.
  • Un retest en el contrato. Un informe sin correcciones verificadas es un documento de responsabilidad legal.
  • Hallazgos enrutados a su pipeline, no a un cementerio de PDFs. Cada hallazgo debe convertirse en un ticket, y las clases recurrentes en verificaciones automáticas en CI, que es exactamente el bucle que describimos en construir un pipeline DevSecOps.

Acertar con el primer bounty

Empiecen en privado, empiecen estrecho, y escriban el alcance como una regla de firewall: permitir explícito, denegar por defecto.

## In scope
- app.example.com (production web app)
- api.example.com/v2/* (public API)

## Out of scope
- *.staging.example.com
- Denial of service, rate limit reports
- Findings requiring physical access or social engineering
- Third-party services (report to the vendor)

## Rewards (guideline)
- Critical: $3,000 to $8,000
- High: $1,000 to $3,000
- Medium: $250 to $1,000
- Low: $0 to $250, at our discretion

Y después sostengan la línea operativa:

  • Acusen recibo rápido, idealmente en dos días hábiles. Los investigadores perdonan un pago lento con más facilidad que el silencio.
  • Paguen al triaje, no a la corrección. Hacer esperar a un investigador por su planificación de sprint es como mueren los programas.
  • Publiquen una declaración de safe harbor para que la investigación de buena fe quede explícitamente autorizada.
  • Midan la tasa de duplicados y el tiempo de triaje como métricas de primera clase. Si los duplicados suben, sus correcciones no están aterrizando o su alcance está desactualizado.

La respuesta real: secuencia, y luego ambos

"Cuál necesitan primero" tiene una respuesta limpia para casi todo el mundo: pentest primero, bounty después, ambos con el tiempo. El pentest liquida la deuda acumulada a precio fijo y produce el artefacto que piden sus clientes y sus auditores. El VDP, y luego el bounty, mantiene la presión sobre todo lo que despliegan después de que los analistas se van a casa. Los programas de seguridad maduros tratan el pentest anual como profundidad y el bounty como amplitud, y enrutan ambos al mismo pipeline de remediación para que los hallazgos se conviertan en pruebas de regresión y no en facturas recurrentes.

Saltarse la secuencia es el camino caro. Los equipos que empiezan por el bounty pagan su backlog bug a bug y en público. Los equipos de solo pentest enmarcan una fotografía limpia mientras el video sigue rodando.

Cómo puede ayudar Innovation T

Innovation T ejecuta la seguridad ofensiva tal como la describe este artículo: pentests con alcance definido, con credenciales, en caja gris y con retest contractual, seguidos de la puesta en marcha del VDP y del bounty privado cuando su músculo de triaje esté listo. También construimos el bucle de remediación, conectando los hallazgos a CI para que las clases de bug corregidas sigan corregidas. Vean nuestros servicios de seguridad e ingeniería para el panorama completo.

Si tienen delante una fecha límite de cumplimiento, un cuestionario de un cliente o un producto que nunca ha sido atacado profesionalmente, hablen con nosotros. Les diremos con honestidad qué ejercicio necesitan primero, y cuál puede esperar.

#bug bounty#pentesting#pruebas de seguridad#estrategia

¿Listo para construir con Innovation T?

Ya se trate de seguridad, crecimiento o ingeniería, nuestro equipo puede ayudarte a lograrlo con calidad.