Contrato de bug bounty y reglas de confidencialidad
Un contrato de bug bounty bien estructurado protege tanto la propiedad intelectual de la empresa como la seguridad jurídica del investigador ético.
En el mundo de la ciberseguridad defensiva, los programas de recompensas por errores (bug bounty) se han convertido en una herramienta indispensable. Sin embargo, invitar a terceros a atacar tus sistemas es una actividad inherentemente arriesgada. Si no se establecen reglas claras, la línea entre una “investigación de seguridad autorizada” y un “delito informático” puede volverse peligrosamente difusa. He visto casos donde investigadores bien intencionados terminaron con demandas civiles por acceder a datos sensibles, simplemente porque el alcance del programa no estaba bien definido.
La clave para un programa exitoso no es solo el presupuesto para recompensas, sino la solidez del marco legal que lo sustenta. Un contrato de bug bounty debe abordar explícitamente qué está permitido (in-scope), qué está prohibido (out-of-scope), cómo se manejará la confidencialidad de los hallazgos y, crucialmente, el compromiso de “Safe Harbor” o puerto seguro legal para los participantes. Sin estos elementos, las empresas se exponen a fugas de datos y daños reputacionales, mientras que los hackers éticos corren riesgos legales innecesarios.
Este artículo desglosará los componentes esenciales de un acuerdo de bug bounty, desde la definición de reglas de compromiso hasta las cláusulas de confidencialidad y pago. Analizaremos cómo estructurar legalmente la relación para fomentar la colaboración sin sacrificar el control, asegurando que el proceso de reporte de vulnerabilidades sea seguro, transparente y beneficioso para ambas partes.
Elementos críticos en la estructura legal de un Bug Bounty:
- Alcance (Scope): Definición precisa de dominios, IPs y tipos de pruebas permitidas. Todo lo que no esté explícitamente “in-scope” debe considerarse prohibido.
- Safe Harbor: Cláusula legal donde la empresa se compromete a no emprender acciones legales contra investigadores que actúen de buena fe y dentro de las reglas.
- Confidencialidad (NDA): Restricciones sobre la divulgación pública de la vulnerabilidad hasta que haya sido remediada (Coordinated Vulnerability Disclosure).
- Propiedad Intelectual: Cesión clara de los derechos sobre el reporte y la prueba de concepto (PoC) a la empresa a cambio de la recompensa.
Ver más en esta categoría: Derecho Digital y Protección de Datos
En este artículo:
Última actualización: 24 de Octubre de 2023.
Definición rápida: Acuerdo legal que regula la relación entre una organización y investigadores de seguridad externos, estableciendo reglas para la detección, reporte y compensación de vulnerabilidades informáticas.
A quién aplica: Empresas con activos digitales expuestos (SaaS, e-commerce, apps móviles) y profesionales de ciberseguridad (bug hunters).
Tiempo, costo y documentos:
- Implementación: 4-8 semanas para definir políticas y configurar plataforma.
- Costo: Variable (recompensas) + tarifas de plataforma (HackerOne, Bugcrowd).
- Documentos: Política de Divulgación de Vulnerabilidades (VDP), Términos del Programa, NDA.
Puntos que suelen decidir disputas:
Further reading:
- Ambigüedad en el alcance (¿estaba permitido probar ese subdominio?).
- Falta de claridad en los criterios de pago (severidad vs. impacto real).
Guía rápida sobre contratos de Bug Bounty
- Reglas Claras de Juego (RoE): Establezca Rules of Engagement específicas. ¿Se permite fuerza bruta? ¿Ingeniería social? ¿Acceso a datos de terceros? Si no lo prohíbe explícitamente, asuma que alguien lo intentará.
- El “Safe Harbor” es innegociable: Para atraer talento serio, debe garantizar legalmente que no demandará al investigador por hackear sus sistemas, siempre que siga las reglas. Esto convierte una actividad ilegal en autorizada.
- Divulgación Coordinada: Defina cuándo y cómo se puede hacer pública la vulnerabilidad. Generalmente, se exige confidencialidad hasta que el parche esté desplegado y verificado.
- Pagos y Fiscalidad: Aclare que el investigador es un contratista independiente, responsable de sus propios impuestos. Las recompensas suelen estar sujetas a validación técnica y no son automáticas.
- Propiedad del Hallazgo: El contrato debe estipular que, al pagar la recompensa (bounty), la empresa adquiere los derechos sobre la información de la vulnerabilidad para evitar que el investigador la revenda o reutilice.
Entender los contratos de Bug Bounty en la práctica
Un programa de bug bounty no es simplemente “poner una recompensa y esperar”. Legalmente, es una oferta pública de contrato unilateral o, en programas privados, un acuerdo de servicios específico. La empresa invita a probar su seguridad bajo condiciones estrictas. El investigador acepta estas condiciones al momento de iniciar sus pruebas o enviar un reporte. La violación de estas condiciones (por ejemplo, acceder a datos de clientes reales o tumbar un servidor en producción) puede invalidar el “Safe Harbor” y exponer al investigador a consecuencias penales bajo leyes como la CFAA en EE.UU. o artículos equivalentes en códigos penales locales.
La confidencialidad es el pilar central. A diferencia de un pentest tradicional donde hay un contrato firmado previamente con una consultora, en bug bounty tratamos con una multitud (“crowd”). Por ello, los términos del programa actúan como un NDA (Non-Disclosure Agreement) masivo. Si un investigador descubre una inyección SQL crítica y la publica en Twitter antes de que la empresa pueda arreglarla, no solo pierde la recompensa, sino que viola el contrato, causando daños reales. Los programas maduros gestionan esto mediante políticas de “Divulgación Coordinada” (CVD), donde se pacta una fecha de publicación conjunta una vez resuelto el fallo.
Jerarquía de decisiones en disputas de Bug Bounty:
- 1. El Alcance (Scope) manda: Si el activo atacado estaba fuera de alcance (“out of scope”), la empresa no tiene obligación de pagar, y el investigador operó sin autorización.
- 2. Reproducibilidad: La empresa solo paga por vulnerabilidades que puede verificar y reproducir. Un reporte teórico sin prueba de concepto (PoC) funcional suele ser rechazado o pagado mínimamente.
- 3. Impacto vs. Riesgo Teórico: Las disputas sobre el monto suelen centrarse en la severidad (CVSS). La empresa paga por el impacto demostrable en el negocio, no solo por la complejidad técnica del hallazgo.
Ángulos legales y prácticos que cambian el resultado
La distinción entre programa público y privado es fundamental. En un programa privado, los investigadores son invitados (vetados previamente) y firman acuerdos específicos de confidencialidad más estrictos. Aquí, la relación es más cercana y el control legal es mayor. En un programa público, cualquiera puede participar. Esto aumenta la superficie de detección pero también el riesgo de “ruido” y de investigadores inexpertos que pueden dañar sistemas accidentalmente. Legalmente, el programa público debe tener términos de uso (“Terms of Service”) extremadamente robustos y accesibles públicamente para proteger a la empresa de responsabilidad por daños causados por pruebas mal ejecutadas.
Otro ángulo crucial es el manejo de datos personales (PII). Si un investigador accede a una base de datos de usuarios para demostrar una vulnerabilidad, técnicamente ha accedido a datos personales. El contrato debe instruir explícitamente: “Si encuentras PII, detente inmediatamente, reporta y purga los datos locales”. No hacerlo puede convertir el reporte de un “white hat” en una brecha de datos reportable bajo GDPR/RGPD, complicando la situación legal para ambas partes.
Caminos viables que las partes usan para resolver disputas
Cuando surge un conflicto sobre el pago o la validez de un bug, el primer paso es la mediación a través de la plataforma (si se usa HackerOne, Bugcrowd, Intigriti). Estas plataformas actúan como árbitros técnicos neutrales, evaluando si el reporte cumple con las normas estándar de la industria. Si el programa es “self-hosted” (gestionado por la propia empresa), la resolución depende del equipo de seguridad interno. Para evitar percepciones de injusticia, muchas empresas establecen comités de revisión o políticas de transparencia donde explican públicamente por qué ciertos reportes fueron rechazados (ej. “Duplicate”, “Informative”, “Won’t Fix”).
Aplicación práctica: Diseñando el Marco Legal
Crear un programa sólido requiere redactar una política que sirva tanto de guía técnica como de contrato legal.
- Definir el “Safe Harbor”: Redactar una cláusula clara que autorice el acceso a los sistemas listados para fines de seguridad, renunciando a acciones civiles/penales por actividad de buena fe.
- Establecer el Alcance (Scope):
- Incluir: *.miempresa.com, api.miempresa.com.
- Excluir explícitamente: Proveedores externos (AWS, Azure), pasarelas de pago, sistemas de empleados.
- Reglas de Comportamiento (RoE): Prohibir denegación de servicio (DoS), spam, ingeniería social a empleados y destrucción de datos.
- Política de Pagos: Publicar una tabla de recompensas basada en severidad (ej. Crítico: $5,000, Alto: $2,000). Aclarar que la decisión final sobre la severidad es de la empresa.
- Proceso de Reporte: Especificar el canal seguro (plataforma o email cifrado PGP). Requerir pasos de reproducción detallados.
- Términos de Confidencialidad: Establecer que la existencia y detalles de la vulnerabilidad son confidenciales hasta que la empresa autorice su divulgación pública.
Detalles técnicos y actualizaciones relevantes
Técnicamente, la validación de reportes se basa en estándares como CVSS (Common Vulnerability Scoring System). Los contratos suelen referenciar CVSS v3.1 o v4.0 para calcular la severidad base. Sin embargo, las empresas deben reservarse el derecho de ajustar la puntuación según el “contexto ambiental”. Una inyección SQL en un entorno de pruebas sin datos reales no tiene el mismo valor (ni pago) que en producción, aunque técnicamente sea la misma vulnerabilidad.
En cuanto a la confidencialidad, el estándar de la industria se mueve hacia la divulgación por defecto después de un tiempo razonable (ej. 90 días o 180 días), siguiendo el modelo de Google Project Zero. Esto presiona a las empresas para que arreglen los fallos (“patching”). Los contratos modernos a menudo incluyen cláusulas de “mutual disclosure”, donde ambas partes acuerdan hacer público el hallazgo educativo una vez mitigado, lo cual beneficia la reputación del investigador.
- Verificación de Identidad (KYC): Para cumplir con leyes de prevención de lavado de dinero y listas de sanciones (OFAC), las plataformas de bug bounty exigen verificación de identidad y fiscal (W-8BEN) antes de pagar. El contrato debe reflejar que el pago está condicionado a esta verificación legal.
- Chain of Custody: Los investigadores deben garantizar la integridad de las pruebas. El contrato debe exigir que cualquier dato exfiltrado como prueba sea eliminado de forma segura tras la validación.
Estadísticas y lectura de escenarios
Los programas de recompensas han madurado, y los datos muestran tendencias claras sobre dónde surgen los conflictos y cómo se resuelven.
La mayoría de los reportes rechazados no son por errores técnicos, sino por estar fuera de alcance o ser duplicados, lo que subraya la importancia de una definición legal clara del “scope”.
20% – 25%
Solo una cuarta parte resulta en pago; el filtrado inicial es crítico.
30% – 40%
La principal fuente de frustración; la regla “first-to-find” es ley.
30% – 35%
Lectura deficiente de las reglas del programa por parte de investigadores.
Puntos monitorizables para la gestión del programa:
- Tiempo al primer triaje: Días para confirmar si un reporte es válido (objetivo < 2 días).
- Tiempo a la recompensa: Días desde la validación hasta el pago (factor clave de reputación).
- Tasa de ruido: Porcentaje de reportes inválidos (indica si las reglas son claras).
Ejemplos prácticos de gestión de Bug Bounty
Escenario A: El reporte responsable
Un investigador encuentra una vulnerabilidad RCE en un servidor de producción. Detiene su prueba tras ejecutar un comando `whoami` inofensivo. Escribe un reporte detallado, no descarga datos de usuarios y espera la validación. La empresa confirma, parchea en 48 horas y paga el bounty máximo.
Resultado: Éxito total. El investigador respetó las reglas, minimizó el daño y recibió su pago bajo el “Safe Harbor”.
Escenario B: La extorsión accidental
Un investigador encuentra una base de datos expuesta. Descarga 10,000 registros “como prueba”. Contacta al CEO por email diciendo: “Páguenme o esto se hace público”. La empresa lo interpreta como extorsión, no como bug bounty.
Resultado: Desastre legal. Al descargar datos masivos y amenazar, violó el contrato y las leyes penales. La empresa activa a su equipo legal y contacta a las autoridades en lugar de pagar.
Errores comunes en la gestión de programas
Alcance vago: Usar “todo el sitio” en lugar de listar dominios específicos. Esto lleva a pruebas en sistemas de terceros integrados, causando problemas legales con proveedores.
Ignorar reportes válidos: “Ghosting” a los investigadores (no responder). Esto daña la reputación y a menudo lleva a que el investigador publique el fallo (“Full Disclosure”) por frustración.
Cambiar reglas retroactivamente: Modificar la tabla de pagos o el alcance después de recibir un reporte crítico para evitar pagar. Esto destruye la confianza en el programa.
No definir “Out-of-Scope”: Olvidar excluir ataques de denegación de servicio (DDoS) o ingeniería social. Sin prohibición explícita, alguien podría tumbar su web “legalmente”.
FAQ sobre Bug Bounty y Aspectos Legales
¿Es legal hackear una empresa si tienen un programa de bug bounty?
Sí, pero solo dentro de los límites estrictos definidos en la política del programa. El “Safe Harbor” es una autorización condicional.
Si te sales del alcance (ej. atacas un dominio no listado) o violas las reglas de comportamiento, pierdes la protección legal y podrías estar cometiendo un delito.
¿Qué pasa si encuentro datos personales de usuarios?
Debes detenerte inmediatamente. Reporta la vulnerabilidad y la existencia de los datos, pero no los descargues ni los veas más de lo necesario para confirmar el fallo.
Descargar bases de datos completas viola la privacidad, las leyes de protección de datos (GDPR) y casi todas las políticas de bug bounty, anulando tu derecho a recompensa.
¿Son imponibles los ingresos por bug bounty?
Sí. Generalmente se consideran ingresos por servicios profesionales o premios, dependiendo de la jurisdicción fiscal del investigador.
Las plataformas suelen requerir formularios fiscales (como el W-8BEN o W-9 en EE.UU.) y es responsabilidad del investigador declarar estos ingresos en su país.
¿Puede una empresa negarse a pagar si arreglo el bug?
El pago es por el reporte de la vulnerabilidad, no por arreglarla (eso lo hace la empresa). Si el reporte es válido, único y dentro del alcance, el contrato obliga al pago.
Sin embargo, las empresas tienen discreción para determinar la severidad y el monto final. Las disputas se suelen resolver a través de la plataforma intermediaria.
¿Qué es la “Divulgación Coordinada”?
Es un acuerdo para mantener el fallo en secreto hasta que la empresa tenga tiempo de arreglarlo. Una vez parcheado, se acuerda una fecha para que el investigador pueda publicar sus hallazgos.
Violar este periodo de embargo suele resultar en la expulsión del programa y la pérdida de la recompensa.
¿Necesito un contrato firmado en papel?
No necesariamente. En plataformas digitales, la aceptación de los “Términos y Condiciones” al unirse al programa constituye un contrato vinculante.
Sin embargo, para programas privados de alto nivel o consultorías específicas, es común firmar un NDA y un contrato de servicios tradicional.
¿Pueden participar menores de edad?
Depende de la legislación local y de la plataforma. Muchas permiten la participación de menores (ej. 14+), pero requieren consentimiento de padres o tutores para procesar los pagos.
Legalmente, la capacidad de contratar de un menor es limitada, por lo que la intervención de un tutor es necesaria para formalizar el acuerdo.
¿Qué pasa con los duplicados?
La regla estándar es “First-to-Find”. Solo el primer investigador que reporta un fallo válido recibe el pago.
Esto puede ser frustrante, pero es una cláusula estándar para evitar pagar múltiples veces por el mismo problema. La transparencia de la empresa al mostrar la fecha del reporte original es clave.
¿Puedo usar herramientas automatizadas (scanners)?
Depende de las reglas del programa. Muchos prohíben escáneres ruidosos o agresivos que puedan degradar el servicio.
Incluso si se permiten, los reportes generados automáticamente sin validación manual (“copiar y pegar del scanner”) suelen ser rechazados por baja calidad.
¿Quién posee la propiedad intelectual del reporte?
Generalmente, al aceptar el pago, el investigador cede a la empresa los derechos de uso sobre la información reportada.
Esto impide que el investigador “revenda” el fallo a otros actores o lo utilice maliciosamente después de cobrar.
Referencias y próximos pasos
- Defina su VDP (Vulnerability Disclosure Policy): Si no está listo para pagar recompensas, comience con una política de divulgación simple que ofrezca “Safe Harbor” y reconocimiento, sin dinero.
- Elija su modelo: Decida si gestionará el programa internamente (email de seguridad) o mediante una plataforma gestionada (HackerOne, Bugcrowd, Intigriti).
- Prepare a su equipo legal: Asegúrese de que sus abogados entiendan que “invitar a hackers” es beneficioso y redacten términos que protejan sin ahuyentar.
Lecturas relacionadas:
- ISO/IEC 29147:2018 – Vulnerability disclosure
- ISO/IEC 30111:2019 – Vulnerability handling processes
- Marco legal de “Safe Harbor” de disclose.io
- Guía de implementación de programas de Bug Bounty del Departamento de Justicia de EE.UU.
Base legal
La base legal de los programas de bug bounty se apoya en el derecho contractual. El programa constituye una oferta pública de recompensa condicionada al cumplimiento de unos términos y condiciones específicos. La cláusula de “Safe Harbor” actúa como una autorización explícita del propietario del sistema, protegiendo al investigador frente a leyes de acceso no autorizado como la Computer Fraud and Abuse Act (CFAA) en EE.UU. o los artículos relativos a delitos informáticos en los códigos penales de otros países (ej. Art. 197 del Código Penal español).
Además, se aplican normativas de propiedad intelectual (cesión de derechos sobre el hallazgo) y confidencialidad (NDA). En el ámbito de datos personales, el investigador actúa bajo instrucciones, debiendo cumplir con principios de minimización de datos según el RGPD u otras leyes de privacidad aplicables.
Consideraciones finales
El bug bounty ha democratizado la seguridad, permitiendo a las empresas acceder a una fuerza laboral global de talento. Pero esta relación simbiótica se basa enteramente en la confianza y la claridad legal. Un contrato vago es una bomba de tiempo. Un contrato claro, justo y con protecciones explícitas para ambas partes es el cimiento de una estrategia de seguridad moderna y resiliente.
Para la empresa, la inversión en definir estas reglas paga dividendos al filtrar el ruido y atraer a los mejores investigadores. Para el hacker ético, leer y entender el contrato no es burocracia, es autodefensa. En última instancia, el objetivo compartido es un internet más seguro, y los acuerdos legales bien diseñados son el protocolo que hace posible esa colaboración.
Punto clave 1: El “Safe Harbor” legal es esencial para proteger a los investigadores de buena fe.
Punto clave 2: La definición precisa del alcance (Scope) evita disputas y daños colaterales.
Punto clave 3: La confidencialidad y la divulgación coordinada protegen la reputación de la empresa.
- Revise sus términos actuales para asegurar que incluyen cláusulas de Safe Harbor explícitas.
- Establezca un proceso claro de triaje y pago para mantener la confianza de la comunidad.
- Considere seguros de ciberseguridad que cubran actividades de bug bounty.
Este contenido es solo informativo y no sustituye el análisis individualizado de un abogado habilitado o profesional calificado.