Los reportes de vulnerabilidades ya no son algo especial

• En el mantenimiento de software de código abierto, los issues, PR y comentarios generales podían tratarse de forma opcional, pero en el pasado los reportes de vulnerabilidades eran una excepción que requería una respuesta aparte para proteger a los usuarios.
• Esa excepcionalidad ofrecía información escasa y confidencialidad que permitían a los investigadores corregir antes que los atacantes, y los proyectos la compensaban con respuestas rápidas, investigación, compartir el progreso y dar crédito.
• En 2026, tanto los mantenedores como los atacantes pueden ejecutar LLM, por lo que el cuello de botella se desplaza de encontrar posibles problemas a filtrar cuáles son vulnerabilidades reales.
• Los investigadores externos sin una relación de confianza tienen dificultades para aportar mucho en ese filtrado, y la relación señal-ruido entre revisar salidas de LLM y revisar la bandeja de entrada de security@ se vuelve similar.
• El tiempo de los mantenedores debería dedicarse menos a responder reportes en sí y más a la clasificación, las correcciones rápidas y la prevención, además de buscar cómo ejecutar análisis con LLM en CI.

---

Por qué los reportes de vulnerabilidades eran una excepción

• Los mantenedores de código abierto que trabajan en público suelen recibir issues, PR y comentarios como regalos, y pueden aceptarlos, ignorarlos o usar solo una parte según sea necesario.
• Los reportes de vulnerabilidades del pasado eran un caso especial que se apartaba de ese principio.
  • En lugar de divulgar de inmediato, los investigadores de seguridad elegían hacer un reporte privado para dar tiempo al proyecto de corregir primero.
  • La expectativa habitual era que el proyecto confirmara el reporte con rapidez, lo investigara, compartiera el avance con quien lo reportó y finalmente diera crédito por el hallazgo.
• Esa expectativa partía de la idea de que quien reportaba no era alguien exigiendo una corrección de bug o una funcionalidad, sino alguien prestando un servicio al proyecto.
  • El valor central era la información y la confidencialidad que permitían distribuir una corrección antes de que los atacantes publicaran un exploit.
  • Ignorar un reporte de vulnerabilidad se interpretaba como una señal de que no importaba la seguridad de los usuarios.

La premisa que se derrumbó en 2026

• En 2026, la premisa que hacía especiales a los reportes de vulnerabilidades ya es difícil de sostener.
  • Los LLM funcionan casi tan bien como casi cualquier investigador de seguridad, y cualquiera puede ejecutarlos.
  • Los mismos recursos pueden ejecutarlos tanto los mantenedores como los atacantes.
• Lo escaso ya no es la capacidad de encontrar posibles problemas, sino el trabajo de clasificación para determinar cuáles de ellos son vulnerabilidades reales.
• A los investigadores externos sin una relación previa de confianza les resulta difícil contribuir de forma significativa a ese proceso de clasificación.
  • La relación señal-ruido entre revisar salidas de LLM y revisar la bandeja de entrada de security@ es casi la misma.
• La importancia de la confidencialidad, los embargos y la coordinación también disminuye frente a antes.
  • Los atacantes ya no necesitan esperar una divulgación pública completa y pueden preguntarle a su propio LLM por vulnerabilidades.
  • Aun así, es probable que los atacantes también enfrenten el mismo cuello de botella de clasificación que los defensores.

Cambio de prioridades para los mantenedores

• Puede que la época en que los reportes de vulnerabilidades eran algo especial haya terminado.
• Ahora lo más importante es la clasificación, las correcciones rápidas y la prevención.
• Hay que encontrar formas de ejecutar análisis con LLM en CI.
• Esta postura no es la posición oficial del equipo de seguridad de Go, sino la opinión personal de quien fue líder de ese equipo.
• Cuando el manejo de reportes de vulnerabilidades entra en conflicto con la aplicación del Code of Conduct, no hay una respuesta correcta.
  • Hay que juzgar según la gravedad de la conducta, si es un asunto privado o algo que afecta a la comunidad, y los recursos del equipo que atiende security@.
• Las prácticas de divulgación pública tienen una historia compleja.
  • En el pasado hubo investigadores de buena fe que enfrentaron amenazas legales o procesos penales.
  • En la realidad del código abierto de 2026, no hay investigadores que teman ser procesados por reportar vulnerabilidades, y los proyectos tampoco deberían insinuar procesos penales como alternativa a una política de reporte documentada.
• La suspensión durante un mes del canal de reportes de vulnerabilidades de curl al principio pareció excesiva, pero ya no está claro que responder a reportes de vulnerabilidades sea el mejor uso del tiempo para proteger a los usuarios.

[GN⁺]

Comentarios en Lobste.rs

• La divulgación apresurada de vulnerabilidades sigue ayudando mucho más a los atacantes que a los defensores. Por experiencia propia, incluso usando modelos de frontera, la tasa de falsos positivos a veces se acerca al 90%
  Además, veo la frase “el mantenimiento y desarrollo sostenibles de protocolos criptográficos de código abierto son importantes para la adopción amplia de la tecnología blockchain”, y me sorprende que todavía haya gente que crea en la tecnología blockchain

  • Me confundía por qué estaba esa frase ahí, pero resultó que era un mensaje enviado por uno de los patrocinadores de Fillippo
    A estas alturas, quizá lo más valioso que la tecnología blockchain ha aportado al mundo sea haber creado un fuerte incentivo económico para construir implementaciones de protocolos criptográficos realmente seguras. Parte de eso podría terminar siendo útil para todos los demás
  • Me pregunto qué significa aquí falso positivo. ¿Que el modelo afirmó haber encontrado una vulnerabilidad, pero al verificarlo resultó no ser un problema?
    A estas alturas pensaba que encontrar vulnerabilidades y, en general, entender código ya estaba bastante establecido como algo en lo que los LLM son buenos, pero me da curiosidad si realmente es así. Estaría bien que explicaras un poco más lo que has visto de primera mano o compartieras algún material de referencia. No uso LLM, así que me cuesta tener una idea de cómo están hoy y sinceramente me pregunto si debería cambiar mis supuestos

• Los reportes de vulnerabilidades especiales deberían tratarse como especiales, y del lado de los defensores deberían establecerse mejores formas de validación y modelos de amenaza públicos. Así la gente podría cumplir y verificar un estándar más alto para que un reporte sea reconocido como excelente

  • Puede que al final se resuma así. En general, los reportes de vulnerabilidades no son especiales, pero algunos de alta severidad o alta confiabilidad sí deberían considerarse reportes especiales de vulnerabilidades

• Estoy de acuerdo en que ahora es más fácil encontrar problemas de seguridad y que la barrera de entrada bajó, así que probablemente hay más ruido que antes en las listas de correo de seguridad. Aun así, seguiría priorizando claramente los reportes de bugs de consultoras de seguridad con buena reputación como Trail of Bits o Zellic
  No solo porque confíe en que no van a enviar reportes flojos, sino porque considero que la combinación de investigadores de seguridad de primer nivel y LLM es mejor que simplemente correr un LLM en CI

  • He trabajado recientemente con proveedores así, y los reportes flojos siguen llegando. La calidad de los informes es más alta, eso sí
    Los LLM pueden malinterpretar el modelo de amenaza sin importar quién los use, y pueden ser perezosos al demostrar un “exploit”. Si el investigador de seguridad pasa por alto esos errores, terminan llegando a nosotros, los mantenedores. En containerd hemos recibido reportes flojos de este tipo de proveedores, de empresas de investigación con LLM, de compañías conocidas de modelos base, e incluso de J Random User en internet
    Otra dificultad que Filippo no menciona lo suficiente aquí es la de los reportes duplicados. Si miras los advisories recientes de containerd, puedes ver que otro problema importante en el triage y en cómo se reparte la atención son los duplicados. Por ejemplo, se dio crédito a 9 investigadores/grupos distintos, incluidos grupos reputados como los que mencioné antes. Esto muestra (a) que los LLM, sin importar quién los use, encuentran muchos de los mismos problemas, y (b) que un reporte de un informante conocido no necesariamente es especial. En cambio, este de hecho no tuvo reportes duplicados, así que solo se dio crédito a una persona, y no era alguien que conociéramos de antemano ni con quien tuviéramos relación