Bug bounty gestionado: montamos el programa y triamos cada reporte

Dos cosas que casi nadie quiere hacer en casa: diseñar un programa de recompensas que atraiga buenos investigadores, y leer todo lo que entra por él. Hacemos las dos, sobre HackerOne, Bugcrowd, Intigriti o tu propio canal. Y si ya tienes el programa montado y solo te sobra la bandeja, hacemos solo el triage.

Última actualización: octubre de 2026

CVSS 4.0 + EPSS — Cada reporte válido sale puntuado métrica a métrica y con la probabilidad real de explotación
24 h / 4 h — Acuse al investigador en 24 h laborables; escalada de lo crítico en 4 h
5-10 días — Alta del servicio: briefing técnico, accesos, integraciones y flujo acordado
0 € — Lo que cuesta un duplicado o un fuera de alcance a tu equipo: los cerramos nosotros

El programa no falla por falta de reportes, falla por la bandeja

Un bug bounty bien planteado atrae reportes. Ese es justo el problema que nadie cuenta antes de abrirlo: la mayoría de lo que entra son duplicados, cosas fuera de alcance y salidas de escáner sin impacto demostrado, y hay que leerlo todo igualmente para encontrar los tres hallazgos que sí importan. Con 2-4 horas por reporte y un volumen normal de cincuenta al mes, eso son más de cien horas al mes de gente cara haciendo criba.

Cuando esa criba se atasca, el daño va en dos direcciones. Hacia dentro, tu equipo de desarrollo deja de fiarse de lo que le llega y los hallazgos reales se tratan como ruido. Hacia fuera, el investigador que esperó tres semanas una respuesta no vuelve, y lo cuenta: la reputación de un programa se construye en los foros donde esa gente se lee entre sí. Y mientras tanto, la vulnerabilidad crítica que llegó un viernes de agosto sigue en la cola.

Por eso el programa y el triage son el mismo servicio y no dos. Diseñamos las reglas y la tabla de recompensas pensando en el volumen que vamos a tener que absorber después, y absorbemos ese volumen nosotros: a tu equipo solo le llega lo que está reproducido, puntuado y listo para corregir.

Qué incluye, del diseño del programa al reporte cerrado

Diseño del programa: alcance, reglas de participación, tipos de vulnerabilidad aceptados y política de divulgación
Tabla de recompensas por severidad, acordada y publicada antes de abrir: sin ella cada bounty es una negociación
Configuración en plataforma (HackerOne, Bugcrowd, Intigriti) o en tu propio canal de recepción
Lanzamiento privado o público, con la estrategia de invitación y las comunicaciones iniciales
Clasificación de cada reporte entrante: dentro o fuera de alcance, y tipo de vulnerabilidad
Reproducción técnica con criterio ofensivo real, no lectura del texto del reporte
Validación de impacto: qué puede hacer de verdad un atacante con el fallo, y hasta dónde llega
Puntuación con CVSS 4.0 justificada métrica a métrica y contexto de explotación con EPSS
Descarte fundamentado de falsos positivos, duplicados y fuera de alcance, cerrados con el investigador
Comunicación con los investigadores en tu nombre, en español y en inglés
Entrega a tu equipo en la herramienta que ya usáis: Jira, GitHub Issues o la propia plataforma
Triage suelto bajo demanda: reportes aislados, hallazgos de auditoría o salidas de escáner que necesitan confirmación antes de escalar
Informe mensual: volumen, tasa de validación, tiempos de respuesta y recomendaciones sobre el programa

Cómo trabajamos

Diseño del programa: Definimos contigo alcance, reglas, tipos de vulnerabilidad aceptados, política de divulgación y tabla de recompensas. Un programa bien definido recibe mejores reportes y menos ruido.
Lanzamiento: Configuramos el canal —plataforma o formulario propio—, preparamos las comunicaciones y coordinamos el arranque privado o público según tu estrategia.
Triage de cada reporte: Clasificación, reproducción en entorno controlado, validación de impacto, CVSS 4.0 y EPSS, respuesta al investigador y entrega al equipo de remediación. Es el grueso del servicio y lo que absorbe el volumen.
Remediación acompañada: Los hallazgos validados llegan con PoC, impacto y pasos concretos. Resolvemos las dudas de tus developers y verificamos la corrección antes de cerrar el caso con el investigador.
Optimización mensual: Informe con métricas y recomendaciones: ampliar alcance, ajustar bounties o cambiar reglas. Un programa que no se retoca deja de atraer a los buenos a los seis meses.

Del diseño al reporte cerrado

Las cuatro fases con el responsable de cada paso y el plazo comprometido cuando lo hay. La tercera, el triage, es donde se va el trabajo real y la razón de que esto sea un solo servicio.

Diseñamos

Las reglas deciden qué recibes después. Un alcance vago se paga en ruido durante meses.

Alcance y reglas (Tu equipo · Semana 1): Qué dominios, aplicaciones y versiones entran, qué queda fuera y qué pruebas no se admiten nunca: denegación de servicio, ingeniería social al personal y datos de terceros.
Tipos aceptados y exclusiones (QuantumSec · Semana 1): Qué clases de vulnerabilidad se premian y cuáles se cierran de oficio. Aquí se evita la mitad de los futuros desencuentros con investigadores.
Tabla de recompensas (QuantumSec · Semana 2): Rangos por severidad acordados y publicados antes de abrir. Negociar cada bounty caso a caso alarga los tiempos y acaba espantando a los buenos.
Política de divulgación (QuantumSec · Semana 2): Qué puede publicar el investigador y cuándo, con cláusula de safe harbor revisada por vuestro equipo legal.

Al cerrar esta fase: Programa definido por escrito: alcance, reglas, exclusiones, tabla de recompensas y política de divulgación.

Lanzamos

Abrir en público el primer día es el error más caro. Se empieza invitando.

Plataforma o canal propio (QuantumSec · Semana 3): Configuramos HackerOne, Bugcrowd o Intigriti, o montamos el canal propio, y lo conectamos con nuestro flujo de triage.
Integración con vuestras herramientas (QuantumSec · Semana 3): Jira, GitHub Issues o lo que ya uséis, para que el hallazgo validado aparezca donde vuestro equipo ya trabaja.
Arranque privado (QuantumSec): Abrimos con un grupo limitado de investigadores invitados. Mide el volumen real y la capacidad de remediación antes de exponerse.
Apertura pública por fases (Tu equipo): Se amplía cuando los tiempos de remediación aguantan el ritmo, no por calendario.

Al cerrar esta fase: Programa en marcha con volumen controlado y los hallazgos aterrizando ya en vuestras herramientas.

Triamos

Lo que entra lo leemos nosotros. A tu equipo solo le llega lo reproducido y puntuado.

Llega el reporte (Investigador): Por la plataforma o el canal propio. Entra en nuestra cola, no en una bandeja compartida que nadie vigila.
Clasificación inicial (QuantumSec · 24 h laborables): Dentro o fuera de alcance y tipo de vulnerabilidad: IDOR, XSS, SQLi, lógica de negocio. Con acuse al investigador y número de caso.
Reproducción técnica (QuantumSec · 72 h laborables): Intentamos el ataque en entorno controlado: que el payload funcione de verdad, que el impacto exista y que no sea un duplicado de algo ya conocido.
Impacto y puntuación (QuantumSec): Qué consigue un atacante real —datos, escalada, dinero, reputación— con CVSS 4.0 justificado métrica a métrica y EPSS para situar la probabilidad de explotación.
Escalada de lo crítico (QuantumSec · 4 h laborables): Si el impacto puede ser crítico avisamos a vuestro responsable de seguridad por la vía de urgencia acordada, sea la hora que sea.
Respuesta y cierre (QuantumSec): Redactamos la respuesta en tu nombre —válido, duplicado, fuera de alcance— con su justificación técnica. Un investigador mal contestado deja de reportar, y lo cuenta.

Al cerrar esta fase: La bandeja vacía y, en vuestras herramientas, solo hallazgos reproducidos, puntuados y accionables.

Optimizamos

Un programa que no se retoca deja de atraer a los buenos en seis meses.

Informe mensual (QuantumSec · Mensual): Volumen, tasa de validación, duplicados, tiempo hasta la primera respuesta y hasta la validación, y estado de cada caso abierto.
Revisión del alcance (QuantumSec · Trimestral): Lo que habéis desplegado desde la última revisión entra al alcance publicado, para que el programa cubra lo que de verdad está expuesto.
Ajuste de recompensas y reglas (QuantumSec · Trimestral): Con los datos del propio programa: dónde se paga de menos, qué clase de reporte sobra y qué regla genera discusiones recurrentes.
Decisión de ampliar o frenar (Tu equipo): Si la remediación no sigue el ritmo del triage, el cuello de botella no es la bandeja: se amplía por fases en lugar de abrir del todo.

Al cerrar esta fase: Un programa ajustado a lo que de verdad recibís y a la velocidad a la que podéis corregir.

Qué recibes

Programa diseñado, configurado y operativo en 2-3 semanas
Tabla de recompensas por severidad, acordada y publicada
Bandeja procesada: cada reporte con estado —válido, duplicado, fuera de alcance, falso positivo— y su justificación técnica
Cada hallazgo válido con PoC, impacto, CVSS 4.0 justificado métrica a métrica y score EPSS
Los hallazgos validados en la herramienta donde ya trabaja tu equipo
Registro completo de las comunicaciones con investigadores, caso por caso
Informe mensual con métricas, tendencias y recomendaciones sobre el programa
Cuadro de métricas accesible en continuo

Cuándo tiene sentido

Empresas que quieren lanzar su primer programa de recompensas y no tienen a quién encargarle la bandeja
Programas ya activos en HackerOne, Bugcrowd o Intigriti donde el equipo interno no da abasto con el triage
Equipos AppSec con backlog de reportes sin procesar y sin forma de ponerse al día
Programas abiertos pero parados, porque los investigadores dejaron de confiar en los tiempos de respuesta
Startups que necesitan un programa para cumplir requisitos de inversores o de clientes enterprise
CISOs que necesitan certeza técnica sobre un hallazgo suelto antes de escalarlo a dirección
Equipos de producto que deben decidir qué vulnerabilidad bloquea una release y cuál no

Bug bounty, VDP y pentesting: qué cubre cada uno

Se compran por separado y resuelven cosas distintas. El error caro es contratar uno esperando lo que da otro.

	Bug bounty gestionado	VDP gestionado	Pentesting
Qué es	Programa con recompensas por hallazgo válido	Canal de divulgación sin recompensas	Evaluación acotada en alcance y tiempo
Quién busca	Comunidad amplia de investigadores	Quien se tropieza con el fallo	Un equipo contratado
Cobertura garantizada	No: nadie asegura que miren tu módulo feo	No	Sí, lo acordado en el alcance
Volumen y ruido	Alto	Bajo y constante	Ninguno: solo el informe
Coste	Gestión + recompensas variables	Solo gestión	Precio cerrado por proyecto
Sirve como evidencia ante un cliente o auditor	Parcialmente	Sí, para NIS2 y CRA	Sí, es su formato natural
Cuándo encaja	Vigilancia continua con presupuesto para premiar	Primer canal formal y base de cumplimiento	Cobertura demostrable y entregable

Compara con

Preguntas frecuentes sobre bug bounty y triage

¿Podéis hacer solo el triage de un programa que ya tenemos montado?

Sí, es la mitad de los encargos. Nos integramos con vuestro HackerOne, Bugcrowd, Intigriti o canal propio sin cambiaros de plataforma ni de proceso: añadimos la capa de validación y respuesta que os falta. También triamos reportes sueltos que llegan por otras vías —un correo a soporte, un hallazgo de auditoría, una salida de escáner— cuando necesitáis certeza técnica antes de escalarlos.

¿En qué se diferencia esto de contratar HackerOne o Bugcrowd?

HackerOne y Bugcrowd son plataformas: te dan acceso a una comunidad de investigadores y herramientas de gestión, pero el triage lo sigue haciendo tu equipo. Nosotros somos el equipo externo que hace ese trabajo. Podemos operar sobre la plataforma que ya usáis o diseñar un programa independiente de ellas.

¿Cuál es el SLA de respuesta a un reporte crítico?

Cuatro horas laborables desde que el triage identifica impacto potencialmente crítico: avisamos a vuestro responsable de seguridad por la vía de urgencia acordada y coordinamos la respuesta desde ahí. El acuse al investigador es de 24 horas laborables y la primera valoración técnica de 72. Los plazos se cierran por escrito al arrancar.

¿Por qué CVSS 4.0 y EPSS, y no la severidad que pone el investigador?

Porque la severidad del investigador mide lo que él consiguió, no lo que vale en vuestro contexto. CVSS 4.0 obliga a justificar métrica a métrica —vector, complejidad, privilegios, impacto— y hace comparable un hallazgo con otro. EPSS añade lo que CVSS no dice: la probabilidad estimada de que algo así se explote de verdad en los próximos treinta días. Un CVSS 9.8 con EPSS bajo y un CVSS 7.5 con EPSS alto no se priorizan igual.

¿Qué pasa con los duplicados y los reportes fuera de alcance?

Los cerramos nosotros con una respuesta razonada, sin que lleguen a tu equipo. El duplicado se enlaza al reporte original y el fuera de alcance se explica citando las reglas publicadas del programa. Es la parte más ingrata de operar un bug bounty y la que más relaciones rompe cuando se despacha con plantillas secas.

¿Qué presupuesto de recompensas hay que reservar para empezar?

Depende del alcance y de la severidad que aceptéis, pero el error habitual no es quedarse corto de presupuesto: es abrir el programa sin tabla de recompensas publicada. Sin ella cada reporte se convierte en una negociación, los tiempos se alargan y los buenos investigadores dejan de enviar. Se fija la tabla antes de abrir, se publica, y se revisa a los seis meses con los datos del propio programa.

¿Qué pasa si recibimos más reportes de los que podemos gestionar?

Es el escenario normal de las primeras semanas de un programa público, y por eso se recomienda empezar en privado con un grupo limitado. El triage externo absorbe el volumen: valida, descarta duplicados y fuera de alcance, y a tu equipo solo le llegan hallazgos confirmados con impacto demostrado. Si el cuello de botella es la remediación y no el triage, se amplía el programa por fases en vez de abrirlo de golpe.

¿Un bug bounty sustituye al pentesting?

No, cubren cosas distintas. El pentest está acotado en alcance y tiempo, con cobertura garantizada de lo acordado y un informe que sirve ante un cliente o un auditor. El bug bounty es continuo y no garantiza cobertura: nadie te asegura que alguien vaya a mirar tu módulo menos atractivo. La combinación sensata es pentesting para cobertura y evidencia, y bug bounty para vigilancia continua entre proyectos.

¿Qué pasa si discrepamos con vuestra valoración de un reporte?

La valoración se entrega justificada métrica a métrica precisamente para poder discutirla. Si vuestro contexto cambia el impacto —ese dato no es sensible, ese endpoint no está expuesto de verdad—, se ajusta y queda registrado el porqué. La decisión final sobre aceptar un riesgo o pagar un bounty es siempre vuestra.

¿Podéis validar vulnerabilidades sin acceso a producción?

En la mayoría de casos sí, trabajando sobre un entorno de preproducción equivalente o con una cuenta de prueba. Cuando el fallo solo se reproduce en producción lo acordamos por escrito antes, con ventana, alcance y las pruebas limitadas a confirmar el impacto sin tocar datos reales.

¿Cómo garantizáis la confidencialidad de los reportes?

Acuerdo de confidencialidad firmado antes de empezar, acceso limitado al equipo asignado, y los reportes y evidencias en los sistemas que acordemos, no en herramientas personales. Si trabajamos sobre vuestra plataforma, los datos no salen de ella.

¿Qué tienen que saber los investigadores sobre quién gestiona el programa?

Lo decidís vosotros. Podemos operar en vuestro nombre sin que los investigadores sepan que hay un proveedor externo, o indicar que el triage lo lleva un equipo de seguridad externo especializado. Los dos modelos son habituales en el mercado.