En la seguridad informática es normal que dada la inquietud que provoca la profesión, investigando nos encontremos con algún fallo de seguridad en alguna página web o un fallo a nivel de infraestructura, Sistema operativo, servicios como DNS, LDAP, Active Directory, lo importante es saber Reportar vulnerabilidades de forma segura.
¿Qué hacer para Reportar vulnerabilidades de forma segura?
Si encontramos una vulnerabilidad podemos estar ante varias situaciones:
Tabla de Contenido
Que el fabricante o propietario de la página web tenga un servicio de Bug Bounty.
Que en el sitio de la vulnerabilidad haya una sección dedicada a reportar fallos de seguridad, mediante el envío de un correo electrónico por ejemplo que no haya nada, ni servicio de Bug Bounty ni sección dedicada a la seguridad.
La normativa de delitos telemáticos es distinta en cada región. En España tenemos una, en Colombia habrá otra por lo tanto a la hora de reportar una vulnerabilidad hemos de vigilar bien donde lo reportamos.
Como no soy Colombiano voy a explicar casos que he leído por ahí y como se acabó reportando la vulnerabilidad en cuestión.
Actualización 2026: la divulgación coordinada es hoy el estándar profesional
La idea central de este artículo no ha cambiado: encontrar una vulnerabilidad es solo la mitad del trabajo; reportarla por el canal correcto y de forma segura es lo que la convierte en una contribución en lugar de un problema legal. Lo que sí ha madurado enormemente desde 2014 es el ecosistema que rodea ese reporte.
Hoy existe un marco formal y ampliamente adoptado: la divulgación coordinada de vulnerabilidades (coordinated vulnerability disclosure). El estándar público ISO/IEC 29147 define cómo deben los fabricantes recibir, procesar y resolver los reportes de vulnerabilidades, y la mayoría de las empresas tecnológicas serias publican hoy una política de divulgación responsable (a menudo en un archivo security.txt o en una página de seguridad) que indica exactamente a dónde reportar, qué alcance está permitido probar y qué plazos de respuesta comprometen. Antes de reportar, el primer paso profesional es buscar esa política: define las reglas del juego y, en muchos casos, ofrece protección legal (safe harbor) al investigador que la respeta.
Además, el panorama de plataformas de bug bounty se consolidó: directorios públicos de programas como HackerOne, Bugcrowd y YesWeHack permiten encontrar en minutos qué empresas aceptan reportes, cuáles pagan recompensas y cuáles son sus reglas. Si el fabricante tiene un programa en alguna de estas plataformas, ese es el canal preferente: el reporte queda documentado, mediado y trazable desde el primer mensaje.
Reporte de la vulnerabilidad contactando al propietario del Whois
Si encontramos una vulnerabilidad en un dominio el cual no tiene sección para reportar la vulnerabilidad, una de las opciones es mirar los contactos del Whois. En este caso miramos el de DragonJAR.
Registrant Email:dragonjar(arroba)gmail.com Admin ID:CR34508516 Admin Name:Jaime Restrepo Admin Organization:Arnoldo Viafara Valencia Admin Street1:carrera 11 No 18-10 Admin Street2:click Admin Street3: Admin City:manizales Admin State/Province: Admin Postal Code:57 Admin Country:CO Admin Phone:+57.8829246 Admin Phone Ext.: Admin FAX: Admin FAX Ext.: Admin Email:dragonjar(arroba)gmail.com Tech ID:CR34508515 Tech Name:Jaime Restrepo Tech Organization:Arnoldo Viafara Valencia Tech Street1:carrera 11 No 18-10
Aquí le podríamos enviar un correo a Jaime, con lo que hubiéramos encontrado.
Quiero destacar en este punto que:
El hecho de reportar una vulnerabilidad al contacto del dominio no significa que sea legal y que, el propietario del dominio haga algo por solucionarlo, y no nos denuncie porque podríamos haberle dejado sin servicios dependiendo del fallo que se quería explotar.
Actualización 2026: cómo elegir el canal de reporte hoy
El artículo original describe cuatro vías que siguen existiendo (contacto directo con el propietario, fuerzas de seguridad, CERTs e intermediarios como ZDI), pero hoy conviene ordenarlas por prioridad:
- 1. El canal oficial del fabricante: su política de seguridad, su programa de bug bounty o su contacto de seguridad. Es la vía más rápida y la que mejor protege al investigador.
- 2. Plataformas de bug bounty: si no hay canal directo pero la empresa tiene programa en HackerOne, Bugcrowd o YesWeHack, repórtalo allí.
- 3. CERTs y coordinadores: cuando el fabricante no responde o no existe un canal claro, los equipos de respuesta a incidentes (como los CERT nacionales o coordinadores internacionales) siguen siendo la vía institucional correcta, tal como plantea el artículo.
- 4. Intermediarios y brókers: iniciativas como ZDI (Zero Day Initiative) continúan operando como intermediarios entre investigadores y fabricantes.
Y una regla que el artículo ya anticipaba y que hoy es innegociable: nunca pruebes más allá del alcance permitido ni accedas a datos de terceros para «demostrar» el fallo. Un reporte profesional incluye la descripción técnica, los pasos de reproducción y el impacto potencial, sin exfiltrar información ni degradar el servicio. Documenta todo desde el inicio: fechas, capturas y comunicaciones son tu respaldo si el proceso se complica.
Contacto con las FCSE (Fuerzas y cuerpos de seguridad del estado)
No tengo constancia como funciona en otros países, pero si que tengo claro a donde he acudido yo cuando he tenido que enfrentarme a un problema de este tipo.
La Unidad de delitos telemáticos de la Guardia Civil tiene una sección para ocuparse de estos menesteres.
Rellenas la información con los datos que tienes y ellos se encargarán de avisar a la persona adecuada.
La verdad es que los considero como la primera opción para el reporte de algunas vulnerabilidades. Y hacen un trabajo excelente desde aquí todo mi apoyo a dicha unidad :D.
Reportar vulnerabilidades a los CERTS (Computer Emergency Response Team)
Un centro de respuesta ante incidentes es y debe de ser una de las opciones disponibles a la hora de reportar una vulnerabilidad. Ellos gestionan las vulnerabilidades de la región, pero también tendrán y lo harán muy bien que gestionar aquellas vulnerabilidades de otras regiones.
Si les mandamos una vulnerabilidad que no les pertenezca ellos se pondrían en contacto con el CERT o entidad responsable correspondiente para reportar la vulnerabilidad.
Los CERT al igual que la unidad de delitos telemáticos son una muy buena opción para estos reportes.
Utilizar a un tercero para reportar vulnerabilidades de forma segura
Otra de las cosas que se pueden hacer es «vender» la vulnerabilidad, uno de los ejemplos es ZDI, creo que es la más famosa para vender vulnerabilidades. Ellos te pagan por la vulnerabilidad y se ponen en contacto con el fabricante.
Podemos ver las especificaciones aquí => https://www.zerodayinitiative.com/about/benefits/
¿Tu empresa recibe reportes de seguridad o necesita un programa de gestión de vulnerabilidades? En DragonJAR ofrecemos servicios de seguridad informática que incluyen pruebas de penetración, auditorías y acompañamiento en la gestión responsable de vulnerabilidades. Solicita una cotización aquí.
