¿Puerto seguro o demanda? La cláusula del VDP que te protege

El puerto seguro (Safe Harbor) en una política de divulgación de vulnerabilidades es un texto explícito que promete que tu organización no emprenderá acciones legales contra los investigadores de seguridad que reporten vulnerabilidades de buena fe. Convierte las expectativas vagas sobre el comportamiento “responsable” en un contrato escrito: si te mantienes dentro del alcance, no extraes datos, no interrumpes el servicio y reportas por el canal oficial, tienes autorización para probar. Sin esa cláusula, leyes antihacking de hace décadas dejan expuestos incluso a quienes reportan de forma ética, y el investigador que encontró tu fallo tiene todos los motivos para callarse o vender el hallazgo.

En mayo de 2026, Microsoft le enseñó a toda la industria lo que pasa cuando esa cláusula falta o se ignora. La historia es un caso de estudio casi perfecto de cómo una política ambigua sumada a una amenaza legal automática destruye en una noche la confianza de los investigadores. La buena noticia para los fundadores: el fallo fue organizativo, no técnico, lo que significa que una startup puede evitarlo desde el primer día con la política y el proceso adecuados.

Lo que Microsoft acaba de hacer (y deshacer a toda prisa)

Microsoft amenazó a un investigador de seguridad con una investigación penal, encajó días de reacción pública de la comunidad de infosec y luego se retractó en público. Todo el arco se desarrolló en aproximadamente un mes.

A principios de abril de 2026, un investigador con seudónimo conocido como “Nightmare-Eclipse” empezó a publicar abiertamente código de prueba de concepto (proof of concept) para una serie de zero-days de Windows sin coordinar antes con Microsoft. La cuenta era un blanco móvil: unos seis fallos a finales de mayo (con nombres como BlueHammer, RedSun, UnDefend y YellowKey, un bypass crítico de BitLocker registrado como CVE-2026-45585), que siguieron creciendo a medida que la disputa se alargaba hasta junio. Microsoft publicó una entrada de blog calificando la divulgación no coordinada de “nunca justificable”. Su Digital Crimes Unit afirmó que “seguirá llevando casos contra estos actores y contra quienes facilitan su actividad delictiva, coordinándose según haga falta con las fuerzas del orden de todo el mundo”.

La comunidad lo leyó como una amenaza de proceso penal dirigida a un investigador. La reacción fue inmediata y brutal. Alrededor del 1 y 2 de junio de 2026, Microsoft dio marcha atrás y declaró que no tenía “ninguna intención de emprender acciones contra personas que realicen o publiquen su investigación de seguridad”, con la salvedad de que colaboraría con las fuerzas del orden cuando alguien “infringe la ley y se dedica a actividad maliciosa que causa daño real a nuestros clientes”.

Un detalle es más revelador que la propia rectificación. Durante la crisis, Microsoft cambió discretamente la expresión “divulgación responsable” por “Divulgación Coordinada de Vulnerabilidades” en su comunicación. Ese cambio de palabra, sobre el que volveremos, era una señal delatora.

Por qué este es el fallo de confianza número uno en la divulgación

El daño aquí no lo causó un exploit ingenioso. Lo causó la ambigüedad. Cuando una política no dice por escrito que los investigadores de buena fe están a salvo, cada informe se vuelve una apuesta, y el humor del proveedor en un día cualquiera decide si un desconocido servicial es un colaborador o un acusado.

La contradicción lo empeoró todo. Kevin Beaumont, investigador de seguridad y exempleado de Microsoft, calificó el episodio de “un incendio que ellos mismos provocaron”, señalando que Microsoft ya había contratado antes a SandboxEscaper, una investigadora que había publicado código de prueba de concepto de zero-days de Windows, exactamente la conducta que la entrada de blog de la empresa ahora pintaba como delictiva. La aplicación inconsistente de las reglas es indistinguible de no tener ninguna política. Si los investigadores no pueden predecir cómo vas a reaccionar, suponen lo peor.

Katie Moussouris, que diseñó el programa original de recompensas por fallos de Microsoft y hoy dirige Luta Security, advirtió de “un efecto inhibidor en el que menos gente se anima a reportar fallos, lo que nos deja a todos menos seguros”. Esa es la lección de fondo. Una amenaza por divulgación no solo castiga a un investigador. Le enseña a los siguientes cien a quedarse callados.

Qué significa realmente el “puerto seguro”

El puerto seguro es la cláusula que elimina la apuesta. Es una promesa escrita, publicada en tu política, de que los investigadores que actúen de buena fe no serán demandados ni denunciados para su procesamiento.

Para acogerse a la protección, los investigadores suelen tener que cumplir una breve lista de condiciones:

1. Actuar de buena fe, con la intención de mejorar la seguridad, no de extorsionar ni causar daño.
2. Mantenerse dentro del alcance definido de los activos que has autorizado a probar.
3. Evitar violaciones de la privacidad y la extracción de datos, accediendo solo a lo mínimo necesario para demostrar un fallo.
4. Evitar la interrupción del servicio, sin pruebas de denegación de servicio ni destructivas.
5. Reportar por el canal oficial y conceder un plazo razonable para corregir antes de la divulgación pública.

Esto no es teoría legal marginal. El marco de puerto seguro de disclose.io, un estándar de código abierto, fue adoptado en 2020 por CISA, fabricantes de máquinas de votación y varios estados de EE. UU., y viene activado por defecto en los programas de Bugcrowd. HackerOne mantiene un “Gold Standard Safe Harbor”. Dropbox, Mozilla y los programas de la época de GitHub usan todos versiones de él. El puerto seguro es ya la referencia generalizada, que es justo por lo que su ausencia se lee como una señal de alarma para las personas que más te interesa que reporten.

¿La ley ya protege a los investigadores? En general, no

Muchos fundadores dan por hecho que, como el Departamento de Justicia de EE. UU. suavizó su postura sobre la Computer Fraud and Abuse Act, los investigadores ya están a salvo y una cláusula a medida es innecesaria. Esa suposición es errónea en dos sentidos importantes.

El 19 de mayo de 2022, el DOJ revisó su política de imputación bajo la CFAA para declarar que no perseguiría la investigación de seguridad de buena fe. Eso fue un avance real. Pero el propio DOJ fue explícito en que el cambio no afecta a la responsabilidad civil y no vincula a las leyes estatales sobre delitos informáticos. Como señaló el bufete Wilson Sonsini en su análisis, siguen existiendo dudas y una posible responsabilidad civil para los investigadores.

Tradúcelo a términos llanos. Una empresa todavía puede demandar a un investigador en un juzgado civil. Un fiscal estatal que actúe bajo una ley antihacking estatal todavía puede presentar cargos. El escudo penal federal es estrecho, y no está en tu mano ampliarlo. El único instrumento que cierra esas brechas para quienes prueban tus sistemas es el texto de puerto seguro en tu propia política. La ley fija un mínimo; tu política es lo que hace real la invitación.

Divulgación “responsable” frente a “coordinada”: las palabras importan

La terminología que elijas indica si ves a los investigadores como colaboradores o como sospechosos, y la industria se ha alejado deliberadamente del término cargado.

“Divulgación responsable” está cargada de valores. Da a entender de forma sutil que cualquiera que no siga el calendario preferido del proveedor está siendo irresponsable, lo que pone toda la carga moral sobre quien reporta y ninguna sobre el proveedor que se sentó encima del parche. CERT/CC y la mayor parte de la comunidad de seguridad usan hoy Divulgación Coordinada de Vulnerabilidades (CVD), que describe el proceso sin el dedo acusador. Plantea la divulgación como un problema de coordinación entre dos partes, que es lo que es en realidad.

Esto no es discutir por discutir. Recuerda que la propia Microsoft pasó de “responsable” a “coordinada” en plena crisis. Moussouris señaló el encuadre original como “el primer golpe”. Cuando la empresa que está en el ojo del huracán cambia su vocabulario bajo presión, eso te dice qué palabra escuchan las personas que reportan fallos. Usa “coordinada” en tu política. No cuesta nada y transmite respeto.

El coste de no tener un VDP: silencio o el mercado gris

Cuando los investigadores no pueden reportar de forma segura, la vulnerabilidad no desaparece. Simplemente no te enteras de ella hasta que está convertida en arma, porque quien la encontró se calló o encontró un comprador que paga mejor.

La magnitud de la brecha es grande. Según el propio recuento de HackerOne, el 93 % de las empresas del Forbes Global 2000 no tiene una vía publicada para que los investigadores reporten un problema de seguridad. Es un dato de HackerOne más que un censo independiente, pero la dirección no es discutible: la mayoría de las organizaciones no tiene puerta de entrada.

El mercado alternativo es de una economía despiadada. Los precios de los exploits en el mercado gris empequeñecen cualquier recompensa de un proveedor. Brókeres como Crowdfense han anunciado hasta unos 9 millones de dólares por una cadena completa de exploits zero-click para móvil; los exploits de navegador alcanzan entre 3 y 3,5 millones de dólares; Zerodium ha anunciado hasta 2 millones de dólares por una cadena de ejecución remota de código en Android. No estás compitiendo con esos precios, ni tienes por qué hacerlo. Solo necesitas que reportar de forma coordinada sea suficientemente seguro y sin fricción como para que un investigador elija la vía legal. Una carta con amenazas lo empuja en la dirección contraria.

Los cinco ingredientes de una política que protege a ambas partes

Una política de divulgación que funciona es corta y concreta. Tiene cinco partes, y un investigador debería poder leerla en dos minutos y saber exactamente qué está permitido.

En cuanto a los plazos, ánclate a normas establecidas para que ninguna parte tenga que negociar desde cero. La ventana de divulgación estándar de facto en la industria ronda los 90 días; CERT/CC usa por defecto unos 45 días; Google Project Zero aplica un plazo de 7 días para fallos bajo explotación activa. Un SLA de acuse de recibo de 24 a 48 horas es práctica común y la señal de confianza más barata que puedes ofrecer. La queja central del investigador Nightmare-Eclipse era el maltrato (una cuenta revocada, una recompensa retenida y la atribución eliminada), no la ausencia de un pago. Acierta con las señales de confianza y la mayoría de las disputas ni siquiera empiezan.

Cómo montar uno desde el primer día, sin la carga de una gran empresa

La razón por la que la mayoría de las startups se saltan el VDP no es que estén en desacuerdo con nada de lo anterior. Es que la guía existente es o bien un estándar abstracto o bien una plantilla legal, sin ningún programa en funcionamiento detrás. OWASP te da la teoría. disclose.io te da la cláusula. Ninguno te da el triaje, los SLA ni un sitio donde los investigadores puedan realmente presentar un informe y ver cómo avanza.

Esta es exactamente la brecha que cierra el módulo de seguridad de Kit. En lugar de coser a mano un documento de política, un formulario de contacto y una hoja de cálculo, configuras un único programa que se corresponde directamente con los cinco ingredientes de arriba:

• El puerto seguro y el alcance forman parte de la configuración del programa, de modo que el texto de autorización y la lista de activos dentro de alcance viven en la política que lee el investigador, no en la memoria de un fundador.
• Un flujo de configuración guiado lleva a una cuenta nueva de cero a un programa en vivo, para que el “y por dónde empiezo” nunca se convierta en un callejón sin salida.
• Un flujo de trabajo estandarizado de divulgación coordinada gestiona el triaje, la evaluación de severidad y la comprobación de duplicados igual para todos los que reportan, que es la consistencia que le faltó a Microsoft.
• Las señales de confianza de cara al investigador vienen integradas: mensajería dentro del programa, estado de triaje transparente, karma del investigador y un rastro limpio de recompensas y libro mayor, para que nadie se sienta ignorado ni estafado.
• SLA comprometidos y cronologías visibles mantienen la respuesta rápida y auditable, eliminando el patrón lento-y-silencioso que empuja a los investigadores hacia la divulgación pública.

Una salvedad honesta, porque todo el sentido de este artículo es no prometer de más. Kit te da el andamiaje operativo y el sitio adecuado donde poner el texto de puerto seguro. No es asesoramiento legal. Haz que un abogado revise el texto final de tu política antes de publicarlo, sobre todo la redacción de la autorización y del alcance. Decirlo en voz alta es en sí mismo una señal de confianza, y encaja con la tesis: la claridad siempre le gana a la ambigüedad.

Si quieres la mecánica más a fondo, nuestra guía sobre cómo montar un programa de divulgación de vulnerabilidades cubre la fontanería de la recepción de informes, y cuando los investigadores se van a lo público profundiza en por qué lo que produce las filtraciones de zero-days es la gestión lenta, no la hostilidad. Si lanzas producto en la UE, el plazo de divulgación del Cyber Resilience Act convierte una política de CVD en un requisito legal, no solo en una buena práctica.

El checklist de un fundador para el primer día

No necesitas un equipo de seguridad para esto. Necesitas una tarde. Esto es lo mínimo:

1. Publica una cláusula de puerto seguro que declare que no emprenderás acciones legales contra investigadores de buena fe que se mantengan dentro del alcance. Toma como base disclose.io y haz que un abogado la revise.
2. Define tu alcance de forma explícita: qué dominios y activos están en juego, y qué queda fuera de los límites (sin extracción de datos, sin DoS, sin ingeniería social, sin servicios de terceros).
3. Abre un único canal de reporte y anúncialo con un archivo security.txt en /.well-known/security.txt.
4. Comprométete a un SLA de respuesta: acusa recibo en 48 horas y da un plazo realista de corrección y divulgación.
5. Usa divulgación “coordinada”, no “responsable”, en todo momento, y promete atribución a quien la quiera.

El error de Microsoft fue echar mano de una amenaza legal cuando debería haber echado mano de una política clara. Una startup tiene la ventaja de construir primero la política, antes del primer investigador enfadado, antes del primer informe incómodo en support@, antes de que el recuento de fallos sin corregir empiece a subir en público. Codifica ahora el puerto seguro, el alcance, los SLA y las señales de confianza en tu programa de divulgación, y nunca tendrás que escribir después la entrada de blog de disculpa.

Monta esta tarde un VDP seguro para los investigadores, no el trimestre que viene. Empieza gratis con Kit y configura tu programa de divulgación en un solo sitio.