A alegação de Schneier sobre descoberta de vulnerabilidades por IA pressiona a correção de software
O resumo do artigo de Bruce Schneier, de 2 de novembro, destaca uma alegação surpreendente: 3% das vulnerabilidades críticas de software registradas historicamente teriam sido encontradas em um mês. O trecho fornecido de sua publicação sobre descoberta de vulnerabilidades por IA também projeta cerca de 100.000 descobertas adicionais por ano. Esses números ainda não foram verificados aqui, mas descobertas documentadas já pressionam as equipes responsáveis por corrigir software.
O conflito central é a velocidade de descoberta versus a capacidade de correção. Encontrar uma falha de segurança cria uma oportunidade de proteger usuários. Também cria trabalho: alguém precisa validar o relatório, avaliar a exposição, revisar uma correção e entregar uma atualização. Automatizar a descoberta não acelera automaticamente todas as decisões posteriores.
Anthropic, Google e Mozilla oferecem referências úteis, embora seus números meçam coisas diferentes. Suas publicações sustentam uma conclusão mais limitada, porém relevante: a pesquisa automatizada em segurança está produzindo descobertas reais, enquanto os métodos de contagem e os resultados posteriores exigem escrutínio. Para desenvolvedores e compradores corporativos, a questão é se uma descoberta mais rápida se traduz em menor exposição.
O que a alegação sobre descoberta de vulnerabilidades por IA realmente estabelece
A estatística de destaque é uma pista de pesquisa, não uma medição independente e estabelecida das falhas críticas de software no mundo.
O trecho fornecido associado à publicação de Schneier sobre descoberta de vulnerabilidades apresenta os números como um comentário. Esta análise não conseguiu recuperar a página original. Consequentemente, o trecho não estabelece quem calculou a porcentagem, quais registros foram contabilizados ou como foi definido o período de referência.
Essa distinção limita o que pode ser afirmado de forma responsável a partir da alegação. Uma porcentagem marcante pode descrever com precisão um banco de dados específico sem descrever todas as vulnerabilidades de segurança já descobertas. Também pode se tornar enganosa quando leitores substituem silenciosamente a população original do denominador por uma mais ampla.
Descoberta, divulgação e publicação em banco de dados são eventos diferentes. Um pesquisador pode identificar uma falha de forma privada antes que um fornecedor a confirme. A documentação pública pode chegar mais tarde, junto com uma atualização de software. Portanto, um pico mensal de publicações não estabelece que cada falha subjacente foi descoberta naquele mês.
A expressão “toda a história registrada” acrescenta outro limite não resolvido. Um cálculo auditável exige um banco de dados identificado, uma captura datada e regras de inclusão consistentes. Também exige uma explicação sobre registros duplicados, submissões rejeitadas e vulnerabilidades cuja gravidade mudou após a publicação.
A projeção anual introduz uma hipótese separada: que o ritmo recente continuará. Essa hipótese merece exame mesmo que a contagem mensal original se mostre correta. Uma campanha de pesquisa concentrada, um acúmulo de publicações ou uma divulgação coordenada podem gerar um aumento temporário sem estabelecer uma taxa anual estável.
Há também um problema de categoria. O trecho começa com vulnerabilidades críticas, mas depois se refere de modo mais amplo a bugs e ao total histórico de vulnerabilidades. Essas categorias não podem ser intercambiadas sem verificar o cálculo subjacente. Um defeito de software, uma vulnerabilidade de segurança confirmada e uma vulnerabilidade crítica descrevem populações diferentes.
Nenhuma dessas limitações torna o desenvolvimento mais amplo irrelevante. Elas estabelecem onde a confiança deve parar. A narrativa defensável diz respeito à atividade de descoberta documentada e às suas consequências operacionais, e não a uma alegação não sustentada sobre um ponto de virada histórico medido com precisão.
Para leitores que encontram a descoberta de vulnerabilidades por IA por meio de publicações em redes sociais, essa distinção protege a percepção útil. As equipes de segurança têm motivos para examinar sua capacidade agora. Elas não precisam aceitar uma porcentagem não verificada antes de investigar se seus próprios processos de descoberta e correção estão se tornando desequilibrados.
Os resultados divulgados pela Anthropic mostram escala, com limites importantes
Os números publicados pela Anthropic sustentam uma alegação substancial de descoberta, mas não validam a porcentagem histórica nem a extrapolação mensal do comentário.
Em seu anúncio de 6 de outubro sobre o programa de verificação cibernética, a Anthropic relatou pelo menos 129.000 vulnerabilidades de software verificadas entre parceiros entre abril e julho. Separadamente, relatou 5.500 descobertas verificadas em sua varredura de código aberto entre abril e outubro.
A empresa afirmou que mais de 33.000 vulnerabilidades verificadas foram classificadas como de gravidade crítica ou alta. Esses são resultados relatados pela empresa, não um censo reproduzido de forma independente. Seus períodos e categorias também diferem da alegação do comentário fornecido sobre vulnerabilidades críticas descobertas em um mês.
A Anthropic divulgou limitações relevantes. Seus relatórios de impacto se basearam em informações parciais de 33 parceiros, e as organizações usaram abordagens de triagem diferentes. Menos da metade forneceu contagens de correções aplicadas. Por isso, a empresa descreveu a taxa de correção relatada como substancialmente incompleta.
Esses limites importam porque medições diferentes respondem a perguntas diferentes. Uma contagem de descobertas mede a produção relatada de identificação de falhas. Uma contagem confirmada adiciona uma etapa de validação. Uma contagem de correções aplicadas descreve um resultado posterior, enquanto evidências de implantação abordam se os usuários afetados realmente receberam proteção.
Portanto, as implicações competitivas devem permanecer limitadas. A Anthropic está relatando resultados de organizações participantes que utilizam seus modelos. Os pesquisadores de ameaças do Google examinam padrões mais amplos de divulgação e exploração. Essas publicações fornecem perspectivas complementares, mas nenhuma delas oferece uma comparação controlada que prove qual fornecedor produz melhores resultados de segurança.
Para compradores, isso significa que os totais de descobertas devem iniciar a conversa, e não encerrá-la. Um fornecedor que gera mais descobertas pode revelar problemas ignorados. Também pode exigir mais tempo de revisão do cliente, especialmente quando os relatórios não têm evidências claras de reprodução ou informações sobre versões afetadas.
Uma avaliação útil distinguiria vulnerabilidades novas e aceitas de problemas já conhecidos e relatórios duplicados. Também separaria correções sugeridas de correções revisadas. Essas distinções tornam as comparações mais difíceis, mas conectam a produção técnica ao trabalho que um cliente precisa realizar.
A pressão recai de modo especialmente intenso sobre organizações que mantêm software importante sem uma grande equipe dedicada de segurança. A capacidade de descoberta pode ser comprada ou obtida por terceiros. A responsabilidade de aceitar um relatório e alterar o produto ainda pertence a alguém, mesmo quando a análise original chega automaticamente.
Essa é uma implicação analítica da escala relatada, não um resultado mensurado de pessoal em toda a indústria. Se os relatórios validados recebidos aumentarem enquanto a capacidade de revisão permanecer fixa, a fila não resolvida crescerá. A taxa exata depende do software, das ferramentas e da capacidade de cada organização de realizar mudanças seguras.
Por isso, o acompanhamento mais útil do anúncio da Anthropic diz respeito à conclusão. Quantas descobertas aceitas chegaram a versões com suporte? Por quanto tempo permaneceram sem solução? Sem respostas comparáveis, grandes números de descoberta demonstram atividade mais claramente do que demonstram redução de exposição.
Os mantenedores de software herdam o trabalho após a descoberta
As organizações que mantêm software vulnerável carregam o ônus operacional de transformar um relatório em proteção.
As mudanças no banco de dados de vulnerabilidades do NIST, de 15 de abril, ilustram a pressão sobre a infraestrutura de informação que cerca o trabalho de segurança. A agência relatou que as submissões de vulnerabilidades aumentaram 263% entre 2020 e 2025. Disse que sua maior capacidade de processamento ainda não conseguia acompanhar o ritmo.
O NIST mudou a forma como enriquece entradas no National Vulnerability Database, seu repositório público de informações sobre vulnerabilidades. O enriquecimento adiciona detalhes como pontuações de gravidade e produtos afetados. Na abordagem revisada, categorias selecionadas recebem prioridade, enquanto outras entradas permanecem listadas sem enriquecimento imediato.
A agência priorizou vulnerabilidades conhecidas como exploradas, software utilizado pelo governo federal e software crítico definido. Também reconheceu que os critérios não capturariam todos os problemas potencialmente relevantes. Essa mudança documenta uma restrição de capacidade; não estabelece que a IA causou o crescimento subjacente nas submissões.
A implicação mais ampla é que um fluxo crescente de descobertas exige mais do que linhas adicionais em bancos de dados. Mantenedores e clientes precisam de contexto confiável para decidir o que merece atenção. Contexto ausente ou atrasado pode transferir o trabalho de interpretação para equipes já responsáveis por avaliar seus próprios sistemas.
Para um mantenedor de software, receber um relatório confiável cria diversas obrigações que não podem ser reduzidas à leitura de sua conclusão. O comportamento afetado deve ser compreendido. Uma correção proposta precisa se adequar ao projeto ao redor. Versões com suporte e componentes dependentes podem exigir decisões separadas.
Usuários corporativos enfrentam outra camada de interpretação. Um componente vulnerável pode aparecer dentro de um produto que compram, em vez de manter diretamente. Eles precisam saber quais versões instaladas são afetadas, se o comportamento vulnerável está acessível e qual ação seu fornecedor oferece como suporte.
Essas são dependências operacionais ilustrativas, não conclusões de que todas as organizações enfrentam o mesmo acúmulo. Sua importância decorre da distinção entre descoberta e remediação, o processo de corrigir ou reduzir uma vulnerabilidade. Um relatório só tem valor quando alguém pode tomar uma decisão informada sobre ele.
O desalinhamento de incentivos merece atenção. Uma plataforma de descoberta pode exibir resultados imediatamente, enquanto um mantenedor recebe menos reconhecimento visível por uma revisão cuidadosa e atualizações sem incidentes. Os compradores devem reconhecer que o volume de relatórios e a qualidade da manutenção representam contribuições diferentes para a segurança.
A documentação compartilhada se torna útil quando decisões atravessam equipes. Uma base de conhecimento pesquisável pode ajudar a conectar registros técnicos, decisões de responsabilidade e evidências de apoio. Ela favorece a coordenação; a validação e a aprovação de lançamento ainda exigem o processo de engenharia adequado.
A pressão prática é tanto organizacional quanto técnica. Descobertas mais rápidas exigem uma definição mais clara de responsabilidade por relatórios, correções e decisões de implantação. Quando essas responsabilidades permanecem ambíguas, um fluxo maior de descobertas legítimas pode expor fraquezas no processo de resposta antes de melhorar o produto.
A Mozilla mostra por que uma descoberta precisa de um processo completo de correção
O relato da Mozilla oferece um exemplo concreto de descoberta assistida por IA conectada a mudanças de software lançadas.
O relatório da Mozilla sobre o pipeline de fortalecimento do Firefox descreve a integração de modelos à infraestrutura de testes e ao ciclo de vida de bugs de segurança. A equipe afirma que uma escala útil exigiu testes reproduzíveis, detecção de duplicatas, triagem, acompanhamento e trabalho de lançamento. Ela relatou a correção de 271 descobertas do Mythos Preview no Firefox 150.
A mesma conta explica por que os totais dos bancos de dados exigem cautela: a Mozilla agrupa vários bugs relatados internamente sob identificadores compartilhados de vulnerabilidades. Portanto, sua contagem de bugs relatados não corresponde diretamente ao número de identificadores públicos. Contar qualquer uma dessas populações sem explicar essa relação pode induzir os leitores ao erro.
A Mozilla também distingue um bug grave de um comprometimento prático. Seu design de navegador em camadas significa que um invasor pode precisar de várias vulnerabilidades para atravessar as barreiras de proteção. Uma classificação de alta gravidade identifica um problema que merece ser tratado; ela não estabelece que um ataque completo já tenha sido desenvolvido.
Esses detalhes relatados formam um estudo de caso mais útil do que apenas um número de descobertas. Eles mostram um mantenedor discutindo o que acontece entre uma descoberta automatizada e uma versão lançada. Também expõem o conhecimento institucional pelo qual a saída de um modelo precisa passar antes que os usuários recebam uma correção.
A lição analítica é que a capacidade do modelo e a capacidade organizacional se multiplicam. Um sistema que encontra um problema genuíno oferece proteção limitada se ninguém consegue reproduzi-lo ou avaliá-lo. Um processo maduro de resposta obtém mais valor de evidências que chegam em um formato que seus engenheiros podem usar.
Essa relação também complica as comparações de aquisição. Um modelo avaliado dentro de um ambiente de projeto cuidadosamente preparado se beneficia de ferramentas de compilação, infraestrutura de testes e mantenedores que entendem o código. Um cliente não pode presumir resultados equivalentes ao apontar o mesmo modelo para uma aplicação desconhecida.
Considere um relatório hipotético envolvendo uma biblioteca amplamente reutilizada. A evidência inicial poderia estabelecer uma falha em um ambiente de testes. Os mantenedores ainda precisariam compreender a causa, estabelecer as versões afetadas e determinar se a correção sugerida resolve o problema subjacente.
Um teste de regressão, uma verificação que impede a reintrodução de um defeito conhecido, ajudaria a preservar a correção. A comunicação da versão precisaria descrever com precisão o comportamento afetado. Os usuários downstream então precisariam de um caminho de atualização compatível com os produtos que incorporam essa biblioteca.
Este exemplo hipotético explica o fluxo de trabalho, em vez de afirmar um incidente adicional do mundo real. Ele mostra por que a mesma descoberta pode gerar trabalho para pesquisadores, mantenedores de bibliotecas, fornecedores de produtos e operadores empresariais. Cada participante controla uma parte diferente do caminho até a proteção.
Há aqui um possível ciclo positivo. Evidências melhores podem reduzir o tempo gasto na interpretação de relatórios, deixando mais atenção para correções reais. Correções revisadas e testes úteis podem então melhorar o ambiente disponível para análises automatizadas subsequentes. Se esse ciclo se concretizará depende da implementação e de resultados medidos.
O inverso também é possível. Descobertas mal apresentadas podem consumir a atenção necessária para resolver relatórios mais sólidos. A distinção relevante não é simplesmente entre pesquisa humana e automatizada. É entre evidências que ajudam um mantenedor a agir e resultados que transferem trabalho investigativo não resolvido ao destinatário.
Os Rótulos de Gravidade Não Podem Resolver a Lacuna de Verificação
Um rótulo crítico, um identificador público e exploração observada descrevem dimensões diferentes de um problema de segurança.
O Common Vulnerability Scoring System, ou CVSS, é uma estrutura para descrever a gravidade de vulnerabilidades por meio de características técnicas definidas. A especificação de pontuação de gravidade da FIRST coloca as pontuações críticas entre 9,0 e 10,0. Essa classificação, por si só, não estabelece se invasores estão explorando uma falha em uma organização específica.
Da mesma forma, um CVE, um identificador Common Vulnerabilities and Exposures, fornece a uma vulnerabilidade divulgada publicamente uma referência compartilhada. Não é uma unidade universal de escopo técnico idêntico. A contagem depende, em parte, de como os problemas são atribuídos e representados.
Uma avaliação rigorosa do percentual original, portanto, exige regras consistentes ao longo do tempo. O numerador e o denominador devem usar populações e definições de gravidade compatíveis. Caso contrário, o cálculo pode combinar registros distintos enquanto aparenta precisão.
Há uma questão de timing igualmente consequente. Se o numerador conta registros publicados recentemente, ele mede atividade de publicação. Chamá-lo de atividade de descoberta exige evidências adicionais sobre quando os problemas subjacentes foram encontrados. Atrasos nos relatórios podem separar esses eventos.
A análise de 30 de setembro do Google sobre divulgação e exploração oferece um contexto mais amplo. Seus pesquisadores relataram 5.045 divulgações em janeiro de 2026 e 10.740 em agosto. Eles também alertaram que políticas de atribuição e ciclos de publicação dos fornecedores complicam a interpretação de totais brutos.
Os pesquisadores acompanharam a exploração separadamente e usaram suas próprias classificações de risco, em vez de categorias CVSS. Essa distinção metodológica importa: uma categoria de risco de sua análise não deve ser silenciosamente rebatizada como uma pontuação de gravidade crítica. Formulações semelhantes não tornam sistemas de classificação diferentes intercambiáveis.
Essas descobertas recomendam cautela com alegações causais. Um aumento nas divulgações pode coincidir com maior uso de IA sem estabelecer que a IA explica todo o aumento. Mudanças no comportamento de reporte, na cobertura e nas práticas de publicação também exigem análise.
A exploração observada tem seus próprios limites. Uma vulnerabilidade ausente de um conjunto de dados de monitoramento não é necessariamente segura ou intocada. Por outro lado, um grande total de divulgações não estabelece um aumento igualmente grande em comprometimentos bem-sucedidos. A visibilidade e a amostragem afetam o que os pesquisadores conseguem observar.
A posição cética mais forte, consequentemente, aceita progresso técnico genuíno ao mesmo tempo que exige medição disciplinada. Ela não exige descartar todo relatório de empresa. Pergunta se as evidências sustentam a conclusão específica apresentada, especialmente quando essa conclusão se estende a totais históricos ou à produção anual futura.
Para AI Vulnerability Finding, a questão não resolvida não é se sistemas automatizados podem identificar falhas reais. Os relatos de projetos citados já sustentam essa alegação mais restrita. A incerteza diz respeito à escala em populações comparáveis, à responsabilidade pelo aumento e à taxa com que as descobertas se tornam proteção duradoura.
Essa distinção deve moldar a discussão pública. Tratar cada falha como uma catástrofe imediata pode sobrecarregar a priorização. Tratar estatísticas agregadas incertas como motivo para ignorar descobertas documentadas cria o erro oposto. As evidências devem determinar o escopo da alegação e a urgência da resposta.
Acompanhe Correções Confirmadas, o Momento dos Lançamentos e a Replicação Independente
As próximas evidências úteis conectarão a produção de descobertas a achados aceitos, correções entregues e resultados reproduzíveis.
Nos próximos meses, acompanhe primeiro relatórios mais completos da Anthropic e das organizações participantes. O desenvolvimento útil seria apresentar contagens correspondentes mostrando quais descobertas foram aceitas, corrigidas e incluídas em versões com suporte. Relatórios comparáveis tornariam mais fáceis de avaliar as alegações atuais de descoberta.
Um relato mais sólido explicaria como relatórios duplicados e defeitos relacionados foram tratados. Ele separaria software mantido de forma privada de projetos públicos cuja documentação pode ser examinada. Também identificaria claramente o período de reporte, evitando comparações entre janelas sobrepostas ou de tamanhos diferentes.
Se essas informações mostrarem crescimento nas descobertas acompanhado de reparos concluídos, isso fortaleceria o argumento de melhoria na capacidade defensiva. Se achados confirmados se acumularem sem evidências correspondentes de lançamento, reforçaria a preocupação de que a descoberta está superando a resposta. Relatórios incompletos, por si só, deixariam o resultado incerto.
Em segundo lugar, acompanhe o intervalo entre relatórios aceitos e atualizações disponíveis. Um patch, uma alteração de software destinada a corrigir um defeito, é um marco intermediário. Uma versão com suporte disponibiliza essa correção aos usuários, enquanto a implantação determina se os ambientes afetados a recebem.
Esses intervalos importam porque o volume de processamento pode melhorar enquanto problemas individuais ainda esperam tempo demais. Uma equipe pode encerrar mais relatórios no total e, ainda assim, manter uma fila crescente de casos difíceis. Reportar apenas correções concluídas ocultaria esses itens não resolvidos.
Evidências de ciclos de reparo mais curtos e sustentáveis fortaleceriam o argumento de que a descoberta automatizada pode melhorar a segurança operacional. Filas não resolvidas em crescimento ou correções repetidas em patches anteriores o desafiariam. Ambos os resultados merecem atenção ao lado dos totais de descoberta em manchetes.
Em terceiro lugar, acompanhe a replicação independente em projetos com diferentes recursos de manutenção. Resultados de um navegador extensivamente testado são informativos, mas não estabelecem resultados equivalentes para todas as aplicações ou bibliotecas. Evidências mais amplas exigem ambientes documentados, achados aceitos e relatos claros sobre o trabalho necessário.
A replicação seria especialmente útil quando os mantenedores publicam sua própria avaliação em vez de apenas endossar o total de um fornecedor. A concordância sobre a validade e a correção de uma descoberta fornece mais informação do que uma demonstração que produz resultados convincentes. A discordância pode revelar limitações que estatísticas agregadas obscurecem.
Esses sinais oferecem uma forma de avaliar o progresso sem depender de uma previsão sobre quem, em última instância, mais se beneficia. Atacantes e defensores podem usar capacidades relacionadas, mas seus objetivos e restrições operacionais diferem. O resultado depende do acesso, da implementação e da rapidez com que mudanças protetivas chegam aos sistemas afetados.
O comentário original captura a surpresa em torno de AI Vulnerability Finding, mas a surpresa é um ponto de partida para o escrutínio. Peça o conjunto de dados por trás do percentual. Pergunte quais regras de gravidade se aplicam e se as datas descrevem descoberta ou publicação. Em seguida, acompanhe as descobertas até a confirmação, a correção e o lançamento. Se você avalia ferramentas de segurança, solicite evidências que sua própria equipe possa reproduzir e resultados que seus mantenedores reconheçam. Se você depende de fornecedores de software, pergunte como eles comunicam as versões afetadas e as correções concluídas. Leia os relatos dos projetos subjacentes antes de repetir projeções anuais. A pergunta útil é concreta: quando a descoberta acelera, as organizações responsáveis pelo seu software conseguem transformar essas evidências em proteção?
