Reportar una vulnerabilidad que acabas de encontrar puede ser la decisión más inteligente —o más estúpida— de tu carrera en ciberseguridad. La diferencia entre acabar en un programa de bug bounty cobrando una recompensa o en un juzgado depende de cómo gestiones el proceso de divulgación responsable. Si alguna vez has pensado "encontré una vulnerabilidad, ¿y ahora qué?", esta guía te da los pasos exactos para hacer un responsible disclosure sin meterte en líos legales ni quemar puentes con la empresa afectada.
Qué es la divulgación responsable y por qué existe
La divulgación responsable (o coordinated vulnerability disclosure) es un acuerdo tácito entre quien encuentra un fallo de seguridad y quien lo tiene que arreglar. Tú reportas el problema de forma privada, la empresa lo parchea, y después —si ambas partes están de acuerdo— se publica la información para que la comunidad aprenda.
El concepto lo formalizó el CERT/CC de la Universidad Carnegie Mellon en los años 90, y hoy organizaciones como ISO (estándar ISO/IEC 29147:2018) y la Unión Europea con la directiva NIS2 lo reconocen como buena práctica. En España, el INCIBE (antes INTECO, desde 2006) opera como coordinador nacional para este tipo de reportes.
¿Por qué no publicarlo directamente en Twitter? Porque un full disclosure sin aviso previo expone a millones de usuarios antes de que exista parche. Y porque en muchos países —incluido España, con los artículos 197 y 264 del Código Penal— acceder a sistemas sin autorización puede tener consecuencias penales aunque tu intención sea buena. La línea entre investigador y delincuente la dibuja el procedimiento que sigas.
Antes de reportar: lo que debes y no debes hacer
Has encontrado un fallo. El corazón te va a mil. Para. Respira. Y sigue estas reglas antes de contactar con nadie.
Lo que SÍ debes hacer
- Documenta todo. Capturas de pantalla, logs, pasos para reproducir el bug, timestamps. Cuanto más detallado, más fácil será para el equipo de seguridad verificar y parchear.
- Limita tu acceso al mínimo. Si encontraste una SQLi, demuestra que funciona con un
SELECT 1, no descargues toda la base de datos "para probar". - Verifica que el fallo es real. Un falso positivo de un escáner automático no es una vulnerabilidad. Confirma manualmente antes de enviar el reporte.
- Busca la política de disclosure de la empresa. Muchas tienen un archivo
security.txten/.well-known/security.txt(estándar RFC 9116) con el contacto directo del equipo de seguridad. - Protege tu identidad si lo necesitas. Usa un email dedicado para security research. Si te preocupa tu anonimato en internet, considera usar una VPN de confianza para las comunicaciones.
Lo que NO debes hacer
- No exfiltres datos reales de usuarios. Ni uno. Ni "para demostrar el impacto".
- No modifiques ni borres nada. Tu prueba de concepto debe ser no destructiva.
- No amenaces con publicar. "Págame o publico el exploit" no es responsible disclosure, es extorsión.
- No uses herramientas automatizadas agresivas contra sistemas en producción. Un escaneo con Nmap está bien; lanzar SQLMap en modo agresivo contra una web de un hospital, no.
- No compartas el fallo con terceros antes de que la empresa lo parchee.
Cómo redactar y enviar un reporte de vulnerabilidad profesional
Un buen reporte de vulnerabilidad es la diferencia entre que te ignoren y que te den las gracias (o una recompensa). Aquí va la estructura que usan los profesionales de bug bounty.
Estructura del reporte
| Sección | Contenido |
|---|---|
| Título | Tipo de vulnerabilidad + componente afectado. Ej: "Stored XSS en el campo de comentarios de /blog" |
| Severidad | Usa CVSS v3.1 o v4.0 para calcularla. La calculadora de FIRST.org es tu amiga. |
| Descripción | Qué es, dónde está y qué impacto tiene. Sin jerga innecesaria. |
| Pasos para reproducir | Numerados, con URLs exactas, payloads y capturas. Quien lo lea debe poder replicarlo en 5 minutos. |
| Impacto | ¿Qué podría hacer un atacante real? ¿Afecta a datos de usuarios? ¿Permite escalada de privilegios? |
| Remediación sugerida | Opcional pero muy valorado. Si sabes cómo arreglarlo, dilo. |
| Tu contacto | Email y, si quieres reconocimiento público, tu nombre o handle. |
Por dónde enviar el reporte
- Plataformas de bug bounty: Si la empresa tiene programa en HackerOne, Bugcrowd o Intigriti, usa siempre la plataforma. Tienes protección legal y un canal estructurado.
- security.txt: Busca
https://dominio.com/.well-known/security.txt. Grandes empresas como Google, Microsoft o GitHub lo tienen. - Email directo:
security@empresa.comoabuse@empresa.com. Cifra con PGP si la clave está disponible. - Coordinadores nacionales: Si la empresa no responde, contacta con el INCIBE (España), CERT/CC (EEUU) o el CSIRT de tu país. Ellos actúan como intermediarios.
Envía el reporte y espera. El estándar de la industria da entre 90 días (política de Google Project Zero) y 120 días antes de considerar la publicación pública. Si la empresa no responde en 30 días, reenvía. Si siguen sin responder, escala al coordinador nacional.
Un detalle que pocos mencionan: activa la verificación en dos pasos en todas las cuentas que uses para security research. Sería irónico que te comprometieran a ti mientras reportas fallos ajenos.
Bug bounty: cuándo cobrar y cuánto esperar
Los programas de bug bounty son la cara amable de la divulgación responsable. Las empresas pagan por cada vulnerabilidad válida que reportes, con tarifas que varían enormemente según la gravedad y la empresa.
Google pagó más de 10 millones de dólares en recompensas solo en 2023, según su informe anual de seguridad. Apple ofrece hasta 2 millones por un exploit de ejecución remota sin interacción del usuario. En el otro extremo, una pequeña startup puede darte entre 50 y 500 euros por un XSS almacenado.
Algunas referencias de rangos habituales en plataformas como HackerOne (datos públicos de sus informes anuales):
- Crítica (RCE, bypass de autenticación masivo): entre 5.000 y 100.000+ USD
- Alta (SQLi, SSRF con impacto): entre 1.000 y 15.000 USD
- Media (XSS almacenado, IDOR): entre 250 y 3.000 USD
- Baja (information disclosure, clickjacking): entre 50 y 500 USD
No todos los programas pagan dinero. Algunos ofrecen swag (camisetas, stickers), reconocimiento público en un Hall of Fame, o simplemente un "gracias". Antes de invertir horas, lee las reglas del programa. Y ojo: si la empresa NO tiene programa de bug bounty, reportar una vulnerabilidad sigue siendo lo correcto, pero no esperes compensación económica.
Fiscalmente, las recompensas de bug bounty tributan como rendimientos de actividades económicas en España. Si esto se convierte en algo recurrente, habla con un gestor. Si necesitas montar la parte técnica de tu setup de investigación, en el blog de Piqture encontrarás recursos sobre herramientas y entornos de desarrollo.
Marco legal en España y la Unión Europea
Aquí viene la parte que todo investigador debería leer y que la mayoría ignora hasta que es tarde.
En España, el Código Penal contempla varias figuras relevantes. El artículo 197.1 castiga con prisión de 1 a 4 años el descubrimiento de secretos o la vulneración de la intimidad mediante el acceso a datos reservados. El artículo 197.3, que tipifica específicamente el acceso no autorizado a sistemas informáticos, prevé penas de 6 meses a 2 años de prisión. El artículo 264 añade penas por daños informáticos. La Ley Orgánica 1/2015 actualizó estas figuras, pero no incluyó una excepción explícita para investigadores de seguridad actuando de buena fe.
La directiva NIS2 de la UE (transpuesta parcialmente en 2024) sí reconoce la divulgación coordinada de vulnerabilidades y pide a los estados miembros que faciliten mecanismos para ello. Países como Países Bajos, Francia y Bélgica ya tienen guías oficiales que ofrecen protección legal a investigadores que siguen el proceso de responsible disclosure.
¿Qué te protege en la práctica?
- Actuar dentro del scope de un programa de bug bounty (sus términos legales son tu escudo).
- No causar daño: no exfiltrar datos, no interrumpir servicios, no modificar sistemas.
- Proporcionalidad: tu prueba de concepto debe ser mínima y no destructiva.
- Documentar tu buena fe: guarda todos los emails, reportes y comunicaciones.
- Usar el canal oficial: si existe security.txt o programa de bug bounty, úsalo.
Si trabajas como investigador de seguridad, mantén un backup automático de toda tu documentación y comunicaciones. Si algún día necesitas demostrar tu buena fe, lo agradecerás.
Preguntas frecuentes
¿Puedo reportar una vulnerabilidad de forma anónima?
Sí. Plataformas como HackerOne permiten perfiles pseudónimos, y puedes enviar emails cifrados con PGP desde cuentas dedicadas. Eso sí, si quieres cobrar una recompensa, en algún momento tendrás que verificar tu identidad para recibir el pago.
¿Qué hago si la empresa me amenaza con acciones legales tras reportar un fallo?
Contacta con organizaciones como la Electronic Frontier Foundation (EFF) o el INCIBE, que pueden mediar. Si seguiste un proceso de responsible disclosure documentado y no causaste daño, tu posición legal es sólida. No borres ninguna comunicación: es tu mejor defensa.
¿Cuánto tiempo debo esperar antes de hacer público un fallo no parcheado?
El estándar de la industria son 90 días desde la notificación (política de Google Project Zero). Si la empresa responde y pide más tiempo con justificación razonable, lo habitual es conceder una extensión. Si no hay respuesta alguna tras 90 días y varios intentos de contacto, la comunidad de seguridad generalmente considera aceptable la publicación.
¿Necesito ser un hacker profesional para encontrar y reportar vulnerabilidades?
No. Muchas vulnerabilidades críticas las descubren usuarios atentos que notan comportamientos extraños. Un IDOR (acceso a datos de otros usuarios cambiando un ID en la URL) no requiere conocimientos avanzados para detectarlo. Lo que sí necesitas es seguir el protocolo de reporte correctamente.
¿Los programas de bug bounty cubren aplicaciones móviles y dispositivos IoT?
Muchos sí. Empresas como Tesla, Samsung y Philips incluyen firmware y apps móviles en sus programas. El IoT es un campo con mucha superficie de ataque y relativamente pocos investigadores, así que las recompensas suelen ser competitivas. Si te interesa el mundo de los dispositivos conectados, el blog de domótica cubre bastante el ecosistema.
El siguiente paso
Busca ahora mismo el archivo /.well-known/security.txt de cinco servicios que uses a diario. Comprueba si tienen programa de bug bounty y léete las reglas. Familiarizarte con estos documentos antes de necesitarlos te ahorrará errores cuando encuentres un fallo real. Si ya tienes una vulnerabilidad entre manos, abre la calculadora CVSS de FIRST.org, evalúa la severidad, redacta el reporte siguiendo la estructura de esta guía, y envíalo al canal correcto. El resto es paciencia y profesionalidad.
