Lo mejor de VulnCon 2026

¿Qué es VulnCon?

VulnCon es un evento anual coorganizado por FIRST y el programa CVE. Su primera edición tuvo lugar en marzo de 2024 y nació como un espacio para reunir a los diversos actores involucrados en el ecosistema global de vulnerabilidades: desde las CNA (CVE Numbering Authorities) y las PSIRT (Product Security Incident Response Teams) hasta proveedores, investigadores y consumidores de esta información.

VulnCon se centra en discutir cómo se identifican, documentan, priorizan, comparten y consumen las vulnerabilidades en la industria. En otras palabras, no gira únicamente en torno a los aspectos técnicos de los hallazgos, sino también a todos los procesos y estándares que hacen que esta información sea útil para la comunidad.

Para Fluid Attacks, asistir a estas conferencias es muy importante porque somos una CNA — fuimos aceptados el 2 de junio de 2021 (fuimos la primera CNA de América Latina; al momento de escribir este artículo, ya somos tres). Tenemos más de 160 CVE públicos y más de 15 en progreso, todos encontrados o coordinados por nosotros. De estos, el 13% son de severidad crítica, el 43% de severidad alta y el 44% de severidad media, los cuales debemos publicar y mantener correctamente. Por esta razón, queremos entender qué están haciendo otras CNAs, qué problemas enfrentan y cómo podemos optimizar nuestros procesos.

Introducción a VulnCon 2026

VulnCon26 tuvo lugar del 13 al 16 de abril en el DoubleTree Resort by Hilton Hotel Paradise Valley, en Scottsdale, Arizona, EE. UU. El lunes 13 de abril se realizaron los workshops previos a la conferencia, seguidos de tres días de charlas interesantes sobre gestión de vulnerabilidades y tendencias emergentes. Este año, hubo alrededor de 130 asistentes presenciales y 100 asistentes remotos de distintas organizaciones del ámbito de la gestión de vulnerabilidades.

Scottsdale, AZ (imagen tomada de afar.com)

Los principales temas de este año se centraron en cómo la inteligencia artificial está afectando al ecosistema de vulnerabilidades, tanto positiva como negativamente. Esto incluyó charlas sobre automatización, pipelines para todo el proceso de divulgación responsable, cómo la IA ha aumentado tanto el número de reportes como el ruido en torno a ellos, así como ideas tempranas sobre cómo debería identificarse el software construido con IA, por ejemplo, usando PURL y tratando los modelos y conjuntos de datos como librerías y archivos de configuración, y sobre cómo asignar vulnerabilidades al software de IA. También hubo discusiones sobre estándares y marcos, como VEX y CSAF, para la gestión de vulnerabilidades. Por último, algunas charlas presentaron investigaciones con críticas constructivas sobre el ecosistema CVE para entender qué está mal y cómo podría mejorarse.

Antes de las charlas

El primer día del evento, aunque no hubo charlas, se ofrecieron varios workshops abiertos a los asistentes. Así pues, después de registrarme y recibir el material del evento —una camiseta, una libreta, stickers y una bolsa de tela—, revisé los talleres a los que quería asistir. La decisión no tomó mucho tiempo, ya que había un workshop llamado "Coordinated Vulnerability Disclosure (CVD) Table Top Exercise", el cual creí que podría ser muy útil para Fluid Attacks.

Este workshop resultó especialmente interesante porque presentó, de manera muy práctica, cómo se desarrolla la divulgación coordinada de vulnerabilidades desde la perspectiva de los distintos actores involucrados: usuarios, coordinadores, divulgadores y proveedores. Una de las ideas más valiosas fue entender que el rol del coordinador no se limita a servir de puente entre las partes. A menudo, también implica solicitar evidencia adicional, facilitar la comunicación entre el divulgador y el proveedor, e incluso apoyar al fabricante en su respuesta pública.

Durante la sesión, también se discutieron escenarios complejos, como los casos en los que el proveedor no confirma la vulnerabilidad, los casos en los que ya hay señales de explotación en la práctica (in the wild) o los casos en los que surge la pregunta de si una vulnerabilidad puede hacerse pública sin el consentimiento del proveedor. Además, me pareció interesante ver cómo algunas CNAs ya cuentan con pipelines y desarrollos internos para gestionar todo el flujo de divulgación de vulnerabilidades, desde el informe inicial hasta la publicación, y cómo usan herramientas como Vulnogram para automatizar partes del proceso, como la generación de CPEs. En general, el taller dejó una idea clara: en la divulgación, no existe una única forma correcta de hacer las cosas, sino muchas decisiones sobre coordinación, tiempos y comunicación que, en última instancia, definen la calidad de la respuesta.

Algunas charlas

Este año hubo seis workshops y alrededor de 60 charlas y reuniones de grupos de trabajo impartidas por 81 ponentes de distintas nacionalidades. Todas estas conferencias se distribuyeron a lo largo de tres días. Hubo charlas de media hora o de una hora, y siempre había tres o más desarrollándose simultáneamente, por lo que los asistentes tuvieron que elegir a cuáles asistir. En cualquier caso, la mayoría de las charlas se grabaron y estarán disponibles en YouTube después del 31 de mayo.

A continuación, describo brevemente las charlas que me parecieron más relevantes y que fueron mis favoritas.

CISA-ENISA Joint Messaging

Esta imagen y las demás relacionadas con las charlas fueron tomadas de first.org

Esta fue la charla de bienvenida del evento, impartida por Lindsey Cerkovnik y Nuno Rodrigues Carvalho. Mostró cómo organismos como CISA en Estados Unidos y ENISA en Europa están apoyando actualmente el ecosistema de CVEs.

Por un lado, CISA sigue siendo uno de los principales impulsores del programa: lo patrocina, participa en su evolución y también aporta capacidades operativas mediante iniciativas de gestión de vulnerabilidades, coordinación de divulgación y catálogos como KEV, que ayudan a priorizar las vulnerabilidades que están siendo explotadas activamente.

Por otro lado, ENISA ha venido fortaleciendo su papel en el entorno europeo al promover políticas de Coordinated Vulnerability Disclosure, actuar como CNA en ciertos casos notificados por CSIRT europeos y desarrollar la EU Vulnerability Database (EUVD) como una fuente de información curada y accionable.

En ese sentido, el esfuerzo conjunto entre ambas regiones no se limita a "apoyar" el programa CVE en abstracto; también fortalece la coordinación, mejora la calidad de la información sobre vulnerabilidades y crea mecanismos más útiles para proveedores, coordinadores y usuarios finales.

A Paradigm Shift in Vulnerability Identity: Why Vulnerability Databases Struggle

En esta charla, Art Manion y Jay Jacobs ofrecieron una crítica constructiva sobre cómo funciona el ecosistema de registro de vulnerabilidades y por qué creen que está roto, es decir, por qué resulta difícil definir y nombrar el software y llegar a acuerdos. Además, se apoyaron en ideas filosóficas para justificar, en cierta medida, los principios que guiarían la reforma de todo el sistema.

Desde el principio dejaron claro que esto no era un marco ni una crítica a los creadores, sino más bien un conjunto de nuevos principios a partir de los cuales se podría construir todo lo demás. Esto se debía a que habían observado que el problema de calidad en las bases de datos tiene menos que ver con los datos en sí y más con la arquitectura y los principios que las gobiernan.

En concreto, los ponentes señalaron que las bases de datos de vulnerabilidades sufren varias complicaciones subyacentes: primero, conceptos centrales como "vulnerabilidad" no siempre están definidos con suficiente precisión; segundo, los nombres e identificadores no siempre representan de forma coherente el objeto real al que apuntan; y tercero, los registros suelen tratarse como entradas estáticas, cuando en realidad deberían entenderse como artefactos vivos que necesitan actualizarse y enriquecerse con el tiempo.

CVD and CVE for Researchers: Meet the Researcher Working Group

Más que una charla, fue una presentación del CNA Researcher Working Group (RWG). En este contexto, varios grupos buscan reunir a las CNA en torno a temas y alcances comunes. Durante esta sesión se mencionó un protocolo llamado CVE-DIBS, que consiste en un mecanismo para coordinar qué CNA asume un caso urgente que involucra una vulnerabilidad ya divulgada públicamente, con el objetivo de asignarle rápidamente un CVE y evitar duplicados o conflictos entre CNAs.

Asimismo, se compartió información sobre cómo opera cada CNA dentro de su propio alcance. VulnCheck, por ejemplo, se enfoca en asignar CVEs a vulnerabilidades públicas que aún no tienen identificador, a casos reportados por terceros y a sus propios hallazgos, incluso en escenarios poco comunes o atípicos. HeroDevs centra su trabajo en vulnerabilidades que afectan software EOL, fallas que su equipo encuentra en las librerías que utiliza y reportes que recibe a través de programas de bug bounty.

GitHub, por su parte, asigna CVEs principalmente a vulnerabilidades de proyectos alojados en su plataforma cuando el mantenedor lo solicita, así como a casos descubiertos por su equipo de investigación o enviados por investigadores ya familiarizados con ese flujo. Finalmente, Trend Micro ZDI asigna CVEs a vulnerabilidades descubiertas, adquiridas o investigadas por la Zero Day Initiative, apoyándose en su equipo interno de investigación e infraestructura de fuzzing. En muchos casos, identifica la vulnerabilidad antes que el proveedor, le entrega al proveedor un informe de alta calidad que incluye una prueba de concepto y luego asigna el CVE.

Deriving CVSS from Multi-Scenario Attack Graphs: A Reproducible, Auditable Scoring Method

En esta charla, Karel Knibbe y Ruben Bos, de Volerion, mostraron que a veces, cuando las personas intentan asignar una sola puntuación CVSS que tenga en cuenta múltiples posibilidades, terminan mezclando métricas de varios escenarios y producen una puntuación que en realidad no representa ninguno de ellos. Como alternativa, propusieron un método llamado Multi-Scenario Attack Graphs, el cual utiliza grafos de ataque en los que todas las métricas e impactos se representan como preguntas, donde cada ruta representa un escenario de ataque con su propia puntuación y, finalmente, se selecciona la de mayor puntuación.

AI Systems Are Software Systems

En esta interesante charla, Jonathan Spring, de CISA, habló sobre cómo los sistemas de IA son sistemas de software y, por lo tanto, las reglas aplicadas a los CVEs también deberían aplicarse a ellos. Muchas reglas existentes para las CNAs serían aplicables a los sistemas de IA, pero otras deberían modificarse y habría que crear algunas nuevas. Spring también mencionó cómo podríamos identificar los productos y cómo los modelos y los conjuntos de datos funcionan como librerías y archivos de configuración. Al final, invitó a quienes trabajamos en ciberseguridad a educar a los ingenieros de IA y ayudarles a entender por qué la seguridad es importante y cuáles serían las consecuencias si no se tuviera en cuenta.

Conclusiones

VulnCon26 confirmó que el ecosistema de vulnerabilidades está atravesando un período importante de cambio. Entre nuevos debates sobre inteligencia artificial, problemas identificados en su estado actual y propuestas para mejorar procesos y estándares, la conferencia mostró que el futuro dependerá tanto de la innovación técnica como de la capacidad de todos los actores para colaborar. En ese sentido, VulnCon se siente como un espacio cada vez más relevante para entender hacia dónde se dirige la industria.

Después de asistir a este evento, una de las preguntas más naturales es: ¿volvería? La respuesta corta es sí. Más allá de ser una conferencia de nicho, es uno de los pocos espacios donde se abordan en profundidad los problemas reales del ecosistema de vulnerabilidades: desde cómo se definen y documentan las vulnerabilidades hasta cómo se coordinan y se utilizan a gran escala por investigadores, clientes y usuarios. Ese nivel de especialización, combinado con la calidad de las conversaciones, hace que este evento sea muy valioso para quienes trabajamos en la gestión de vulnerabilidades.

Asimismo, al comparar VulnCon 2026 con lo que estamos haciendo actualmente en Fluid Attacks, queda claro que, como organización, deberíamos regresar. No solo porque somos una CNA y el evento es muy relevante para nuestro trabajo, sino también porque ya estamos construyendo exactamente el tipo de cosas que allí se discutieron. Por ejemplo, actualmente estamos descubriendo vulnerabilidades en proyectos de código abierto mediante IA, publicando avisos reales con CVE derivados de ese proceso y explorando modelos para priorizar proyectos según su impacto en el ecosistema.

En ese sentido, creo que no solo tendríamos material para presentar, sino también una clara oportunidad de aportar valor al ecosistema. Temas como el uso de IA para identificar vulnerabilidades en software de código abierto, estrategias para reducir falsos positivos y validar hallazgos, la priorización basada en el impacto real más allá de la severidad y la evolución de ese proceso hasta la asignación de CVEs son líneas de trabajo que podríamos desarrollar en artículos, publicaciones e incluso futuras presentaciones. En definitiva, está claro que VulnCon es un evento en el que todos los que estamos construyendo el futuro de la gestión de vulnerabilidades deberíamos compartir cómo lo estamos haciendo.