Mon, 13 Apr 2026
← VoltarAs inconsistências nos dados de vulnerabilidade surgem do mau design do sistema e da falta de padrões partilhados. O MVVE propõe uma abordagem flexível para alinhar as descrições de vulnerabilidades.
Nesta entrevista da Help Net Security, Art Manion, vice-diretor da Tharros, examina por que os dados de vulnerabilidade nos repositórios permanecem inconsistentes e difíceis de confiar. O problema começa com sistemas que não foram concebidos para recolher ou gerir bem esses dados. Eles introduzem a ideia de Enumeração de Vulnerabilidade Mínima Viável (MVVE), um conjunto mínimo de afirmações necessárias para confirmar que dois sistemas descrevem a mesma vulnerabilidade e descobrir que não existe um mínimo verdadeiro. As afirmações variam de acordo com o caso e mudam com o tempo.
Eles argumentam que antes de escrever novas especificações ou construir novas ferramentas, a comunidade precisa de termos e princípios partilhados. Métricas como as pontuações do CVSS muitas vezes desviam a atenção do trabalho mais árduo de avaliar o risco real no contexto. Quando dois repositórios discordam sobre se um patch corrige uma vulnerabilidade, isso é um problema de qualidade de dados, um problema de governança ou um problema de definição? E a distinção importa na forma como a corrigimos?
Provavelmente estes são os três problemas, em alguma combinação e com algum grau de sobreposição. O conjunto de produtos e versões de software vulneráveis e corrigidos pode ser impreciso ou incompleto. A governação pode não detectar e resolver adequadamente tais imprecisões. As definições, o vocabulário e a gramática não são suficientemente estritos nem partilhados de forma suficientemente ampla.
Um dos princípios que propomos é que a qualidade do registro de vulnerabilidade é um problema de arquitetura antes de ser um problema de dados. Não devemos esperar dados de alta qualidade de um sistema que não foi concebido para os recolher, gerir e transmitir. Os produtores e consumidores de informações sobre vulnerabilidade possuem uma variedade de habilidades, experiências e conhecimentos. Talvez mais importante ainda, tanto os produtores como os consumidores têm acesso desigual à informação, e tanto a informação como o acesso à mesma mudam ao longo do tempo.
Outro princípio é que os registros de vulnerabilidade devem ser gerenciados ao longo do tempo. O sistema deve se adaptar e até incentivar a mudança para que se adapte e evolua com o nosso entendimento. Devemos aceitar que a informação incompleta e o desacordo legítimo são características permanentes do panorama e gerir os registos em conformidade. Qual é o conjunto mínimo de afirmações que permitiria a dois sistemas independentes confirmar que estão falando sobre a mesma vulnerabilidade, sem que nenhum dos sistemas tenha que confiar na autoridade do outro?
Decidimos definir esse conjunto mínimo (MVVE) e descobrimos que provavelmente não existe tal mínimo. Existem elementos partilhados, como a especificação de um produto (software) afetado e a identificação das condições sob as quais a exploração seria bem-sucedida e uma ou mais propriedades de segurança comprometidas. Além disso, o número e o tipo de afirmações necessárias para desduplicar e eliminar a ambiguidade de uma vulnerabilidade variam. Esperamos um conjunto variável de asserções, ao longo do tempo, dentro e entre repositórios.
Mas classificar listas e tipos de afirmações é secundário. À medida que pesquisamos os problemas com dados de vulnerabilidade, descobrimos que primeiro precisamos de uma base melhor de termos e conceitos compartilhados, para então podermos construir convenções para afirmações adequadas. Se você eliminar as pontuações de gravidade, o texto consultivo, as atribuições do CWE e as listas de produtos afetados, o que resta? O que resta é suficiente para ancorar a desduplicação entre repositórios ou eliminá-la expõe um vazio?
Não há dúvida de que os nossos formatos de gravação existentes têm oportunidades de melhoria. Não começamos com “O que temos?” mas em vez disso perguntou “O que precisamos?” Isso levou a “Quais tarefas e decisões de gerenciamento de vulnerabilidades são suportadas pelos registros de vulnerabilidade?” Uma das tarefas iniciais mais críticas é a identificação dos produtos de software afetados. Uma pesquisa recente mostrou que “foram identificadas inconsistências de nomenclatura em 50,18% dos nomes de fornecedores usados em CPEs no banco de dados oficial do NVD”. Se não conseguirmos identificar com precisão os produtos afetados, o resto não importa.
(CPE não é o único neste modo de falha, outros sistemas de identificação de software sofrem de forma semelhante). Um desafio em medir a qualidade de tão Algo parecido com uma afirmação CPE é que ela pode parecer perfeitamente razoável para um ser humano, mas não consegue identificar adequadamente o software, especialmente em termos de automação e usabilidade da máquina. Saber a diferença entre identificadores e produtos de software requer um esforço manual significativo. A redução ou mesmo a eliminação desse esforço manual começa na arquitetura e no design do sistema de identificação e nas suas afirmações.
Depois de projetarmos para capturar o nível certo de detalhe, precisamos nos concentrar em nossa capacidade de confiar nas informações. Outro princípio que discutiremos: “Cada afirmação em um registro deve ser capaz de responder por si mesma”. Portanto, quando registramos afirmações, elas precisam ser simples, precisas, observáveis, úteis e incluir a proveniência. O novo registro de vulnerabilidade é uma coleção de afirmações, crescendo (e mudando) ao longo do tempo, vinculadas a um identificador de vulnerabilidade e utilizáveis por máquina.
Essas afirmações descrevem a vulnerabilidade, permitindo a identificação, a desduplicação e o gerenciamento de vulnerabilidades e precisam ser verificáveis e refutáveis de forma independente. Os incentivos baseados em métricas, sejam eles o tempo de resposta, as contagens de cobertura ou o rendimento do CVSS, têm um efeito distorcido na qualidade dos registos. Que distorções específicas você observa com mais frequência e alguma delas é invisível para as pessoas que as produzem? Quantidade não é qualidade.
Não quer dizer que a cobertura e as contagens não sejam úteis, mas, por exemplo, ter uma pontuação base CVSS ou um ID CWE num registo de vulnerabilidade não significa que as informações sejam exatas, precisas ou mesmo úteis. Há uma tendência de focar nas coisas que você está medindo, simplesmente porque você as está medindo. As próprias medições podem se tornar o objetivo. Considere o CVSS.
Os repositórios de vulnerabilidades normalmente fornecem pontuações e vetores CVSS Base, que se destinam a transmitir a severidade técnica aproximada. Não há nada superficialmente errado com isso. Os repositórios não podem fornecer facilmente aos consumidores as informações locais e dependentes do contexto necessárias para avaliar o risco. Os consumidores precisam de fornecer este contexto, que é provavelmente mais importante do que a severidade técnica imediata.
Mas a atenção dispensada a pontuações relativamente baratas do CVSS Base (“cuidado, 9,8!”) desvia a atenção do trabalho de determinação do contexto e de avaliação do risco de forma mais holística. Contar registros de vulnerabilidade com pontuações CVSS ou medir distribuições de pontuações CVSS Base é possível, mas isso ajuda? Diferentes jogos de linguagem, definições e métricas excessivamente abstratas também levam à distorção. Como dois analistas diferentes, mas com qualificações semelhantes, que analisam as mesmas informações de vulnerabilidade, podem criar IDs CWE ou vetores de complexidade de ataque CVSS diferentes?
Muitas das afirmações comuns que usamos hoje falham nos testes de atomicidade e observabilidade. Desentendimentos ocorrem naturalmente e as métricas baseadas nessas afirmações serão distorcidas. A comunidade de segurança tem um longo histórico de produção de especificações elegantes que são adotadas seletivamente e implementadas de forma inconsistente. O que há de diferente nesta proposta que impediria esse resultado?
Não podemos garantir o resultado, mas o estado atual da prática é insustentável. Não estamos prestes a esboçar uma nova especificação, elegante ou não. Um novo formato, especificação ou um punhado de campos não resolverão os problemas fundamentais e filosóficos que enfrentamos. A premissa do nosso trabalho é que primeiro precisamos desenvolver um conjunto de princípios e requisitos para projetar e construir melhores repositórios de vulnerabilidades.
Talvez então seja hora de escrever uma especificação, construir um novo repositório ou fazer alterações nos repositórios existentes. Mas primeiro precisamos de uma base sólida. Download: Pesquisa de Ameaças e Defesas de Identidade SANS 2026