Atualização do Project Glasswing: o que a evidência diz sobre a descoberta de vulnerabilidades impulsionada por IA

O que mudou após a primeira atualização do Glasswing

A atualização inicial da Anthropic afirma que, após aproximadamente um mês, a Anthropic e cerca de 50 parceiros do Project Glasswing haviam usado o Claude Mythos Preview para identificar mais de 10.000 vulnerabilidades de severidade alta ou crítica em software considerado sistemicamente importante. A Anthropic também reporta que vários parceiros aumentaram sua taxa de detecção de falhas de segurança em mais de um fator de dez.

São afirmações de grande importância e deveriam ser lidas com a mesma cautela com que abordamos nosso post anterior. As estimativas de severidade dependem do contexto; muitas descobertas se encontram dentro de janelas de divulgação coordenada, e a avaliação inicial de um modelo não equivale a uma vulnerabilidade confirmada pelo mantenedor. Mesmo assim, a nova atualização é mais concreta do que o anúncio inicial. Inclui exemplos de parceiros, estatísticas de varredura de código aberto, um dashboard de divulgação e referências a benchmarks que poderão ser inspecionados com o tempo.

Em um anúncio posterior sobre a ampliação do Project Glasswing, a Anthropic indicou que o programa está indo além de seu grupo inicial de cerca de 50 parceiros para ampliar seu acesso a aproximadamente 150 organizações adicionais. Segundo se informa, o novo grupo abrange mais de 15 países e inclui setores que estavam menos representados no lançamento, como energia, água, saúde, comunicações e hardware. Essa expansão altera a escala da ambição do projeto: o Glasswing não se apresenta mais apenas como um experimento defensivo com grandes empresas de tecnologia, mas como uma tentativa de aproximar as capacidades do seu modelo a organizações cujo software ou infraestrutura poderiam afetar populações muito grandes se fossem comprometidos.

Até agora, os números públicos mais interessantes se apresentam no trabalho da Anthropic com código aberto. Segundo a atualização, o Mythos havia varrido mais de 1.000 projetos open source e gerado 23.019 descobertas candidatas, incluindo 6.202 inicialmente estimadas como de severidade alta ou crítica. Um subconjunto de 1.752 descobertas de severidade alta ou crítica havia sido avaliado por empresas externas de segurança ou por pessoal da Anthropic; dessas descobertas, 90,6% foram consideradas verdadeiras positivas válidas e 62,4% foram confirmadas como de severidade alta ou crítica após a revisão.

Soa impressionante, mas a evolução do número é mais importante do que o dado global. No dashboard de divulgação coordenada de vulnerabilidades, o funil se estreita rapidamente: as descobertas candidatas se tornam descobertas revisadas externamente, as descobertas revisadas se tornam vulnerabilidades confirmadas, as vulnerabilidades confirmadas se tornam relatórios para os mantenedores, e apenas um conjunto muito menor se torna software corrigido com avisos públicos. Essa diminuição não significa um fracasso para o projeto, é claro. É evidência do trabalho real que implica converter o output de segurança gerado por IA em algo útil.

Talvez o dashboard seja mais importante para o AppSec do que o anúncio em si, porque converte uma afirmação sobre a capacidade de um modelo em um fluxo de trabalho observável: candidato, priorizado, validado, reportado, reconhecido, corrigido e divulgado publicamente. Esse é o tipo de estrutura que o setor precisará se a descoberta assistida por IA se tornar comum. Sem um registro, uma fila, revisão de severidade, comunicação com mantenedores e acompanhamento de patches, "encontramos milhares de vulnerabilidades" não se constitui em um resultado valioso para a segurança; é simplesmente uma acumulação de tarefas pendentes.

O processo de divulgação da Anthropic agora faz parte da história

Uma das medidas responsáveis que a Anthropic adotou é publicar uma política de divulgação coordenada para as vulnerabilidades descobertas por meio do Claude. A política busca seguir a norma conhecida de divulgação em 90 dias ou a divulgação pública após a revelação de um patch, com possíveis extensões quando os mantenedores estiverem trabalhando ativamente em uma correção. Para vulnerabilidades críticas exploradas ativamente, a Anthropic descreve uma linha do tempo muito mais curta, com um patch ou uma mitigação esperados em um prazo de 7 dias, com possibilidade de uma breve extensão.

A política também diz algo importante sobre o ritmo: a Anthropic pretende entregar relatórios revisados por humanos, com correções sugeridas quando possível, e regular o volume de envios de acordo com o que os mantenedores possam gerenciar. Este último aspecto não é trivial. Se os sistemas de IA aceleram a descoberta muito mais do que os mantenedores podem priorizar e corrigir, a divulgação não coordenada pode se tornar outra forma de pressão sobre o ecossistema.

Portanto, o Project Glasswing opera em um ponto intermediário difícil. Por um lado, atrasar demais a divulgação deixa os usuários expostos a vulnerabilidades que outros poderiam descobrir de forma independente. Por outro lado, divulgar muito cedo pode saturar os mantenedores e fornecer aos atacantes detalhes úteis antes que as correções estejam prontas e implementadas. Este não é um problema que o Mythos resolve. É um problema que o Mythos torna visível em escala.

A expansão da Anthropic também deixa claro que o acesso continua sendo um tema fundamental em matéria de governança. A empresa afirma que está trabalhando para alcançar o acesso generalizado às capacidades de nível Mythos, mas apenas após desenvolver medidas de segurança suficientemente sólidas para evitar o uso indevido, um problema que, segundo admite, ainda não foi resolvido pela Anthropic nem, segundo seu conhecimento, por outros desenvolvedores de IA. Enquanto isso, planeja expandir ainda mais o Project Glasswing e escalar um programa de verificação cibernética que colocaria à disposição de mais organizações seu modelo para tarefas defensivas específicas.

A armação importa tanto quanto o modelo

Vários relatórios de parceiros da Anthropic dentro do Glasswing convergem em uma lição que deveria ser familiar para as equipes de AppSec: um modelo poderoso não é suficiente; ele precisa de uma boa armação.

A análise da Cloudflare é um dos exemplos mais claros. Ela descreve um pipeline que não se limita a atribuir um agente genérico de programação a um repositório e pedir que encontre erros. Em vez disso, o processo cria contexto de arquitetura, divide o trabalho em tarefas específicas, executa múltiplos agentes em paralelo, valida as descobertas de forma adversarial, descarta causas raiz duplicadas, rastreia se uma falha é alcançável de fora do sistema e converte o output em relatórios estruturados.

Isso é importante porque os agentes genéricos de programação estão otimizados para um modo de trabalho diferente. São bons para manter um fluxo de contexto focado enquanto constroem, reparam ou refatoram. A pesquisa de vulnerabilidades, por outro lado, geralmente requer muitas hipóteses específicas através de numerosos arquivos, limites de confiança e classes de ataque. Um único agente de longa duração que "busca vulnerabilidades" em um repositório grande pode gerar ideias interessantes, mas não oferecerá uma cobertura significativa. Uma armação dá forma ao trabalho.

A experiência da Mozilla ao fortalecer o Firefox conta uma história semelhante. Experimentos anteriores com auditorias de código baseadas em LLMs mostraram potencial, mas geraram muitos falsos positivos, o que impede sua ampliação em larga escala. Segundo a Mozilla, as armações agênticas mudaram esse panorama porque podiam criar e executar casos de teste reproduzíveis, testando hipóteses de forma dinâmica em vez de deixar relatórios especulativos na fila de triagem. Em seguida, a Mozilla construiu seu próprio pipeline sobre sua infraestrutura existente de fuzzing, paralelizou os trabalhos em máquinas virtuais efêmeras e integrou os resultados ao ciclo de vida dos erros de segurança do Firefox: descarte de duplicatas, acompanhamento, priorização, correção, testes e gestão de lançamentos.

Este é um ponto-chave para os programas de segurança de aplicações. A unidade de referência não é o "resultado do modelo". A unidade de referência é uma descoberta validada que foi reproduzida, avaliada em seu contexto, atribuída a um responsável, remediada de forma segura e verificada. Os modelos podem acelerar algumas etapas desse processo, mas não eliminam a necessidade de realizá-lo.

A Anthropic também afirmou que está ampliando os casos de uso defensivos associados a modelos como o Mythos, incluindo a redação de patches, verificações pré-lançamento, testes de penetração, detecção e resposta automatizadas a ameaças e até mesmo a reconstrução de código legado em linguagens seguras para a memória. Essas tarefas não devem ser consideradas uma única capacidade genérica de segurança baseada em IA; cada uma requer seu próprio ambiente de execução, controles, métricas de sucesso e revisão humana.

A descoberta melhora, mas a validação continua sendo onde o risco se torna real

A avaliação da XBOW acrescenta outra distinção útil. A empresa descobriu que o Mythos é particularmente forte em auditoria de código-fonte e em raciocínio técnico, especialmente quando o código-fonte está disponível. Mas também enfatizou que a validação em ambientes ao vivo continua sendo complicada. Muitos problemas exploráveis não são evidentes apenas no código da aplicação; surgem de decisões de implantação, configurações, dependências, permissões e a maneira como componentes aparentemente seguros interagem em produção.

A mesma avaliação também aponta o julgamento dos modelos como um âmbito com resultados mistos. O Mythos pode reduzir os falsos negativos em alguns cenários e produzir análises técnicas precisas, mas ainda pode ser excessivamente conservador, excessivamente literal ou inconsistente no raciocínio sobre a segurança dos comandos. Isso não é surpreendente. O trabalho em matéria de segurança está repleto de decisões de julgamento: se uma vulnerabilidade é alcançável, se é seguro executar uma prova de conceito, se uma classificação de severidade se ajusta ao modelo de ameaças do projeto e se uma correção modifica o comportamento de formas inaceitáveis. Um modelo pode ser bastante útil, mas não pode substituir uma revisão responsável.

A capacidade de exploração está sendo medida com mais seriedade

Um dos avanços mais relevantes para os defensores de cibersegurança é o surgimento de benchmarks mais sólidos em relação ao desenvolvimento de exploits. O blog Frontier Red Team da Anthropic fala sobre o ExploitBench e o ExploitGym, sendo o primeiro especialmente útil porque não trata a exploração como um evento binário de sucesso ou fracasso. Pelo contrário, ela a divide em etapas: alcançar o código vulnerável, reproduzir a vulnerabilidade, construir primitivas de exploração específicas para o alvo, construir primitivas genéricas que escapem dos limites de isolamento e, finalmente, alcançar a execução arbitrária de código.

Essa distinção é importante: uma falha não é o mesmo que um exploit. Chegar a uma função vulnerável não é o mesmo que obter o controle de um sistema. Uma prova de conceito pode revelar a existência de um erro sem demonstrar que um atacante possa convertê-lo em um impacto significativo. O ExploitBench tenta medir todo o processo, em vez de apenas uma etapa.

No benchmark V8 do ExploitBench, a Anthropic reporta que o Mythos alcançou a execução arbitrária de código em 21 de 41 ambientes de CVE ao combinar a variante de referência (sem indicações adicionais específicas sobre a vulnerabilidade) e a variante "nudged" (uma breve pista que orienta o modelo para a área vulnerável). Nenhum outro modelo alcançou a execução arbitrária de código nem uma única vez em nenhuma das duas variantes, salvo mediante um andaime (scaffold) proprietário que alcançou esse resultado em dois casos. A análise das avaliações de exploits da Anthropic enquadra isso como parte de uma necessidade mais ampla: medir até onde os modelos podem avançar da descoberta de vulnerabilidades à exploração funcional, em vez de tratar todo progresso parcial como equivalente.

Esta é uma das partes mais sérias da atualização. Ela sugere que a lacuna de capacidades não se limita à detecção de falhas, mas também abrange o avanço das falhas para os exploits. Para os defensores, isso comprime o tempo disponível entre a publicação de um patch, a compreensão da vulnerabilidade subjacente por parte de um atacante e a viabilidade prática do código de exploração. Também reforça por que os tempos de teste e implantação de patches importam; se construir exploits se torna mais barato, o custo de uma remediação lenta aumenta.

Os resultados do AISI sugerem rápida evolução de capacidade, com incertezas

O AI Security Institute do Reino Unido traz uma perspectiva mais ampla sobre as capacidades. Seu conjunto de tarefas cibernéticas estima a extensão das tarefas que os modelos de fronteira podem completar de forma autônoma, com um limiar de confiabilidade. Em fevereiro de 2026, o AISI estimou que o "horizonte temporal" cibernético com 80% de confiabilidade havia dobrado a cada 4,7 meses desde o final de 2024. O Mythos Preview e o GPT-5.5 superaram significativamente essa tendência nos testes do AISI.

O AISI é cuidadoso com a incerteza. Suas tarefas não são intrusões reais completas contra sistemas defendidos. As tarefas mais longas são escassas, as linhas de base humanas (os resultados de referência obtidos quando as pessoas realizam os mesmos testes de desempenho) são imperfeitas, os orçamentos de tokens afetam os resultados e os benchmarks atuais podem ser muito curtos para medir como a confiabilidade se degrada em tarefas mais longas. Mesmo assim, a conclusão geral do AISI é difícil de ignorar: a capacidade cibernética autônoma avança em um ritmo significativo mensal, não apenas anual.

Isso não significa que toda organização deva entrar em pânico. Significa que as equipes de segurança deveriam deixar de considerar a exploração assistida por IA como uma preocupação remota. Embora as capacidades atuais continuem sendo desiguais, seu ritmo de melhora é suficientemente rápido para influenciar a forma como as equipes planejam os testes, a remediação de vulnerabilidades e a resposta a incidentes.

Resultados de parceiros mostram capacidade de correção, não apenas descoberta

Os relatórios de parceiros importam porque revelam o que acontece depois que o modelo encontra problemas. A Palo Alto Networks reportou que seu aviso "Patch Wednesday" de maio incluiu 26 CVEs que representavam 75 problemas, em comparação com seu volume mensal habitual de menos de cinco CVEs, após uma varredura inicial de mais de 130 produtos. Também enfatizou que os resultados de alta fidelidade requerem armações, contexto, controles de segurança, inteligência de ameaças e uma abordagem multimodelo. Essa é uma correção útil à versão mais simples da história do Mythos. A IA de fronteira pode encontrar problemas importantes, mas nenhum modelo ou prompt por si só é suficiente para identificar o conjunto completo de vulnerabilidades.

A atualização da Oracle é útil por outro motivo: separa os ambientes administrados pelo fornecedor dos administrados pelo cliente. Nos serviços de nuvem administrados pela Oracle, o fornecedor pode aplicar patches continuamente. Em implantações administradas pelo cliente, a Oracle pode entregar correções, mas os clientes ainda precisam planejá-las, testá-las e aplicá-las. A Oracle também anunciou Critical Security Patch Updates mensais para correções críticas específicas, em vez de depender apenas de ciclos trimestrais.

Essa distinção vai muito além da Oracle. Se a descoberta assistida por IA aumentar o número de descobertas urgentes, as organizações que puderem aplicar patches de forma centralizada se moverão mais rapidamente. Aquelas com ambientes on-premises, administrados pelo cliente ou altamente integrados enfrentarão mais fricção. É aqui que AppSec, infraestrutura, operações e gestão de mudanças se tornam inseparáveis.

A Mozilla oferece outro exemplo prático: a correção de 271 erros do Firefox identificados por meio do Mythos não exigiu apenas os resultados do modelo, mas também a intervenção de pessoas, ou seja, engenheiros que escreveram e revisaram patches, equipes que escalaram o pipeline, priorizaram relatórios, testaram correções e gerenciaram implantações. Mais de 100 pessoas contribuíram com código para essa iniciativa. É assim que se parece na prática um programa de segurança impulsionado por IA: um modelo no centro do processo de detecção, rodeado de pessoas, ferramentas e uma disciplina de lançamentos.

Claude Security: a produtização do fluxo de trabalho

O produto Claude Security da Anthropic é outro sinal de para onde isso está indo. Atualmente está em beta público para clientes do Claude Enterprise e se apresenta como uma ferramenta que varre bases de código, valida descobertas e sugere patches para revisão. A Anthropic afirma que cada descoberta passa por uma verificação adversarial, que as correções sugeridas preservam a estrutura e o estilo do projeto, e que as equipes podem integrar os resultados a fluxos de trabalho como Slack, Jira, varreduras recorrentes e exportações para auditoria.

Isso é relevante mesmo que não tratemos o Claude como a resposta definitiva. A existência desse produto mostra como as lições do Glasswing estão passando de um programa de pesquisa controlado a ferramentas empresariais de segurança. A linguagem do produto também é reveladora: varrer, validar, corrigir, revisar, aprovar. A proposta de valor, como reconhecemos há anos na Fluid Attacks, não é apenas "encontramos vulnerabilidades." É "ajudamos a passar da descoberta à remediação mantendo os humanos no controle."

Para as empresas de AppSec, isso lembra que o mercado normalizará rapidamente a detecção assistida por IA. Um scanner que apenas produz uma lista cada vez mais extensa de descobertas será cada vez menos convincente. O diferencial estará em quão bem uma plataforma valida descobertas, lhes atribui prioridades, as conecta com a exposição ao risco do negócio, propõe rotas seguras de remediação, verifica as correções e se integra à forma como os desenvolvedores já trabalham.

O que o dashboard ensina às equipes de AppSec

O dashboard de divulgação coordenada de vulnerabilidades da Anthropic merece atenção especial por parte dos profissionais de AppSec porque expõe a física operacional da descoberta de vulnerabilidades assistida por IA. A parte superior do funil é grande: 23.019 descobertas candidatas. O resultado público é muito menor: segundo a captura do dashboard, 1.596 vulnerabilidades em 281 projetos open source haviam sido divulgadas; 97 haviam sido corrigidas e 88 haviam recebido um CVE ou um GitHub Security Advisory.

Esses números mostram que, de fato, a identificação de vulnerabilidades pode escalar mais rápido do que a remediação e que esta não é um evento único. Inclui reprodução, avaliação de severidade, comunicação com mantenedores, design, revisão e lançamento de patches, publicação de avisos e implantação por parte dos usuários finais.

O dashboard também nos lembra que "verdadeiro positivo" não equivale a "alto impacto no negócio." A Anthropic aponta que as taxas de verdadeiros positivos incluem descobertas que podem ser reais, mas que estão fora do modelo de ameaças de um projeto, afetam código que normalmente não é alcançável ou são tratadas de forma diferente posteriormente pelos mantenedores. A concordância quanto à severidade também é imperfeita; na captura pública, a Anthropic reportou 58,7% de coincidência exata entre a avaliação inicial de severidade do Claude e as avaliações de empresas externas de segurança e 94,4% de coincidência dentro de um nível de severidade.

Isso não é um fracasso da IA; é um lembrete do que sempre foi a gestão de vulnerabilidades: um exercício contextual, adversarial, aproximado e limitado por restrições operacionais.

Um desafio útil: o sistema acima do modelo

Vale a pena mencionar a análise da AISLE porque questiona uma interpretação excessivamente centrada no modelo. A empresa testou se modelos menores e mais baratos podiam redescobrir descobertas conhecidas do Mythos, incluindo CVE-2026-4747 no FreeBSD, e reportou que vários modelos podiam identificar a vulnerabilidade em testes repetidos ao nível de arquivo, enquanto ignoravam corretamente a versão corrigida. O argumento mais amplo da AISLE é que um sistema de varredura bem projetado, com cobertura paralela, prompts, triagem e um orçamento de tokens suficiente, pode compensar parte das lacunas de capacidade do modelo.

Isso é, talvez, uma forma de reconhecer que o modelo de fronteira é apenas uma parte da equação. A pergunta prática para os defensores talvez não seja "temos o modelo mais poderoso?", mas sim "temos o sistema adequado ao redor dos modelos que podemos acessar?" Esse sistema deveria incluir: seleção de alvos, contexto da base de código, design da armação, validação, descarte de duplicatas, análise de alcançabilidade e acompanhamento da remediação.

Isso é especialmente importante para as organizações que não terão acesso antecipado a modelos restritos. Esperar um lançamento de nível Mythos não é uma estratégia. Construir a capacidade operacional para usar os modelos atuais de forma segura e eficaz é.

O que isso significa para o AppSec

Para reiterar, o primeiro mês do Project Glasswing demonstra que a detecção de vulnerabilidades e o desenvolvimento de exploits por meio de sistemas baseados em IA estão se tornando mais rápidos, mais automatizados e mais quantificáveis. A consequência não é que o trabalho humano em matéria de segurança desapareça, mas que se reorienta para a coordenação, a validação, a priorização, a remediação e a tomada de decisões responsáveis.

Para as equipes de AppSec, algumas lições se destacam.

Primeiro, os testes de segurança devem se tornar mais frequentes ou, melhor dizendo, contínuos. Se os modelos podem varrer código e gerar testes com rapidez, os ciclos anuais ou trimestrais de avaliação se verão cada vez mais desalinhados com a velocidade tanto do desenvolvimento quanto da exploração.

Segundo, as descobertas devem ser vinculadas à alcançabilidade e à explorabilidade. Um erro teórico, uma falha reproduzível e uma vulnerabilidade alcançável em produção são coisas distintas. As plataformas que não consigam distingui-las desperdiçarão o tempo de analistas e desenvolvedores.

Terceiro, as capacidades de remediação dependem da estratégia operacional. As organizações que mais se beneficiarão da descoberta assistida por IA não serão as que gerarem a lista de descobertas mais longa; serão as que puderem resolver problemas de forma segura, rápida e verificável.

Quarto, a diversidade de modelos importa. Diferentes modelos têm pontos fortes e pontos cegos distintos. Uma abordagem AppSec robusta não deveria depender de um único fornecedor, modelo ou benchmark.

Por último, os programas de segurança requerem fluxos de trabalho auditáveis. À medida que as descobertas geradas por IA se integrem à gestão de vulnerabilidades, as organizações precisarão de evidências de como as descobertas foram validadas, quem aprovou as correções, quando os patches foram implantados e se o risco de fato diminuiu.

A perspectiva da Fluid Attacks

Para a Fluid Attacks, essa atualização reforça uma posição que mantemos há anos: a detecção de vulnerabilidades é apenas uma fase inicial da segurança das aplicações. O valor real reside em reduzir a exposição ao risco por meio de testes contínuos, validação especializada, priorização rigorosa, apoio constante na remediação e verificação disciplinada.

Os agentes de IA podem acelerar o trabalho de segurança. Podem inspecionar mais código, gerar hipóteses, escrever provas de conceito e sugerir correções. Mas precisam de um sistema controlado ao seu redor e as organizações precisam de governança sobre seus resultados. Caso contrário, a IA simplesmente aumenta a velocidade com que a incerteza entra na lista de pendências.

Os programas de AppSec mais sólidos combinarão automação, expertise humana e disciplina de plataforma. A automação amplia o alcance; os especialistas trazem discernimento; a plataforma mantém o trabalho rastreável, priorizado e conectado à remediação. É assim que as organizações passam de saber que têm vulnerabilidades a demonstrar que reduziram sua exposição ao risco.

A atualização inicial do Project Glasswing nos reafirma a ideia de que a identificação de vulnerabilidades está ficando mais barata, a construção de exploits está se tornando mais acessível, as filas de divulgação são cada vez mais difíceis de gerenciar e os ciclos de correção estão sob pressão. As equipes de segurança que tratarem essas mudanças como uma razão para comprar mais detecção perderão de vista o essencial: o verdadeiro desafio é construir sistemas que convertam as descobertas em uma redução verificada do risco.

De fato, a Fluid Attacks — com suas ferramentas automatizadas, sua IA e seus pentesters — está aqui para ajudá-lo a ir além da mera detecção de vulnerabilidades de segurança. Entre em contato conosco.