O melhor da VulnCon 2026

O que é a VulnCon?

A VulnCon é um evento anual coorganizado pela FIRST e pelo programa CVE. Sua primeira edição ocorreu em março de 2024 e foi criada como um espaço para reunir os diversos atores envolvidos no ecossistema global de vulnerabilidades: desde CNAs (CVE Numbering Authorities) e PSIRTs (Product Security Incident Response Teams) até fornecedores, pesquisadores e consumidores dessas informações.

A VulnCon concentra-se em discutir como as vulnerabilidades são identificadas, documentadas, priorizadas, compartilhadas e consumidas na indústria. Em outras palavras, ela não gira apenas em torno dos aspectos técnicos de encontrar vulnerabilidades, mas também de todos os processos e padrões que tornam essas informações úteis para a comunidade.

Para a Fluid Attacks, participar dessas conferências é muito importante, pois somos uma CNA — fomos aceitos em 2 de junho de 2021 (fomos a primeira CNA da América Latina; no momento em que este artigo foi escrito, já somos três). Temos mais de 160 CVEs públicos e mais de 15 em andamento, todos encontrados ou coordenados por nós. Desses, 13% são de severidade crítica, 43% de severidade alta e 44% de severidade média; precisamos publicá-los e mantê-los adequadamente. Por esse motivo, queremos entender o que outras CNAs estão fazendo, quais problemas enfrentam e como podemos otimizar nossos processos.

Introdução à VulnCon 2026

A VulnCon26 ocorreu de 13 a 16 de abril no DoubleTree Resort by Hilton Hotel Paradise Valley, em Scottsdale, Arizona, nos EUA. Na segunda-feira, 13 de abril, foram realizados os workshops pré-conferência, seguidos de três dias de palestras envolventes sobre gestão de vulnerabilidades e tendências emergentes. Este ano, houve cerca de 130 participantes presenciais e 100 remotos de diferentes organizações da área de gestão de vulnerabilidades.

Scottsdale, AZ (imagem retirada de afar.com)

Os principais temas deste ano concentraram-se em como a inteligência artificial está afetando o ecossistema de vulnerabilidades, tanto de forma positiva quanto negativa. Isso incluiu palestras sobre automação, pipelines para todo o processo de divulgação responsável, como a IA aumentou tanto o número de relatos quanto o ruído em torno deles, bem como ideias iniciais sobre como o software criado por IA deve ser identificado, usando, por exemplo, PURL e tratando modelos e conjuntos de dados como bibliotecas e arquivos de configuração, e como atribuir vulnerabilidades ao software de IA. Também houve discussões sobre padrões e estruturas, como VEX e CSAF, para a gestão de vulnerabilidades. Por último, mas não menos importante, algumas palestras apresentaram pesquisas com críticas construtivas ao ecossistema CVE para entender o que está errado e como ele poderia ser melhorado.

Antes das palestras

No primeiro dia do evento, embora não houvesse palestras, vários workshops abertos estavam disponíveis aos participantes. Assim, depois de fazer o check-in e receber os brindes do evento — uma camiseta, um caderno, adesivos e uma sacola de pano —, examinei os workshops dos quais queria participar. A decisão não demorou, pois havia um workshop chamado "Coordinated Vulnerability Disclosure (CVD) Table Top Exercise", que eu acreditava poder ser muito útil para a Fluid Attacks.

Esse workshop acabou sendo especialmente interessante porque apresentou, de forma muito prática, como a divulgação coordenada de vulnerabilidades ocorre sob a perspectiva dos diferentes atores envolvidos: usuários, coordenadores, divulgadores e fornecedores. Uma das ideias mais valiosas foi entender que o papel do coordenador não se limita a servir de ponte entre as partes. Muitas vezes, ele também envolve solicitar evidências adicionais, facilitar a comunicação entre o divulgador e o fornecedor e até apoiar o fabricante em sua resposta pública.

Durante a sessão, também foram discutidos cenários complexos, como casos em que o fornecedor não confirma a vulnerabilidade, casos em que já existem sinais de exploração em ambiente real (in the wild) ou casos em que surge a questão de saber se uma vulnerabilidade pode ser tornada pública sem o consentimento do fornecedor. Também achei interessante ver como algumas CNAs já têm pipelines internos e ferramentas para gerenciar todo o fluxo de divulgação de vulnerabilidades, do relatório inicial à publicação, e como usam ferramentas como Vulnogram para automatizar partes do processo, como a geração de CPEs. No geral, o workshop deixou uma ideia clara: na divulgação, não existe uma única maneira correta de fazer as coisas, mas muitas decisões sobre coordenação, tempo e comunicação acabam por definir a qualidade da resposta.

Algumas palestras

Este ano, foram realizados seis workshops e cerca de 60 palestras e reuniões de grupos de trabalho ministradas por 81 palestrantes de diferentes nacionalidades. Todas essas conferências foram distribuídas ao longo de três dias. Houve palestras com duração de meia hora ou uma hora, e sempre havia três ou mais acontecendo simultaneamente, então os participantes precisavam escolher a quais assistir. Em qualquer caso, a maioria das palestras foi gravada, e você pode encontrá-las no YouTube após 31 de maio.

A seguir, descrevo brevemente as palestras que considerei mais relevantes e minhas favoritas.

CISA-ENISA Joint Messaging

Esta imagem e as outras relacionadas às palestras foram retiradas de first.org

Esta foi a palestra de abertura do evento, apresentada por Lindsey Cerkovnik e Nuno Rodrigues Carvalho. Ela mostrou como agências como a CISA, nos Estados Unidos, e a ENISA, na Europa, estão atualmente apoiando o ecossistema de CVEs.

Por um lado, a CISA continua sendo um dos principais motores do programa: patrocina o programa, participa de sua evolução e também contribui com capacidades operacionais por meio de iniciativas de gestão de vulnerabilidades, coordenação de divulgação e catálogos como o KEV, que ajudam a priorizar vulnerabilidades exploradas ativamente.

Por outro lado, a ENISA vem fortalecendo seu papel no ambiente europeu ao promover políticas de Coordinated Vulnerability Disclosure, atuar como CNA em certos casos relatados por CSIRTs europeus e desenvolver a EU Vulnerability Database (EUVD) como uma fonte curada de informações acionáveis.

Nesse sentido, o esforço conjunto entre ambas as regiões não se limita a "apoiar" o programa CVE de forma abstrata; ele também fortalece a coordenação, melhora a qualidade das informações sobre vulnerabilidades e cria mecanismos mais úteis para fornecedores, coordenadores e usuários finais.

A Paradigm Shift in Vulnerability Identity: Why Vulnerability Databases Struggle

Nesta palestra, Art Manion e Jay Jacobs ofereceram críticas construtivas sobre como o ecossistema de registro de vulnerabilidades funciona e por que acreditam que ele está quebrado — isto é, por que é difícil definir e nomear software e chegar a acordos. Eles também recorreram a ideias filosóficas para justificar, em certa medida, os princípios que orientariam a reforma de todo o sistema.

Desde o início, deixaram claro que isso não era uma estrutura nem uma crítica aos criadores, mas sim um conjunto de novos princípios a partir dos quais tudo o mais poderia ser construído. Isso porque perceberam que o problema de qualidade nos bancos de dados tem menos a ver com os dados em si e mais com a arquitetura e os princípios que os regem.

Especificamente, os palestrantes apontaram que os bancos de dados de vulnerabilidades sofrem de várias complicações subjacentes: primeiro, conceitos centrais como "vulnerabilidade" nem sempre são definidos com precisão suficiente; segundo, nomes e identificadores nem sempre representam de forma consistente o objeto real ao qual se referem; e, terceiro, os registros muitas vezes são tratados como entradas estáticas, quando na realidade deveriam ser entendidos como artefatos vivos que precisam ser atualizados e enriquecidos ao longo do tempo.

CVD and CVE for Researchers: Meet the Researcher Working Group

Isso foi mais uma apresentação do CNA Researcher Working Group (RWG) do que uma palestra. Nesse contexto, vários grupos buscam reunir CNAs em torno de temas e escopos comuns. Durante esta sessão, foi mencionado um protocolo chamado CVE-DIBS. Ele consiste em um mecanismo para coordenar qual CNA assume um caso urgente envolvendo uma vulnerabilidade que já foi divulgada publicamente, com o objetivo de atribuir rapidamente um CVE e evitar duplicatas ou conflitos entre CNAs.

Também foram compartilhadas informações sobre como cada CNA opera dentro do seu próprio escopo. A VulnCheck, por exemplo, concentra-se em atribuir CVEs a vulnerabilidades públicas que ainda não têm identificador, a casos relatados por terceiros e às suas próprias descobertas, mesmo em cenários incomuns ou atípicos. A HeroDevs concentra seu trabalho em vulnerabilidades que afetam software EOL, falhas que sua equipe encontra nas bibliotecas que utiliza e relatos recebidos por meio de programas de bug bounty.

A GitHub, por sua vez, atribui CVEs principalmente a vulnerabilidades em projetos hospedados em sua plataforma quando o mantenedor solicita um, bem como a casos descobertos por sua equipe de pesquisa ou enviados por pesquisadores já familiarizados com o processo. Por fim, a Trend Micro ZDI atribui CVEs a vulnerabilidades descobertas, adquiridas ou investigadas pela Zero Day Initiative, contando com sua equipe interna de pesquisa e infraestrutura de fuzzing. Em muitos casos, ela identifica a vulnerabilidade antes do fornecedor, fornece a ele um relatório de alta qualidade que inclui uma prova de conceito e, então, atribui o CVE.

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

Nesta palestra, Karel Knibbe e Ruben Bos, da Volerion, mostraram que, às vezes, quando as pessoas tentam atribuir uma única pontuação CVSS que leve em conta múltiplas possibilidades, acabam misturando métricas de cenários distintos e produzindo uma pontuação que, na verdade, não representa nenhum deles. Como alternativa, eles propuseram um método chamado Multi-Scenario Attack Graphs, que usa grafos de ataque nos quais todas as métricas e impactos são representados como perguntas. Cada caminho representa um cenário de ataque com sua própria pontuação e, por fim, seleciona-se a mais alta.

AI Systems Are Software Systems

Nesta palestra interessante, Jonathan Spring, da CISA, discutiu como os sistemas de IA são sistemas de software e, portanto, as regras aplicadas aos CVEs também deveriam se aplicar a eles. Muitas regras existentes para CNAs se aplicariam aos sistemas de IA, mas outras precisariam ser modificadas, e algumas novas também teriam de ser criadas. Spring também mencionou como poderíamos identificar produtos e como modelos e conjuntos de dados funcionam como bibliotecas e arquivos de configuração. No final, ele convidou aqueles de nós que trabalham com cibersegurança a educar os engenheiros de IA e ajudá-los a entender por que a segurança é importante e quais seriam as consequências se ela não fosse levada em consideração.

Conclusões

A VulnCon26 confirmou que o ecossistema de vulnerabilidades está passando por um período significativo de mudanças. Entre novas discussões sobre inteligência artificial, problemas identificados em seu estado atual e propostas para melhorar processos e padrões, a conferência mostrou que o futuro dependerá tanto da inovação técnica quanto da capacidade de todos os atores de colaborar. Nesse sentido, a VulnCon parece ser um espaço cada vez mais relevante para entender para onde a indústria está caminhando.

Depois de participar deste evento, uma das perguntas mais naturais é: eu voltaria? A resposta curta é sim. Além de ser uma conferência de nicho, é um dos poucos espaços onde os problemas reais do ecossistema de vulnerabilidades são discutidos em profundidade: desde como as vulnerabilidades são definidas e documentadas até como são coordenadas e utilizadas em larga escala por pesquisadores, clientes e usuários. Esse nível de especialização, combinado com a qualidade das conversas, torna este evento altamente valioso para aqueles de nós que trabalham com gestão de vulnerabilidades.

Da mesma forma, ao comparar a VulnCon 2026 com o que estamos fazendo atualmente na Fluid Attacks, fica claro que, como organização, deveríamos voltar. Não apenas porque somos uma CNA e o evento é altamente relevante para o nosso trabalho, mas também porque já estamos construindo exatamente o tipo de coisa que foi discutida lá. Por exemplo, estamos atualmente identificando vulnerabilidades em projetos de código aberto usando IA, publicando avisos reais com CVEs derivados desse processo e explorando modelos para priorizar projetos com base em seu impacto no ecossistema.

Nesse sentido, acredito que não apenas teríamos material para apresentar, mas também uma oportunidade clara de agregar valor ao ecossistema. Temas como o uso de IA para identificar vulnerabilidades em software de código aberto, estratégias para reduzir falsos positivos e validar descobertas, priorização com base no impacto real, além da severidade, e a evolução desse processo até a atribuição de CVE são linhas de trabalho que poderíamos desenvolver em artigos, publicações e até em futuras apresentações. Em definitivo, fica claro que a VulnCon é um evento no qual todos nós que estamos construindo o futuro da gestão de vulnerabilidades deveríamos compartilhar como estamos fazendo isso.