ATALAIAUn bug bounty es una promesa a desconocidos: envíanos lo que encuentres y responderemos con rapidez, justicia y buena fe. Lanzar uno antes de poder cumplir esa promesa suele provocar una avalancha de informes, una bandeja desbordada e investigadores molestos.
El checklist de abajo está pensado para recorrerlo en una sola reunión con ingeniería, seguridad y quien lleve vuestra web pública. Si no puedes marcar la mayoría, empieza por una política de divulgación y vuelve dentro de un trimestre.
Paso cero: un VDP y security.txt
Una política de divulgación de vulnerabilidades (VDP) es la versión gratuita y siempre activa de un bounty. Dice cómo reportar, qué consideras dentro de scope y que no emprenderás acciones legales contra la investigación de buena fe. Publícala antes de cualquier esquema de recompensas.
Después publica un fichero security.txt, como describe el RFC 9116, para que investigadores y herramientas encuentren el contacto correcto.
# https://example.com/.well-known/security.txt
Contact: mailto:security@example.com
Expires: 2027-06-30T23:59:59Z
Policy: https://example.com/security/disclosure
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en, pt
Canonical: https://example.com/.well-known/security.txtComprueba que el buzón se monitoriza, que la fecha de Expires está en el futuro y que alguien se encarga de renovarla.
Checklist de preparación
| # | Pregunta | Listo cuando |
|---|---|---|
| 1 | ¿Tienes un VDP público? | Publicado, enlazado desde security.txt, con una declaración de safe harbour |
| 2 | ¿Habéis probado vosotros mismos los activos en scope? | Se ha hecho un pentest o una revisión interna recientes y sus hallazgos están corregidos |
| 3 | ¿La primera llamada es gratis? | Puedes enumerar cada dominio, aplicación y API que pondrías en scope, con un responsable |
| 4 | ¿Quién hace el triage? | Personas concretas con tiempo reservado, más suplencia en vacaciones |
| 5 | ¿Quién arregla? | Cada asset en scope se asigna a un equipo que ha aceptado los SLA de corrección |
| 6 | ¿Puedes reproducirlo de forma segura? | Un entorno de staging o cuentas de prueba que investigadores y triagers puedan usar |
| 7 | ¿Se valida la entrada no confiable donde se usa, y no solo donde llega? | Se han revisado la cláusula de puerto seguro y las condiciones de pago |
| 8 | ¿Puedes pagar? | Existe un responsable del presupuesto y una vía de pago, incluso para un programa privado |
Un scope que un desconocido pueda aplicar
Un buen scope se lee como un contrato, no como un deseo. Escríbelo de modo que un investigador que nunca ha hablado contigo pueda decidir si un hallazgo cuenta.
- En scope: hostnames exactos, identificadores de app y rutas base de API, indicando el entorno.
- Fuera de scope: servicios de terceros que no controlas, sitios de marketing y todo lo que se comparta con otros tenants.
- Clases excluidas: problemas que has decidido no recompensar, como cabeceras ausentes sin impacto, self-XSS o rate limiting en endpoints no sensibles.
- Reglas de enfrentamiento: sin denegación de servicio, sin ingeniería social al personal, sin acceder a datos de otros usuarios más allá de lo que demuestre el problema, usa las cuentas de prueba proporcionadas.
Empieza con un programa privado y un scope reducido. Amplíalo cuando el triage esté tranquilo.
SLAs de triage y recompensas
Publica objetivos de respuesta que puedas cumplir en tu peor semana, no en la mejor. Una estructura típica tiene cuatro relojes:
- Primera respuestaEl investigador recibe de una persona la confirmación de que el informe se ha recibido y se está revisando.
- Decisión de triageVálido, duplicado, fuera de scope o necesita más información, con una severidad asignada.
- Decisión de recompensaLa banda de recompensa se confirma una vez acordada la severidad.
- Corrección y divulgaciónEl problema se corrige, se verifica y, si se ha acordado, se divulga.
Define las recompensas como una tabla de rangos por severidad y nivel del activo, y rellena los importes según tu propio presupuesto. La estructura importa más que las cifras.
| Severidad | Activos de Tier 1 (producto principal, auth, pagos) | Activos de Tier 2 (aplicaciones y APIs de apoyo) |
|---|---|---|
| Crítica | Banda A | Banda B |
| Alta | Banda B | Banda C |
| Media | Banda C | Banda D |
| Bajo | Banda D | Agradecimientos y reconocimiento |
Anota cómo puntúas la severidad, por ejemplo con CVSS más una nota de impacto en el negocio, para que dos personas que hagan triage lleguen a la misma respuesta.
Cierra el ciclo de corrección
Un bounty que solo genera pagos es un coste. Uno que alimenta la línea es una inversión. Para cada informe válido:
- Abre un ticket en el backlog del equipo responsable con el SLA adjunto, no en un tracker solo de seguridad.
- Verifica el arreglo con la prueba de concepto original y, si procede, pide al investigador que lo vuelva a probar.
- Añade un test de regresión, una regla de Semgrep o una comprobación del scanner para que la misma clase de fallo no vuelva a colarse.
- Pregunta una vez por trimestre qué estaciones de la línea deberían haber detectado antes esa clase de fallo, y arregla la estación.
Compruébalo esta semana
- Haz fetch de
/.well-known/security.txten tu dominio principal. Si no existe o ha caducado, esa es tu primera tarea. - Rellena la tabla de ocho filas de arriba con las personas adecuadas en la sala y marca cada fila como sí, no o parcialmente.
- Si hay más de dos noes, publica un VDP, programa un pentest y revisa el bounty el trimestre que viene.