40.000 CVEs, NIST limita análises detalhadas

Em março de 2024, o Instituto Nacional de Padrões e Tecnologia dos EUA (NIST) analisou 199 dos 3.370 registros CVE que recebeu. O Programa CVE já havia dado a cada vulnerabilidade um identificador comum.

O Programa CVE pode distribuir a atribuição de identificadores; NIST, fornecedores e defensores ainda precisam empregar capacidade escassa para validar falhas, estabelecer o contexto de exploração, localizar sistemas expostos, orientar reparos e verificar se esses reparos foram efetivados.

O Programa CVE escalou a nomenclatura antes que alguém escalasse a interpretação

Os identificadores comuns do Programa CVE permitem que pesquisadores, fornecedores e operadores se refiram à mesma vulnerabilidade sem conciliar nomes concorrentes. O programa da MITRE havia se tornado um sistema distribuído de notificações em 2025: o CyberScoop contou 413 organizações reportando entradas. O Programa CVE registrou mais de 40.000 entradas em 2024, elevando o total acumulado para mais de 270.000. A atribuição distribuída é uma força, não uma parte fracassada do sistema.

Um identificador estabelece que os participantes podem discutir uma falha. Não estabelece se um invasor consegue explorá-la, se uma organização específica executa o código afetado ou se uma correção disponível chegou a essa organização. O fluxo de enriquecimento de CVEs do NIST exige outro insumo: tempo analítico aplicado depois que um registro chega.

Essa distinção se tornou mensurável em março de 2024. O NIST analisou 199 dos 3.370 CVEs que recebeu naquele mês e citou apoio interagências insuficiente. Após uma lacuna de financiamento em 2024, seu acúmulo cresceu; em julho de 2025, a MIT Technology Review informou que mais de 25.000 vulnerabilidades aguardavam análise, cerca de dez vezes o recorde anterior em 2017. Nenhum dos números diz que a atribuição de CVEs parou. Juntos, mostram por que um registro crescente já não podia implicar uma análise igualmente rápida de cada entrada.

O NIST transformou a atenção analítica em uma decisão de risco

Em abril de 2026, o NIST restringiu a análise detalhada da National Vulnerability Database a falhas envolvendo software crítico, sistemas federais ou exploração ativa, incluindo entradas no catálogo Known Exploited Vulnerabilities da CISA. O NIST também disse que analisaria pedidos de detalhamento sobre vulnerabilidades fora dessas prioridades. Não anunciou que falhas não prioritárias perderiam seus IDs CVE nem que nenhuma exceção poderia receber análise.

A CISA já havia fornecido uma distinção operacional. Seu catálogo Known Exploited Vulnerabilities identifica falhas que se sabe terem sido exploradas e orienta agências federais a corrigir as vulnerabilidades catalogadas dentro de prazos prescritos. Um CVE nomeia uma falha; uma listagem KEV acrescenta evidência de uso por invasores e uma obrigação de resposta para essas agências. Os critérios do NIST acrescentam outros motivos para dedicar atenção, incluindo a importância do software e seu uso em sistemas federais.

Esses critérios também deixam um problema de julgamento. A exploração conhecida é uma forte evidência de urgência, mas a ausência de uma listagem KEV não prova que um sistema exposto está seguro. O processo de solicitação do NIST abre espaço para casos que suas categorias permanentes não contemplam. A cobertura fornecida não informa dados comparáveis de produção, acúmulo ou adoção de correções após a política, portanto ainda não é possível estabelecer se a seleção do NIST tornou mais rápida a análise de alto impacto.

Exploits mais rápidos encurtam a vida útil de um registro sem triagem

Pesquisadores da Anthropic disseram que seu modelo Mythos Preview poderia transformar vulnerabilidades divulgadas publicamente em exploits funcionais em horas, em vez de semanas. Trata-se de uma alegação sobre a capacidade demonstrada pelo modelo, não de um tempo de conversão medido para toda falha pública. Ainda assim, isso muda a decisão de um defensor diante de uma vulnerabilidade recém-divulgada e acessível: esperar por uma entrada de banco de dados uniformemente completa pode consumir grande parte do tempo disponível para corrigir ou isolar o sistema.

Defensores precisam manter dois sinais separados. O catálogo KEV da CISA registra exploração conhecida; a capacidade de um modelo de produzir um exploit indica velocidade potencial, não prova de que invasores já estejam usando um. Por sua vez, um fornecedor lançar uma correção não estabelece que um operador a instalou. Uma decisão de triagem útil registra qual sinal justificou a ação urgente e quais evidências ainda faltam.

A IA amplia a capacidade de descoberta e também testa a capacidade de reparo

A Anthropic e seus parceiros do Project Glasswing ilustram como o volume de candidatos pode crescer rapidamente sem gerar uma contagem comparável de sistemas reparados. A Reuters informou o número da Anthropic de 5.500 vulnerabilidades verificadas encontradas de abril a outubro de 2026. Parceiros do Glasswing reportaram mais de 129.000 achados de abril a julho, mais de 33.000 classificados como de severidade crítica ou alta. Os veículos, períodos e termos diferem. O registro fornecido não estabelece como esses conjuntos se sobrepõem, quantos achados receberam CVEs ou quantas correções chegaram ao software implantado.

A OpenAI oferece um contraponto importante à ideia de que a automação apenas aumenta a fila. Ela descreveu um pipeline assistido por IA que validou e corrigiu 948 vulnerabilidades de escalonamento local de privilégios no Linux, a um custo de US$ 1,2 milhão em APIs. Isso é trabalho posterior à detecção, não apenas detecção. A conta de APIs não é uma contabilização completa de revisão, integração ou implantação, e uma correção produzida não é evidência de que todo operador afetado a adotou.

Fornecedores, mantenedores e operadores pagam por etapas diferentes desse trabalho. Um fornecedor pode publicar uma correção enquanto um operador arca com o custo de encontrar instalações afetadas e alterá-las. Para decisões de alto impacto, uma revisão humana auditável deve preservar por que um achado foi aceito, por que um sistema teve prioridade e quem confirmou o reparo. A automação pode reduzir o esforço de investigação sem tornar a responsabilização opcional.

Um sistema exposto, não um CVE, é a unidade que um defensor pode proteger

O relato da Socket sobre o comprometimento do Axios no npm torna concreto o problema de inventário. Invasores introduziram uma dependência maliciosa em versões específicas de um pacote que, segundo relatos, recebia 100 milhões de downloads semanais. Essa contagem de downloads descreve distribuição, não o número de instalações comprometidas. Um operador precisava saber quais versões seus aplicativos de fato usavam. O incidente também mostra por que o trabalho de segurança não pode ser organizado apenas em torno de registros CVE: uma versão comprometida de pacote exige uma resposta de implantação, tenha ou não um identificador de vulnerabilidade fornecido o ponto de partida.

No outro extremo da escala, invasores exploraram falhas críticas em três modelos de controladores de geladeiras conectados à internet em um ataque que afetou cerca de 700 supermercados europeus. A Claroty e a CISA sinalizaram as vulnerabilidades dos modelos, mas as lojas afetadas eram definidas pelos controladores que haviam implantado e exposto. A identidade do produto, a acessibilidade e a capacidade de substituir ou reparar esses controladores determinaram o trabalho.

Se fornecedores e operadores puderem levar evidências de exploração, detalhes das versões afetadas e o status de reparo da divulgação à implantação, o NIST poderá concentrar sua análise sem pedir que o registro CVE se torne menor. O NIST recebeu 3.370 falhas nomeadas naquele março. Para um operador com um sistema exposto, a verificação final é se ele ainda executa o código vulnerável.