NIST analisou 199 dos 3.370 CVEs em março de 2024

Em março de 2024, o National Institute of Standards and Technology dos EUA (NIST) analisou 199 dos 3.370 registros de Common Vulnerabilities and Exposures (CVE) que recebeu. Naquele ano, 413 organizações reportaram mais de 40.000 CVEs. O sistema continuou nomeando falhas de segurança enquanto a base de dados federal criada para explicá-las ficou para trás.

Esses números descrevem funções diferentes. Um identificador permite que um fornecedor, pesquisador, órgão público e operador de software se refiram à mesma falha reportada. A análise precisa estabelecer informações suficientes sobre produtos afetados, gravidade e contexto para ajudar alguém a decidir o que fazer. Um nome pode ser atribuído antes que esse trabalho esteja concluído.

O nome comum ganhou escala porque a identificação foi distribuída

O sistema CVE começou em 1999 para resolver um problema de coordenação: partes distintas precisavam de uma referência comum para uma vulnerabilidade reportada. A MITRE mantém o programa, mas grandes fornecedores e outras organizações participantes podem atribuir identificadores. Essa delegação ajudou o registro a ultrapassar 270.000 entradas sem exigir que a MITRE investigasse cada falha antes que alguém pudesse nomeá-la.

A National Vulnerability Database do NIST foi criada sobre a Lista CVE para fornecer uma referência pública mais rica. Seu trabalho é diferente de emitir um ID. Um operador que tenta encontrar software afetado precisa do contexto de produto e versão; um operador que decide se deve interromper uma implantação precisa saber se a falha está sendo explorada e se o componente vulnerável está presente e acessível. Uma pontuação, por si só, não responde a nenhuma das duas perguntas.

O déficit do NIST não surgiu de um dia para o outro. Em 2025, o instituto buscava contratados para lidar com um acúmulo de mais de 25.000 vulnerabilidades, cerca de dez vezes o recorde anterior reportado para 2017. O NIST atribuiu a baixa contagem de análises de março de 2024 à insuficiência de apoio entre órgãos; uma interrupção de financiamento mais tarde naquele ano contribuiu para o acúmulo que levou à sua mudança posterior de política. Adicionar analistas pode ajudar, mas cada registro ainda exige coordenação entre relatos, definições de produtos, correções e retificações. O identificador pode ser distribuído mais facilmente do que um julgamento confiável sobre seu significado operacional.

A neutralidade da MITRE depende de um caminho funcional para correções

O episódio de financiamento da MITRE em 2025 testou a camada de identificadores sem rompê-la. A MITRE disse que seu financiamento havia expirado; a CISA prorrogou o suporte e afirmou que não haveria interrupção nos serviços críticos de CVE. A prorrogação manteve o registro em funcionamento e tornou visível sua dependência de apoio contínuo.

A continuidade por si só não resolve a questão da confiança. Em 2019, a VideoLAN contestou um problema reportado no VLC, dizendo que ele estava em uma biblioteca de terceiros corrigida mais de 16 meses antes, e alegou que a MITRE não havia verificado a alegação subjacente. A contestação da VideoLAN mostra o que um mantenedor afetado precisa quando uma classificação pública está errada ou desatualizada: uma forma de rastrear a origem, contestar a descrição e fazer uma correção chegar às pessoas que dependem dela.

A MITRE pode manter o nome comum enquanto NIST, CISA, fornecedores e operadores fazem julgamentos diferentes sobre urgência. Se uma classificação assistida por máquina se transforma em uma ordem de correção, a instituição que emite essa ordem precisa tornar compreensíveis suas evidências e seu caminho de recurso; um identificador neutro não pode carregar a responsabilidade por uma decisão tomada por outra pessoa.

O NIST tornou explícita a ordem de análise

Em abril de 2026, o NIST restringiu a análise detalhada da NVD a CVEs no Known Exploited Vulnerabilities Catalog da CISA e a falhas que afetam software crítico, sistemas federais ou ativos sob exploração ativa. O NIST não anunciou que fornecedores e outros participantes deixariam de atribuir identificadores CVE. Mudou quais registros receberiam análise detalhada.

O catálogo de vulnerabilidades conhecidas exploradas da CISA oferece uma razão para a prioridade: ele identifica falhas que atacantes estão usando, e a CISA exige que órgãos federais corrijam vulnerabilidades listadas dentro de prazos determinados. Mais tarde, a CISA reduziu para três dias o prazo das vulnerabilidades federais mais críticas, citando o uso de IA por hackers. Um sinal de exploração dá a um conjunto específico de operadores um prazo.

Priorizar exploração conhecida é melhor do que tratar cada rótulo de alta gravidade como uma ordem de reparo igualmente urgente, mas deixa lacunas. Uma falha não precisa aparecer no catálogo para ser perigosa, e uma prioridade federal não precisa descrever a exposição de um operador privado. O NIST pode estabelecer uma ordem pública de análise; cada organização ainda precisa determinar se usa o software afetado, onde ele está exposto e o que pode tirar de operação com segurança. Um operador não pode inferir segurança de um registro da NVD que não foi enriquecido.

A IA torna uma descoberta mais fácil de produzir do que de confiar

Desenvolvedores estão adicionando código à fila de revisão mais rapidamente. Uma pesquisa do Stack Overflow constatou que 84% dos desenvolvedores usavam ou planejavam usar ferramentas de IA em seus fluxos de trabalho, ante 76% em 2024, enquanto a confiança na precisão da IA caiu de 43% para 33%. Empresas têm enfrentado dificuldades para revisar o volume resultante de código gerado. Pesquisadores de segurança podem usar ferramentas relacionadas para encontrar fraquezas nesse código e em software anterior a ele.

A Anthropic reportou 5.500 vulnerabilidades verificadas encontradas de abril a outubro de 2026; seus parceiros Glasswing reportaram mais de 129.000 de abril a julho, incluindo mais de 33.000 classificadas como de gravidade crítica ou alta. Essas descobertas reportadas não devem ser tratadas como um número equivalente de novas entradas CVE ou de correções concluídas. Elas mostram por que a verificação não pode ser deixada como uma reflexão posterior à descoberta.

A mesma busca barata pode enviar trabalho não verificado para a caixa de entrada de outra pessoa. O Google suspendeu o envio de relatos de falhas em produtos para seu OSS Vulnerability Reward Program em meio a reportes inválidos gerados por IA. O Curl planejou encerrar seu programa HackerOne depois que relatos de baixa qualidade gerados por IA sobrecarregaram seus mantenedores. O problema de verificação em programas de recompensa por bugs expõe o custo que uma contagem de descobertas omite: alguém precisa reproduzir uma alegação, identificar a versão afetada, eliminar duplicatas e decidir quem é responsável pela correção. Um pesquisador automatizado que fornece apenas uma descrição plausível transfere esse trabalho para o destinatário.

Atacantes também enfrentam menos atrasos. Uma análise do desenvolvimento de exploits assistido por IA citou um caso de 30 minutos entre uma correção e um exploit e argumentou que janelas tradicionais de divulgação poderiam se tornar insustentáveis para problemas críticos. Esse caso é um argumento sobre velocidade possível, não um intervalo medido para todas as vulnerabilidades. Ainda assim, ele explica por que o tempo entre uma descoberta sólida e uma resposta autorizada importa tanto quanto a precisão da própria descoberta.

A prova precisa chegar ao responsável pelo ativo exposto

Em outubro de 2026, atacantes comprometeram controladores de refrigeração conectados à internet em cerca de 700 supermercados europeus, explorando vulnerabilidades críticas em três modelos de controladores identificados pela Claroty e pela CISA. Um identificador público poderia nomear cada falha. As descobertas de produtos da Claroty e da CISA poderiam ajudar a identificar os modelos afetados. Nenhuma das duas etapas, por si só, poderia dizer a um operador de supermercado quais controladores estavam conectados ou quem poderia isolar um deles sem interromper a refrigeração.

A Censys monitora hosts na internet e seu status de segurança. Startups que buscam verificação formal de software, incluindo a &Truth, tentam produzir evidências mais fortes sobre o comportamento do software. Um operador precisa conectar uma alegação confiável sobre uma falha ao sistema que de fato opera.

A transferência exige uma descoberta reproduzível, um produto e uma versão afetados, evidências de acessibilidade ou exposição, um responsável e uma decisão de corrigir, isolar ou aceitar o risco. Quando um modelo ajuda a fazer essa avaliação, preservar as evidências permite que um revisor humano conteste as entradas e identifique quem aprovou a ação.

Um número CVE cabe em uma etiqueta. A decisão está ao lado de um controlador de refrigeração em operação, com um operador que precisa decidir se deve isolá-lo.