Cuando los investigadores deciden publicar: el coste de una divulgación mal gestionada

Los investigadores de seguridad eligen la divulgación total (full disclosure) en lugar de la divulgación responsable cuando pierden la confianza en el proceso del fabricante, no porque quieran causar daño. El detonante casi siempre es operativo: un informe que estuvo semanas sin respuesta, un parche que se publicó en silencio y sin crédito, o una severidad rebajada discretamente a “sin impacto”. Cuando un investigador concluye que coordinarse contigo es una pérdida de tiempo, publica. El fallo nunca fue el problema. El problema fue tu proceso de divulgación.

Este es el problema del “día 2” que la mayoría de los equipos ignora. Montar un programa de divulgación de vulnerabilidades es la parte fácil: un archivo security.txt, una declaración de alcance, un buzón. La parte difícil es operarlo de forma que los investigadores de verdad sigan reportando a ti en vez de sobre ti. Y en 2026, el coste de hacerlo mal ha quedado a la vista de todos.

La divulgación de github.dev que se saltó a Microsoft por completo

El 2 de junio de 2026, el investigador de seguridad Ammar Askar publicó una prueba de concepto completa para un robo de token OAuth de GitHub con un solo clic en github.dev, el editor de VS Code basado en navegador. El exploit encadenaba la propagación del evento keydown de los webviews de VS Code para instalar en silencio una extensión local y exfiltrar el token del usuario. El token robado no estaba limitado a un único repositorio: daba acceso a todos los repos a los que la víctima podía llegar, incluidos los privados (fuentes: BleepingComputer, CSO Online).

La severidad técnica era alta. Pero la parte que todo responsable de un programa debería estudiar es la propia divulgación.

Askar dio a GitHub solo una hora de aviso antes de hacerlo público, y se saltó deliberadamente por completo el Microsoft Security Response Center (MSRC). Su razón declarada: un bug anterior de VS Code que él había reportado se corrigió en silencio, sin crédito, y se marcó como “sin impacto de seguridad”. Concluyó que el proceso no trataría su trabajo de forma justa, así que dejó de participar en él. Un investigador colaborador se convirtió en alguien que publica un zero-day sin previo aviso por la manera en que se gestionó un informe anterior.

Ahí está toda la lección en una sola frase. El fallo de divulgación convirtió a un aliado en un adversario, y ninguna cantidad de excelencia técnica por parte de Microsoft pudo deshacerlo a posteriori. Microsoft sacó un parche provisional (una confirmación para los notebooks web y un bloqueo que impide saltarse la verificación de confianza del editor de la extensión), pero la confianza ya se había perdido, y el exploit sin parchear ya era público.

Divulgación responsable vs divulgación total, y por qué la línea se mueve

La divulgación responsable (también llamada divulgación coordinada de vulnerabilidades) es cuando un investigador reporta en privado y da al fabricante tiempo para corregir el problema antes de que aparezca cualquier detalle público. La divulgación total es cuando el investigador publica la vulnerabilidad, a menudo con un exploit funcional, antes de que exista un parche. La línea entre ambas no es un rasgo de personalidad. Depende de si el investigador cree que el fabricante cumplirá su parte.

El sector tiene relojes de referencia bien conocidos sobre lo que significa un “plazo justo para corregir”:

• Google Project Zero aplica un plazo de divulgación de 90 días, que baja a 7 días para bugs que se están explotando activamente.
• CERT/CC divulga 45 días después del informe inicial, haya o no un parche disponible.

(Fuentes: Guía de divulgación coordinada de vulnerabilidades del CERT/CC, Wikipedia: Divulgación coordinada de vulnerabilidades.)

Estas ventanas existen porque los investigadores necesitaban un estándar neutral al que apuntar cuando los fabricantes daban largas indefinidamente. Son el listón con el que un investigador frustrado te va a medir.

Qué le pide realmente la divulgación responsable a un fabricante

La divulgación responsable es un pacto de doble vía. El investigador se compromete a esperar y guardar silencio. A cambio, el fabricante se compromete a acusar recibo del informe rápidamente, comunicar con honestidad sobre la severidad y los plazos, corregir el problema y dar crédito. La mayoría de las políticas de divulgación publicadas lo plantean exactamente así: cooperación a cambio de una gestión de buena fe. Cuando una parte cumple su promesa y la otra no, el pacto se rompe.

Cuándo decide un investigador que no vale la pena

A los investigadores no se les paga por esperar. Muchos hacen este trabajo en su tiempo libre, y su reputación se basa en la atribución pública. Cuando un fabricante trata un informe como una molestia, lo ignora o le quita el crédito que justifica ese esfuerzo no remunerado, lo racional es dejar de coordinarse. Hacerlo público devuelve lo único que el proceso roto le quitó: la prueba visible de su trabajo.

Por qué los investigadores hacen pública la vulnerabilidad: los cinco verdugos de la confianza

Tanto en el incidente de github.dev como en la investigación más amplia sobre programas de divulgación, aparecen una y otra vez los mismos cinco fallos operativos. Ninguno es técnico. Cada uno es una decisión de proceso que tú controlas.

1. Acuse de recibo lento o inexistente. Un informe que se queda sin respuesta le dice al investigador que su tiempo no importa.
2. Rebajas de severidad injustificadas. Marcar un bug real como “sin impacto” o “severidad baja” se lee como mala fe, sobre todo cuando el investigador no puede ver el razonamiento.
3. Parches silenciosos sin crédito. Publicar el arreglo pero borrar el nombre del investigador elimina por completo su incentivo para reportar en privado.
4. Pago tardío o ausente. Cuando se promete una recompensa, los retrasos y las disputas corroen la confianza tan rápido como una rebaja de severidad.
5. Apagón de comunicación. Quedarse en silencio durante la ventana de corrección deja al investigador sin saber si se está haciendo algo en absoluto.

(Fuentes: OWASP Vulnerability Disclosure Cheat Sheet, Entrevista de HelpNetSecurity a Roy Davis, Zoom.)

Acuse de recibo lento o inexistente

El acuse de recibo es la señal de confianza más barata que tienes, y la más fácil de fallar. Un investigador que escribe a tu buzón y no recibe nada durante dos semanas no tiene forma de saber si estás trabajando en el problema o ignorándolo. Lo honesto es una confirmación rápida de que una persona recibió el informe y se hace cargo de él. Los programas gubernamentales lo dan por sentado: el Departamento de Comercio de EE. UU. y el Departamento del Interior se comprometen a acusar recibo de los informes en un plazo de 3 días hábiles, y Silicon Labs se compromete a lo mismo. Si las agencias federales pueden cumplir un listón de 3 días, una startup también puede.

Rebajas de severidad injustificadas

Las disputas por severidad son el segundo punto de fricción más habitual, y son evitables. El problema no es la calificación en sí; es que la calificación llega como un veredicto de caja negra que el investigador no puede inspeccionar ni rebatir. Una rebaja que parece una forma de esquivar un pago o de minimizar el bochorno se lee como mala fe aunque no lo sea. La solución es basar la severidad en un marco estándar y transparente (CVSS) y mostrar tus cálculos, para que el investigador vea los mismos datos de entrada que tú.

Parches silenciosos sin crédito

Este es el fallo que detonó la divulgación de github.dev. El investigador reportó un bug, el fabricante lo parcheó en silencio, y el nombre del investigador no apareció por ningún lado. Para alguien que ha forjado su carrera sobre la base de la atribución pública, un parche silencioso es peor que un rechazo. Se queda con el trabajo y con el reconocimiento. Dar crédito, ya sea con un agradecimiento en un CVE o con una entrada en un salón de la fama, no te cuesta nada y es la forma más fiable de conseguir que un investigador te siga reportando la próxima vez.

Pago tardío o ausente

Si tienes un programa con recompensas, el pago es una promesa. Los investigadores citan de forma constante los pagos inconsistentes o tardíos como motivo para abandonar programas. Un proceso de pago predecible y auditable importa más que una recompensa de cifra llamativa. La ambigüedad sobre cuándo y si van a cobrar hace más daño que una recompensa modesta pero fiable.

Apagón de comunicación

Aunque estés trabajando en ello, el silencio se interpreta como abandono. La guía de OWASP es explícita: envía actualizaciones periódicas de estado incluso cuando no haya avances que reportar, porque la propia actualización es la señal de que el informe no se ha olvidado. Un “seguimos en ello, esto es lo que tenemos hasta ahora” de una línea cada par de semanas suele ser la diferencia entre un investigador que espera y uno que publica.

Esto no es raro: la oleada de zero-days públicos de 2026

El incidente de github.dev no fue un caso aislado. En esa misma ventana de abril a junio de 2026, un investigador conocido como “Chaotic Eclipse” hizo públicos seis zero-days de Windows sin parchear, tres de los cuales ya se estaban explotando de forma activa en entornos reales (in the wild). Los motivos declarados eran una lista familiar: informes ignorados, una cuenta de reporte que habían eliminado, cero compensación, y la sensación de haber sido difamado por cómo un aviso de CVE describía su trabajo (fuentes: SecurityAffairs, The Hacker News).

Microsoft condenó públicamente las divulgaciones “no coordinadas” por poner a los clientes en riesgo innecesario, y luego tendió una rama de olivo tras la reacción en contra. La secuencia es muy reveladora: culpar al investigador no arregló el proceso, y no detuvo la siguiente divulgación. Cuando el mismo patrón de fallos produce varias divulgaciones públicas en un solo trimestre contra una de las organizaciones de seguridad con más recursos del planeta, deja de ser un problema de investigadores y pasa a ser un problema de diseño del programa.

Qué hace distinto un VDP en el que se puede confiar

Un programa fiable convierte cada uno de los cinco verdugos de la confianza en un compromiso con el que el investigador puede contar. La mecánica no tiene nada de exótico; es disciplina operativa aplicada de forma constante.

El hilo que recorre todo esto es el respeto por el tiempo y el trabajo del investigador. Acierta con eso y el reloj de divulgación se queda en privado. Falla y el investigador recurrirá a los 90 días de Project Zero o a los 45 del CERT/CC como el estándar que no cumpliste.

Cómo operacionaliza Kit la confianza de los investigadores

El módulo de seguridad de Kit (Csirt) se construyó precisamente en torno a estos modos de fallo. Formarte en el modelo operativo importa más que cualquier herramienta, pero el valor de una herramienta es que convierte el comportamiento correcto en lo predeterminado, en vez de en algo que tienes que recordar bajo presión. Aquí tienes cómo se asigna cada verdugo de la confianza a una configuración concreta.

Para ser claros sobre lo que Kit puede y no puede atribuirse: Kit no tiene nada que ver con el bug de github.dev, y ninguna herramienta lo habría “evitado”. Eso era el producto de Microsoft. Lo que Kit arregla es el fallo de proceso de divulgación que empujó al investigador a la divulgación total. Si tu empresa recibiera un informe como aquel, el SLA de acuse de recibo de Kit, la severidad CVSS transparente, el crédito por defecto y el pago predecible son lo que mantiene al investigador coordinándose contigo en vez de publicando un exploit sin parchear.

Tu proceso de divulgación es tu postura de seguridad

La conclusión de los zero-days públicos de 2026 es incómoda pero sencilla: los investigadores no publican porque sean hostiles. Publican porque el proceso faltó al respeto a su tiempo y a su trabajo. Un acuse de recibo lento, rebajas de severidad opacas, parches silenciosos, pagos tardíos y apagones de comunicación no son lapsus administrativos menores. Son la causa directa de que aparezcan exploits sin parchear en Hacker News con tu nombre encima.

Cada uno de esos fallos es una decisión que tú controlas, y cada uno se asigna a una configuración que puedes arreglar hoy. Si ya tienes un VDP, el siguiente paso no es más política; son las operaciones del “día 2” que mantienen a los investigadores de tu lado. Empieza por la guía de configuración si aún no has llegado ahí, y luego convierte tu recepción en un flujo respaldado por SLA, con crédito y con pago. Cuando estés listo para operarlo como es debido, puedes empezar una prueba gratuita y tenerlo todo funcionando en una tarde.