Una campaña de divulgación masiva de vulnerabilidades es un único remitente que hace llegar muchos hallazgos a muchas partes sin relación entre sí, a la vez y con el calendario que él mismo fija. El Security Disclosure Ledger público de Z.ai registra **2 436 hallazgos en 269 proyectos de código abierto**, 107 de ellos críticos y 990 altos, con una media de **26,6 años** entre el momento en que se escribió el defecto y el momento en que alguien lo encontró. Una auditoría independiente del campo de estado de ese registro encontró **2 239 hallazgos todavía marcados como `discovered`** y exactamente uno como `sent to maintainer`. La recepción informe a informe —un acuse de recibo, un reloj de SLA y una decisión de severidad por cada uno— se rompe en cuanto toca algo con esa forma.

Este es el tercer artículo de una serie, y la distinción lo es todo. [El artículo sobre la basura generada por IA](/blog/ai-slop-flooding-bug-bounty-triage) iba de informes **inválidos** que llegan en masa. [El de la economía](/blog/ai-cheap-vulnerability-research-vdp-triage-economics) iba del coste de encontrar un fallo real, desplomado hasta rondar el precio de una comida. Este no va de ninguna de las dos cosas: estos hallazgos son en su mayoría válidos y nadie los pidió. [El artículo sobre varios proveedores](/blog/coordinated-disclosure-multi-vendor-vulnerabilities) cubría un fallo que aterrizaba en cinco proveedores. Esto es un solo remitente que aterriza en 269 proyectos: el mismo problema de gobernanza del revés, con la fecha límite en manos de quien tiene un lanzamiento de producto.

## 2 436 hallazgos, 269 proyectos y un solo remitente

El 14 de agosto de 2026, Z.ai lanzó GLM-5.3 y publicó ese mismo día un Security Disclosure Ledger en `cvd.z.ai`. Lo que merece una lectura atenta no es la nota del benchmark, sino el registro.

| Dato | Cifra |
|---|---|
| Total de hallazgos | 2 436 en 269 proyectos de código abierto |
| Reparto por severidad | 107 críticos, 990 altos, 1 286 medios, 53 bajos |
| Divulgados públicamente | 53 con identificador CVE; 2 383 sin divulgar |
| Antigüedad media del fallo | 26,6 años desde que se introduce hasta que se descubre |
| Código afectado más antiguo | 1981, un arco de 45 años |

Entre los hallazgos divulgados con nombre propio están la pila 6lowpan del kernel de Linux, WebKit, el `ptrace` de FreeBSD, GStreamer y Suricata. Z.ai señala que GLM-5.3 obtiene un **84,5 %** en CyberGym, frente al 77,2 % de GLM-5.2. El hilo de Hacker News llegó a 1 170 puntos y 584 comentarios, y las críticas más afiladas no apuntaban al modelo, sino a escanear código abierto a gran escala sin ninguna política de embargo.

Dos advertencias antes de construir nada sobre estas cifras.

**La campaña no es obra de un solo modelo.** Z.ai afirma que arrancó en la época de GLM-5.2, con varios equipos de seguridad y varios arneses, y los avisos de los proyectos afectados atribuyen los hallazgos a versiones distintas de GLM. Escribe «la campaña de Z.ai», nunca «GLM-5.3 encontró 2 436 fallos».

**Todos los agregados que aparecen aquí se apoyan en la publicación de la propia Z.ai.** Nadie fuera de la empresa puede auditar los 2 383 registros sin divulgar. No es un ataque a Z.ai: es exactamente la posición en la que estarás tú cuando te caiga un lote de cuarenta en el buzón. En el momento de la recepción no puedes verificar lo que afirma un remitente masivo, y yo tampoco puedo verificar estas cifras.

## Por qué esto no es la historia de la basura generada por IA, ni la del descubrimiento barato

El problema de la basura generada por IA era de relación señal-ruido. El de la economía, de coste unitario. Este es de **forma**, y la forma es lo que rompe las herramientas.

Un VDP normal da por hecho una relación de muchos a uno: muchos investigadores independientes, cada uno con un informe, cada uno acogido a tu política por el mero hecho de enviar bajo ella. Una campaña masiva invierte eso. Un solo remitente se dirige a 269 destinatarios a la vez, con un calendario que fija él, y publica un registro público antes de haber contactado con casi ninguno.

Quien recibe no aceptó nada, no acordó ningún plazo y, en la mayoría de los casos, ni siquiera está enterado. Eso no es un envío a un programa de recompensas. Se parece más a una **campaña de notificación masiva de vulnerabilidades**, algo que la investigación en seguridad lleva una década estudiando. Y sabe que su tasa de respuesta es lamentable.

## El cuello de botella es notificar, no parchear

El dato más útil del registro no es el 2 436. Es dónde se han quedado esos hallazgos.

Una auditoría del propio campo de estado del registro, capturada el 14 de agosto, anotó: **2 239 en `discovered`, 84 en `reported`, 53 en `revealed`, 29 en `acknowledged`, 30 en `patched` y 1 en `sent to maintainer`.** Es decir, alrededor del **92 %** de los hallazgos sigue en el lado de quien informa.

Anthropic hizo el mismo movimiento dos meses antes y le auditaron el resultado. El análisis de VulnCheck del 9 de junio de 2026 sobre el registro Mythos de Anthropic encontró **23 019 candidatos a vulnerabilidad**, de los cuales 467 se validaron y se comunicaron, y otros 1 129 se comunicaron sin validar. Son **1 596 hallazgos, un 6,9 %, que llegan a los mantenedores en 60 días**, un ritmo que VulnCheck cifró en unos **2,4 años para vaciar la cola**. También encontró **diez hallazgos que ya habían superado el plazo de 90 días de la propia Anthropic** sin publicarse, y otros 168 que vencían en menos de 30 días.

Dos proveedores, dos registros, un mismo resultado estructural: **el descubrimiento escala y la notificación no.** Un modelo encuentra un desbordamiento de heap en una base de código de 1994 en cuestión de minutos. Localizar al mantenedor, escribir un informe sobre el que una persona pueda actuar y acompañarlo hasta el parche sigue siendo el mismo trabajo humano de siempre.

Para quien recibe, esa es una buena noticia con fecha de caducidad. La ola todavía no te ha alcanzado y, cuando llegue, llegará en **lote**, porque quien informa está vaciando una cola, no abriendo una incidencia.

## Qué se rompe cuando llegan 40 informes del mismo remitente

Tres fallos mecánicos, ninguno discutible. En los tres casos, tu automatización actual funciona exactamente como se diseñó.

**El acuse de recibo se multiplica.** Una respuesta automática por informe es correcta con uno y abusiva con cuarenta. Quien informa recibe cuarenta correos que nadie quería, tu dominio manda cuarenta mensajes casi idénticos a una sola dirección y, después de todo eso, la otra parte sigue sin saber quién se encarga del lote ni cuándo lo mirará una persona.

**Los SLA no se suman.** Arrancan cuarenta relojes de acuse de recibo a la vez; cada uno se cumple de sobra en 72 horas por separado, pero juntos son una carga de triaje para la que nadie dimensionó la rotación de guardias. Tu cola marca verde informe a informe y es inabarcable en conjunto. Ese es el modo de fallo que documentaba el [artículo sobre varios proveedores](/blog/coordinated-disclosure-multi-vendor-vulnerabilities), pero del revés: allí un caso tenía muchos relojes; aquí muchos casos comparten un mismo techo de capacidad.

**La severidad antes que la causa raíz.** El triaje informe a informe pregunta primero «¿cómo de grave es este?». En una campaña, esa es la segunda pregunta. La primera es «¿es sólido el método de este remitente y comparten causa raíz estos hallazgos?». Cuarenta hallazgos salidos del mismo arnés contra el mismo parser suelen ser una única clase de fallo con cuarenta puntos de llamada. Pasarlos por triaje uno a uno cuesta cuarenta veces más y da una respuesta peor, porque el patrón solo se ve en conjunto.

Los tres fallos vienen de una única decisión de modelado: **la unidad de trabajo es el informe.** En una campaña, no lo es.

## Una campaña no es un informe: qué debe modelar tu recepción

El arreglo es un objeto de lote por encima del informe. Cinco campos concentran casi todo el valor.

1. **Un lote, un acuse de recibo.** Una sola respuesta que nombre el lote, diga cuántos hallazgos han llegado y se comprometa a una fecha para la primera respuesta sustantiva. Si hay identificador de lote, silencia el correo por informe.
2. **Un responsable.** Una persona con nombre y apellidos que responda del lote, y no cuarenta asignaciones rotativas.
3. **Un reloj compartido para el lote**, con relojes por hallazgo debajo. El acuse de recibo es una obligación del lote; la corrección es de cada hallazgo.
4. **Una valoración del método registrada una sola vez.** ¿Es sólido el arnés? ¿Se pueden ejecutar las PoC? Responde para el lote, hereda esa respuesta y revísala solo donde un hallazgo la contradiga.
5. **Agrupar por causa raíz antes de puntuar la severidad.** Primero agrupa; después puntúa los grupos, no las filas.

Kit todavía no trae esto. Su vertical `Csirt::` trata `Csirt::Report` como el registro de primer nivel: no hay objeto de campaña ni lote de envío. Cuarenta informes son cuarenta filas, cuarenta correos de acuse de recibo, cuarenta relojes de SLA y cuarenta avisos a la guardia. Ese es el argumento central de este artículo, y es una carencia de nuestro propio producto, no una función suya. Los cinco campos de arriba son la forma que creemos que debería tener.

## ¿Quién se hace cargo del reloj de la divulgación cuando el remitente es un proveedor de modelos?

Nadie, salvo que lo dejes por escrito.

Ninguna ley fija la divulgación coordinada en 90 días. Existe la costumbre —el 90+30 de Project Zero, el 90+14 de ZDI para proveedores que colaboran— y luego está quien publica primero. Cuando quien informa es un proveedor de modelos, la fecha límite queda enredada con el **marketing de lanzamiento**, porque el registro es tanto una demostración de capacidades como un documento de divulgación.

Z.ai no ha publicado ninguna política de embargo en el registro: ni página de política, ni plazo por hallazgo, ni cuenta atrás. Solo estado, severidad e identificadores. Es más transparente que escanear en silencio, y aun así te deja sin ninguna fecha declarada.

Anthropic sí publicó un plazo de 90 días, y VulnCheck encontró diez hallazgos que se lo habían saltado sin llegar a publicarse. Así que la elección no es entre un proveedor con política y otro sin ella. Es entre una fecha en **tu** registro y una fecha en el calendario editorial de otro.

Tres campos cierran esa brecha: `requested_embargo_at` (lo que pidió quien informa), `agreed_embargo_at` (lo que negociaste) y `published_at` (lo que pasó). Kit no los tiene, y lo dice en su propia página de comparación: *«Kit no modela ningún temporizador de divulgación ni fecha de embargo. Un campo de fecha de embargo es una petición razonable; hoy Kit sigue el acuse de recibo, no la divulgación.»* La única constante de 90 días que hay en el código es la caducidad de un token de recibo, no un reloj de divulgación.

## Los límites de envío son la defensa equivocada: qué consiguió de verdad el tope de Apple

El primer impulso al leer todo esto es frenar a quien informa. Apple hizo ese experimento en público y el resultado es más interesante que el titular.

En junio de 2026, Apple añadió un tope de envíos y un **periodo de espera de 30 días** en su portal de investigación de seguridad; a partir de ahí hace falta una solicitud especial. El número exacto del tope no es público. Bynario, que había presentado **13 informes en todo 2025 y principios de 2026**, montó un arnés de IA y envió **más de 50 informes de macOS en tres semanas**. Hizo saltar el tope y se quedó fuera del portal justo cuando tenía un hallazgo crítico en la mano.

Va la parte que casi siempre se omite: el freno no impidió el hallazgo. Apple recibió los detalles por otra vía y parcheó **CVE-2026-43760** el 27 de julio, un fallo de delegado confundido (*confused deputy*) en la ruta heredada de VNC que permitía a un visor autenticado por VNC leer y crear archivos como root. Bynario publicó su análisis dos días después, con el parche ya distribuido. Eso es publicación de investigación posterior al parche, de manual, y no la filtración airada de un 0-day.

Y luego llegó la parte con la que el tope no tenía nada que ver. El análisis de Bynario atrajo la atención de otros investigadores hacia una ruta de código heredada de Compartir pantalla. En 48 horas se divulgó, con prueba de concepto incluida, un fallo distinto **previo a la autenticación** en el mismo demonio. Cuatro días más tarde ya había un exploit funcional y, después, explotación activa para minar criptomonedas contra el puerto 5900 expuesto a internet. Apple parcheó de urgencia el 6 de agosto. CISA lo recalificó de 7,1 a **9,8 el 14 de agosto** y lo añadió al catálogo de vulnerabilidades explotadas conocidas (KEV) el 18 de agosto, con fecha límite de corrección para las agencias federales el 21 de agosto de 2026.

Diez días desde un fallo de privilegios posterior a la autenticación hasta una RCE previa a la autenticación catalogada en el KEV, en el mismo componente.

La moraleja no es que frenar los envíos provoque 0-days; eso es leer en los hechos más de lo que dicen. Es algo más estrecho y más útil: **un tope de envíos gobierna la velocidad a la que los informes entran en tu cola, y no gobierna absolutamente nada de la velocidad a la que se entera el mundo.** En ese calendario, la capacidad de recepción es la única variable que controlas, y el tope no la aumentó lo más mínimo.

## La respuesta de GitHub es mejor: cuatro envíos y una puerta de salida

GitHub chocó con el mismo muro y eligió los niveles en vez del freno. Para los informes presentados a partir del 27 de julio de 2026, mantiene un nivel público de pago fijo de **250 / 2 000 / 5 000 / 10 000 USD**, de severidad baja a crítica, y un nivel VIP solo por invitación de **1 000 / 7 500 / 20 000 / más de 30 000 USD**.

Lo interesante es el mecanismo de entrada. Quien está por debajo del umbral de señal de la plataforma dispone de **hasta cuatro envíos iniciales** para demostrar lo que vale, y la puerta VIP se abre con **un crítico válido**, o dos altos, o cuatro medios, o siete bajos.

Eso es un límite con salida. El arnés de Bynario habría gastado cuatro envíos y, con cualquiera de los críticos que comunicó después, se habría ganado el carril rápido. El tope de Apple no tiene puerta: cuenta envíos, deja de contar y la única forma de pasar es el calendario.

La distinción de diseño merece decirse sin adornos: **un límite de volumen solo se sostiene cuando superarlo depende de acertar y no de esperar 30 días.** El resumen que hizo GitHub de su propia reestructuración es la frase que hay que robar: *«no ganas más por enviar más. Ganas más por enviar mejor.»*

Kit implementa la mitad de esa idea —la de la confianza— y le falta arreglar la otra mitad, la del freno. `Csirt::Researcher#karma_tier` clasifica a los investigadores según el karma acumulado y llega a `trusted` a los 200 puntos, alimentado por valores firmados de `Csirt::KarmaEvent`: `report_validated` +5, `bounty_awarded` +10, frente a `spam_dismissed` -10, `ai_slop_confirmed` -15 y `policy_violation` -25. El karma es por cuenta a propósito, para que el criterio de un programa no persiga al investigador por todo internet.

Aun así, los valores por defecto de Kit también habrían dejado fuera a alguien como Bynario. `SpamConfig` bloquea a partir de 5 informes en 300 segundos, y el limitador de peticiones restringe los envíos del CSIRT a **10 por hora y por IP**. Un remitente con cuarenta hallazgos verificados choca con los dos. Ese es el modo de fallo de Apple instalado en nuestros propios valores por defecto, y la solución no es un número más grande. Es contar **lotes** en lugar de peticiones, y dejar que `karma_tier` suba el techo a quien se lo ha ganado.

## Triaje con la reproducción por delante: cinco campos que tu política debe exigir

Ross McKerchar, CISO de Sophos, y Ryan Westman lo formulan con precisión: los programas necesitan *«PoC claras, registros, trazas, versiones afectadas y pasos reproducibles. Si algo no se puede reproducir, no tiene cabida en el proceso.»*

Conviértelo en campos obligatorios del formulario, no en prosa de política. Exige:

1. **Una prueba de concepto que funcione.** Un script, una petición o una traza. Describir un exploit con palabras no es un exploit.
2. **Las versiones afectadas, exactas.** Un SHA de commit o una etiqueta de versión. Nunca «la última».
3. **Pasos de reproducción que pueda ejecutar un desconocido**, desde un estado limpio hasta el impacto observado.
4. **¿Generó un modelo alguna parte de este hallazgo?** Sí o no, y con qué sistema. No para penalizar: para encaminar.
5. **¿Ha verificado una persona este hallazgo de principio a fin?** Sí o no, y quién.

El campo 5 es el que hace el trabajo de verdad. Es lo que separa el caso de Bynario —resultados de la IA verificados por una persona, que acabaron en un crítico— de la basura generada por IA. Hoy casi nadie lo pregunta, y cuesta dos booleanos y un campo de texto.

En el momento en que aceptes campañas, añade dos más: **identificador de lote o nombre de campaña** y **fecha de divulgación solicitada**, para que quien informa deje su reloj escrito dentro de tu registro y no en su blog.

<div class="blog-inline-cta">
  <p><strong>¿Gestionas un VDP con un registro de verdad?</strong> El módulo CSIRT de Kit trae recepción estructurada, cribado de origen por IA, detección de duplicados, niveles de SLA por severidad y un security.txt generado.</p>
  <p><a href="/users/sign_up">Empieza tu prueba gratuita</a></p>
</div>

## El reloj del regulador empieza el 11 de septiembre de 2026

Si vendes productos conectados en la UE, un solo informe entrante puede arrancar un plazo legal que no tiene nada que ver con tu cola. Desde el **11 de septiembre de 2026**, el Reglamento de Ciberresiliencia (CRA) exige una alerta temprana en **24 horas**, una notificación completa en **72 horas** y un informe final de vulnerabilidad en **14 días** desde la medida correctora, presentados a tu CSIRT nacional a través de la plataforma única de notificación del CRA y compartidos a la vez con ENISA.

Ese reloj arranca cuando sabes que hay explotación activa. Le da igual que el informe llegara como el número 23 de 40, que nadie lo hubiera leído o que lo escribiera un modelo. Un lote sin abrir durante cuatro días es una exposición legal, no solo trabajo pendiente. Nuestra [guía del Reglamento de Ciberresiliencia de la UE](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure) cubre la obligación al completo.

## Sin recepción, el registro de quien informa es tu canal de divulgación

Si alguien no encuentra la manera de contactar contigo, no deja de notificar: publica.

`security.txt` es el arreglo más barato que existe en seguridad y el menos adoptado. Un estudio de 2025 sobre el millón de dominios más visitados encontró un **1,25 % (12 510 sitios)** que publica uno, frente al 0,7 % de abril de 2024, y solo un **44 % de ellos** cumple la RFC 9116. Alrededor del 99 % de la web no tiene contacto de seguridad legible por máquina, y más de la mitad de las excepciones lo tienen mal formado.

Kit genera un archivo conforme a partir de `Csirt::SecurityTxtConfig`, con `Contact`, `Policy`, `Acknowledgments`, `Encryption` y un `Expires` renovable a 365 días. Si no tienes programa ninguno, empieza por nuestra [guía para montar un programa de divulgación de vulnerabilidades](/blog/how-to-set-up-vulnerability-disclosure-program) antes de preocuparte por los lotes.

## Cómo gestiona una campaña el CSIRT de Kit y qué le falta todavía

Parte de lo que exige este momento ya está en Kit. Parte no, y el reparto dice más que una lista de funciones.

**Lo que aguanta hoy:**

- **Recepción estructurada, no una caja de texto libre.** `Csirt::Report` exige `title`, `description`, `vulnerability_type` de una lista cerrada y `affected_endpoint`, además de una columna propia `reproduction_steps`. Esa columna admite nulos, algo que la lista de arriba considera un error. Hacerla obligatoria es el cambio de configuración que pide este momento.
- **El cribado de origen por IA como registro con entidad propia.** `Csirt::AiScreening` puntúa todos los informes entrantes y devuelve un `ai_confidence_score` más señales de un enum cerrado (`hallucinated_functions`, `fabricated_cves`, `no_specific_poc`, `vague_reproduction_steps` y alguna más) con una recomendación `pass` / `review` / `flag`. Es la prueba de reproducibilidad de Sophos implementada como columna en lugar de como párrafo.
- **La agrupación por causa raíz ya existe como elemento básico.** Los informes llevan un embedding de 3 072 dimensiones y la detección de duplicados busca el vecino más cercano por coseno dentro de un programa. Cuando cuarenta hallazgos son una sola clase de fallo, ese es el mecanismo que reduce cuarenta tickets a uno.
- **Reputación en lugar de frenos**, vía `karma_tier`.
- **SLA separados para el acuse de recibo y para la resolución.** `Csirt::SlaConfig` viene con una ventana de acuse de recibo de 72 horas y objetivos de resolución por severidad, desde 24 horas en `super_critical` hasta 720 en severidad baja, además de alertas de incumplimiento repetidas y escalado a la guardia para los críticos.

**Lo que falta, dicho como hoja de ruta y no como funciones:**

1. **No hay objeto de campaña.** Cuarenta informes siguen siendo cuarenta filas con cuarenta relojes.
2. **No hay campos de calendario de divulgación.** El ciclo de vida va de `submitted` a `resolved` y `paid`, sin vocabulario para el reloj de quien informa.
3. **No hay marcas declaradas de «lo generó un modelo» ni de «lo verificó una persona».** El cribado deduce el origen de IA a posteriori; nadie se lo pregunta a quien envía.
4. **Valores por defecto de freno que dejarían fuera a un remitente masivo de buena fe**, exactamente como hizo el tope de Apple.

Cualquier otro artículo sobre este registro lo trata como una historia sobre un modelo. Es una historia sobre un buzón. Los hallazgos son casi todos reales, casi todos sin comunicar, y vienen de camino. El cambio que te prepara es pequeño: que tu programa acuse recibo de la **campaña**, la asuma y la cronometre, en lugar de hacerlo informe a informe. Y después, escribe la fecha de quien informa en tu registro antes de que la escriba él en su blog.