Anthropic OSS Scanner oferece auditorias gratuitas de código aberto, mas mantenedores precisam triar a saída da IA

A Anthropic lançou o Anthropic OSS Scanner em 8 de outubro, oferecendo a projetos de código aberto elegíveis auditorias recorrentes de vulnerabilidades sem custo. O serviço representa uma expansão significativa da pesquisa de segurança assistida por IA. Também transfere uma responsabilidade importante aos mantenedores, pois seus relatórios chegam sem validação humana.

Essa contrapartida define o lançamento. A Anthropic afirma que seus modelos podem examinar mais código do que seus pesquisadores de segurança conseguem revisar manualmente. O OSS Scanner elimina esse gargalo de revisão ao enviar descobertas brutas diretamente aos projetos participantes.

O momento é desconfortável para mantenedores de código aberto. O Google pausou recentemente partes de seu programa de recompensas por vulnerabilidades em código aberto após receber volumes crescentes de relatórios automatizados inválidos. O projeto curl também encerrou seu programa de bug bounty depois que os mantenedores enfrentaram dificuldades com envios de baixa qualidade.

A Anthropic acredita que seus relatórios agora oferecem evidências muito melhores do que as descobertas geradas por IA que antes frustravam mantenedores. O feedback inicial dos projetos apoia essa afirmação em casos selecionados. No entanto, o serviço público ainda não estabeleceu como sua precisão se sustentará em uma variedade mais ampla de repositórios.

Anthropic OSS Scanner troca revisão humana por velocidade

O Anthropic OSS Scanner dá aos mantenedores acesso mais cedo a possíveis vulnerabilidades, mas cada projeto participante se torna responsável por validar as conclusões do modelo.

Segundo o lançamento do OSS Scanner, os projetos participantes recebem varreduras periódicas dos modelos mais avançados da Anthropic. Esses modelos incluem o Claude Mythos, desenvolvido pela Anthropic para trabalhos avançados de cibersegurança.

Os relatórios são totalmente gerados por modelos. A Anthropic não promete que um pesquisador de segurança verificará uma descoberta antes que ela chegue ao projeto. A empresa alerta explicitamente que os relatórios podem estar incorretos ou ser inválidos.

Cada relatório é projetado para incluir mais do que um local de código suspeito. A Anthropic afirma que fornece uma explicação, instruções de reprodução e um patch candidato, quando disponível. Um relatório também pode incluir uma análise do histórico do código que identifica quando o defeito suspeito surgiu.

Essa evidência é importante porque os mantenedores precisam de uma forma repetível de distinguir uma vulnerabilidade real de uma saída de modelo que apenas parece plausível. Um reprodutor concreto permite que um engenheiro execute o código relevante e observe se o comportamento relatado de fato ocorre.

Um patch candidato pode encurtar a próxima etapa. Ele não elimina a necessidade de revisão, testes, verificações de compatibilidade e coordenação com sistemas dependentes. Correções de segurança às vezes alteram comportamentos dos quais usuários ou softwares dependentes dependem silenciosamente.

A Anthropic testou o pipeline com dezenas de projetos de código aberto antes de disponibilizar a inscrição de forma mais ampla. Segundo a empresa, essas varreduras iniciais produziram centenas de relatórios. A Anthropic diz que várias descobertas poderiam ser combinadas em explorações de execução remota de código sem autenticação.

Essa é uma categoria séria de vulnerabilidade porque um invasor pode potencialmente executar código sem primeiro fazer login no sistema afetado. No entanto, a Anthropic não publicou uma avaliação independente completa desses resultados iniciais.

O lançamento amplia um trabalho que a Anthropic anteriormente conduzia por meio de um programa coordenado de divulgação de vulnerabilidades. Nesse processo, pesquisadores de segurança revisavam as descobertas antes de notificar os mantenedores. A divulgação pública geralmente seguia um cronograma definido.

O OSS Scanner cria uma via rápida separada. Suas descobertas automatizadas são enviadas privadamente por e-mail aos mantenedores, e a Anthropic afirma que não as publicará automaticamente segundo seu prazo padrão de divulgação.

Se a Anthropic validar posteriormente uma descoberta por meio de seu programa com revisão humana, esse relatório poderá entrar no processo de divulgação já existente da empresa. Até lá, o relatório automatizado permanece uma submissão privada não verificada.

A distinção é essencial. A Anthropic não está oferecendo uma certificação de que o software inscrito é seguro. Está oferecendo outra fonte de hipóteses de vulnerabilidade, apoiadas por evidências reproduzíveis quando o sistema tem êxito.

Os números explicam por que a Anthropic mudou seu processo

O serviço existe porque os modelos da Anthropic conseguem gerar descobertas candidatas muito mais rápido do que seus pesquisadores conseguem validá-las.

A Anthropic afirma ter descoberto mais de 29.000 vulnerabilidades candidatas ao examinar projetos de software importantes nos seis meses anteriores. Seus pesquisadores revisaram manualmente aproximadamente 6.000 relatórios nesse período.

Isso deixa mais de 23.000 descobertas candidatas fora do processo concluído de revisão humana. Algumas representarão problemas reais de segurança. Outras serão duplicatas, mal-entendidos, defeitos de baixo impacto ou conclusões incorretas do modelo.

A Anthropic também afirma que os mantenedores solicitaram cada vez mais acesso em massa à sua saída não verificada. A empresa relata ter enviado quase 5.000 descobertas não validadas a projetos que pediram para receber tudo o que estivesse disponível.

Esses números explicam a lógica operacional por trás do Anthropic OSS Scanner. Continuar a exigir revisão manual limitaria o número de repositórios que a Anthropic poderia cobrir. Remover essa exigência aumenta ao mesmo tempo a cobertura, a frequência e a incerteza.

A empresa relaciona essa mudança à melhoria do desempenho dos modelos. A Anthropic afirma que os modelos de linguagem encontraram menos de 20% das vulnerabilidades no benchmark CyberGym no início de 2025. Diz que o resultado superou 85% durante 2026.

Um benchmark é um conjunto de testes padronizado, não uma garantia de desempenho em campo. Repositórios reais contêm sistemas de compilação incomuns, pressupostos não documentados, código gerado e fronteiras de segurança específicas de cada projeto.

Um modelo também pode identificar um defeito genuíno de software sem julgar corretamente seu impacto na segurança. Uma leitura fora dos limites em um utilitário de teste inacessível apresenta um risco diferente de uma exposta por meio de um serviço de rede.

Os próprios números da Anthropic revelam uma segunda limitação. Encontrar problemas candidatos já não é o único recurso escasso. Verificação, priorização, remediação e divulgação estão se tornando as partes mais difíceis do fluxo de trabalho.

Essa transição cria pressão para projetos sem equipes de segurança dedicadas. Uma importante biblioteca de infraestrutura pode depender de um pequeno grupo de mantenedores que já lidam com solicitações de recursos, regressões, problemas de empacotamento e suporte à comunidade.

Mesmo um relatório bem estruturado consome atenção. Alguém precisa reproduzir o comportamento, confirmar as versões afetadas, avaliar a explorabilidade, projetar uma correção segura e coordenar lançamentos.

Há muito tempo, equipes de segurança usam análise estática, fuzzing e varredura de dependências para identificar comportamentos suspeitos. O fuzzing fornece entradas inesperadas ao software para expor falhas ou outros erros.

A varredura de vulnerabilidades por IA adiciona uma camada de raciocínio. Um modelo pode examinar relações entre funções, inferir o comportamento pretendido, inspecionar o histórico de versões e construir um teste direcionado.

A Anthropic afirma que seus modelos às vezes seguiram novos caminhos de investigação depois que técnicas convencionais não encontraram nada. Pesquisas anteriores incluíram examinar o histórico de controle de versão e escrever programas de prova de conceito para vulnerabilidades suspeitas.

Esse raciocínio mais amplo pode encontrar defeitos que ferramentas baseadas em padrões deixam passar. Também pode produzir uma narrativa persuasiva, porém equivocada. Portanto, a qualidade das evidências que acompanham o relatório importa mais do que a fluência da explicação.

Mantenedores de código aberto se tornam a camada final de verificação

O serviço gratuito da Anthropic transfere a computação cara dos modelos para longe dos mantenedores, mas não elimina o custo humano da triagem de segurança.

Os mantenedores principais precisam aderir por meio do repositório de inscrição do projeto. Eles enviam um pull request contendo detalhes de configuração e instruções para compilar o software.

Cada projeto fornece um endereço de repositório, um contato principal de segurança e um Dockerfile. Um Dockerfile descreve o ambiente e os comandos necessários para compilar o projeto dentro de um contêiner.

Os projetos também podem fornecer um modelo de ameaças. Esse documento explica quais ativos importam, onde entram dados não confiáveis e como os mantenedores classificam a gravidade.

Esse contexto pode evitar mal-entendidos óbvios. Caso contrário, um scanner poderia tratar um comportamento deliberado como vulnerabilidade ou exagerar a importância de código que nunca manipula entradas não confiáveis.

A Anthropic compila os projetos participantes dentro de máquinas virtuais isoladas. A configuração pode usar acesso à rede para obter dependências necessárias. A análise de segurança em si é executada sem acesso à internet, dentro de sandboxes reforçados.

As descobertas são então enviadas por e-mail aos contatos designados pelo projeto. Os mantenedores podem solicitar entrega criptografada publicando uma chave OpenPGP com sua configuração de inscrição.

O serviço é limitado a projetos de código aberto qualificados. A Anthropic afirma que a elegibilidade se assemelha aos critérios usados pelo programa OSS-Fuzz do Google. Os projetos devem ter impacto crítico sobre infraestrutura ou segurança dos usuários.

Esse padrão torna o OSS Scanner diferente de uma ferramenta pública que qualquer pessoa pode apontar para qualquer repositório. A Anthropic controla as inscrições e cobre o custo de computação dos modelos para projetos aceitos.

A empresa também aplica métodos de varredura mais experimentais e intensivos em tokens do que os usados em seu produto geral de segurança comercial. Essa escolha posiciona o serviço de código aberto como um campo de testes para auditorias mais profundas.

Os mantenedores mantêm o controle após a inscrição. Eles podem editar sua configuração, atualizar instruções de compilação, pausar a varredura ou retirar o projeto por meio de outro pull request.

Também decidem o que fazer com cada descoberta. A Anthropic não cria automaticamente uma issue pública, não atribui um identificador de vulnerabilidade nem impõe um prazo de divulgação à saída automatizada bruta.

Essa abordagem reduz a chance de que um relatório incorreto acuse publicamente um projeto de distribuir uma falha explorável. Também evita expor detalhes técnicos antes que os mantenedores tenham avaliado um patch.

Ainda assim, a entrega privada não resolve as limitações de capacidade. Um projeto pequeno pode continuar recebendo mais relatórios confiáveis do que seus voluntários conseguem processar. A Anthropic não anunciou um limite universal para o volume de relatórios.

Os projetos precisarão de suas próprias regras de triagem. Um fluxo de trabalho prático deve separar problemas reproduzíveis e acessíveis externamente de falhas que exigem condições irrealistas.

As equipes também precisam de registros técnicos duradouros. Uma base de conhecimento de engenharia pesquisável pode preservar etapas de reprodução, versões afetadas, decisões sobre patches e tarefas de acompanhamento.

Essa documentação se torna importante quando vários relatórios compartilham uma causa-raiz. Sem ela, diferentes mantenedores podem repetir a mesma investigação ou aplicar correções inconsistentes entre ramificações.

A varredura de vulnerabilidades por IA agora enfrenta um teste de precisão

A questão central já não é se um modelo de IA consegue encontrar vulnerabilidades, mas se consegue entregar sinal verificado suficiente para justificar a atenção dos mantenedores.

A evidência inicial mais forte da Anthropic vem de projetos que testaram o sistema. O colaborador do PostgreSQL Noah Misch disse que vários relatórios identificaram defeitos e incluíram correções que estavam quase prontas para uso.

Anton Arapov, da OpenSSL Corporation, comparou favoravelmente o resultado bruto aos relatórios humanos. Ele enfatizou o valor de receber um exploit funcional, pois os engenheiros podem testá-lo diretamente.

O resultado mais específico divulgado veio da wolfSSL. O projeto recebeu 74 descobertas e considerou todas, exceto duas, válidas, segundo feedback publicado pela Anthropic. Cinco descobertas se tornaram registros de Common Vulnerabilities and Exposures, normalmente chamados de CVEs.

Esse resultado sugere alta precisão em uma implantação inicial. Ele não estabelece a mesma taxa entre linguagens de programação, tipos de projeto, configurações de compilação e modelos de ameaça.

A amostra também vem do próprio material de lançamento da Anthropic. A empresa não divulgou um conjunto de dados completo mostrando todos os relatórios aceitos, rejeitados, duplicados e contestados em seu piloto.

Uma avaliação independente exigirá mais do que contar relatórios. Pesquisadores devem examinar validade, gravidade, duplicação, tempo para reproduzir, tempo para corrigir e o número de regressões causadas pelas correções sugeridas.

O esforço dos mantenedores é outra métrica importante. Um scanner que encontra mais defeitos reais ainda pode criar uma carga líquida se cada relatório válido chegar em meio a muitos falsos positivos convincentes.

Esse risco não é teórico. Outras comunidades de código aberto já enfrentaram uma onda de envios automatizados de vulnerabilidades sem evidências adequadas.

O Google afirmou que pausou parte de seu Open Source Software Vulnerability Rewards Program após um aumento substancial de relatórios automatizados. Segundo a explicação da empresa, a maioria desses envios era inválida.

O projeto curl encerrou seu programa de recompensas por bugs em janeiro de 2026. Seus mantenedores haviam alertado repetidamente que relatórios gerados por IA estavam consumindo tempo sem oferecer valor de segurança correspondente.

Mantenedores do Linux também descreveram relatórios automatizados duplicados como difíceis de administrar. Várias pessoas podem executar ferramentas semelhantes, encontrar o mesmo padrão questionável e enviar, de forma independente, contribuições quase idênticas.

O modelo de adesão voluntária da Anthropic resolve parte desse problema. Apenas mantenedores autorizados inscrevem um projeto, e os relatórios vão diretamente para contatos designados. Não há recompensa financeira incentivando pessoas externas a maximizar o volume de envios.

O reprodutor obrigatório também eleva o padrão de evidência. Um relatório que mostra comportamento observável é mais útil do que outro que apenas classifica um padrão de código como perigoso.

Ainda assim, um reprodutor pode demonstrar uma falha sem comprovar um caminho de ataque relevante. Ele também pode depender de uma opção de compilação artificial ou de uma configuração que usuários reais nunca adotam.

Patches candidatos apresentam outra fonte de incerteza. Um patch pode silenciar um teste enquanto deixa a vulnerabilidade subjacente intacta. Também pode introduzir outro bug ou quebrar a compatibilidade em sistemas posteriores.

Os resultados iniciais justificam atenção cuidadosa, não confiança automática. O Anthropic OSS Scanner precisa provar que seus resultados continuam úteis após a expansão da adesão para além de projetos-piloto cooperativos.

O OSS Scanner complementa as ferramentas de segurança existentes

A Anthropic posiciona seu scanner como um sistema adicional de descoberta, não como substituto para fuzzers, bancos de dados de dependências, revisão de código ou divulgação coordenada.

A comparação histórica mais clara é o serviço OSS-Fuzz do Google, que testa continuamente importantes projetos de código aberto com infraestrutura de fuzzing.

O OSS-Fuzz é eficaz quando as ferramentas conseguem gerar entradas que exercitam comportamentos relevantes do programa. Ele é especialmente útil para softwares que analisam arquivos, mensagens de rede ou outros dados não confiáveis.

No entanto, o fuzzing depende de harnesses de teste e falhas observáveis. Alguns erros de autorização, falhas de lógica de negócios e caminhos de ataque em múltiplas etapas não produzem uma falha imediata.

Modelos de linguagem de grande porte podem raciocinar sobre essas relações. Eles podem rastrear dados por diferentes componentes, considerar o modelo de segurança declarado de um projeto e gerar experimentos direcionados.

A análise estática tradicional oferece outra comparação. Ela examina o código-fonte sem executar o programa completo e aplica regras que identificam fluxos ou padrões arriscados.

Analisadores estáticos são reproduzíveis e podem ser executados a cada alteração no software. Sua utilidade depende da qualidade das regras, do suporte à linguagem e da capacidade de uma equipe de lidar com alertas recorrentes.

A análise de composição de software se concentra em pacotes incluídos e vulnerabilidades conhecidas. Ela pode informar a uma equipe que uma dependência corresponde a uma versão afetada, mas geralmente não descobre um defeito desconhecido anteriormente.

O serviço da Anthropic tem como alvo vulnerabilidades desconhecidas dentro do código-fonte. Seus modelos não se limitam a comparar um repositório com um catálogo de vulnerabilidades existente.

A revisão humana continua necessária em todas essas abordagens. Engenheiros de segurança entendem o contexto de implantação, os incentivos dos atacantes, os requisitos de compatibilidade e consequências que vão além do ambiente de teste imediato de um scanner.

As ferramentas também podem se reforçar mutuamente. Uma hipótese gerada por IA pode se tornar um alvo de fuzzing. A falha encontrada por um fuzzer pode fornecer a um modelo evidências concretas para a análise da causa raiz.

Um modelo pode propor um patch, enquanto a análise estática e os testes de regressão examinam a alteração em busca de novos problemas. A análise de dependências pode então identificar produtos posteriores que precisam de uma versão atualizada.

A política de divulgação padrão da Anthropic continua relevante quando seus pesquisadores validam um problema. Em geral, essa política prevê notificação seguida de divulgação após 90 dias ou assim que um patch for lançado.

A política permite prazos mais curtos para vulnerabilidades críticas exploradas ativamente. Ela também descreve extensões para mantenedores que estejam avançando rumo a uma correção.

Os relatórios brutos do OSS Scanner ficam fora desse cronograma automático. A Anthropic afirma que não os publicará, a menos que posteriormente entrem em um processo de revisão humana.

Essa separação dá aos mantenedores espaço para investigar. Também cria uma questão de governança ainda sem resposta sobre descobertas que permanecem sem solução por longos períodos.

A Anthropic afirma que poderá eventualmente introduzir períodos de divulgação para algumas descobertas automatizadas de alta gravidade. A empresa promete aviso prévio e uma opção para que projetos deixem o serviço caso essa política mude.

Por enquanto, a oferta favorece o acesso defensivo privado em vez da responsabilização pública. Essa é uma posição de lançamento razoável, mas depende fortemente de os mantenedores participantes responderem de forma responsável.

O que determinará se o serviço funciona

Três sinais mostrarão se o Anthropic OSS Scanner se tornará uma infraestrutura de segurança útil ou mais uma fonte exigente de relatórios automatizados.

O primeiro sinal é a experiência de projetos recém-inscritos. O feedback do piloto da Anthropic veio de equipes estabelecidas, com forte expertise técnica e processos de segurança maduros.

Uma adesão mais ampla testará o scanner em diferentes linguagens, arquiteturas e modelos de manutenção. Os resultados devem revelar se sua precisão inicial se transfere para além de um grupo selecionado.

Correções documentadas publicamente fornecerão evidências úteis. Referências a commits, registros de CVE e retrospectivas dos mantenedores podem mostrar quais relatórios produziram melhorias significativas de segurança.

A atribuição é opcional, mas a Anthropic incentiva os projetos a incluir um identificador de relatório do scanner nos commits relevantes. Esses identificadores podem ajudar a empresa a medir quais descobertas levaram a patches.

O segundo sinal é a qualidade dos relatórios ao longo do tempo. A Anthropic deverá eventualmente publicar dados agregados sobre precisão, duplicação, gravidade e correção, sem expor vulnerabilidades não resolvidas.

A medida mais informativa não será o número total de descobertas candidatas. Será a proporção que os mantenedores conseguem reproduzir, aceitar e corrigir sem investigação excessiva.

Uma redução na taxa de falsos positivos fortaleceria o argumento da Anthropic de que os modelos de linguagem ultrapassaram um importante limiar de utilidade. O aumento dos custos de triagem o enfraqueceria.

O terceiro sinal é como outros programas de segurança reagirão. O Google planeja revisar seu processo pausado de recompensas para código aberto depois de lidar com envios automatizados inválidos.

Uma implantação bem-sucedida da Anthropic poderia influenciar os padrões de evidência usados por programas de recompensas por bugs e de divulgação. Reprodutores e patches testáveis poderiam passar a ser esperados para qualquer relatório gerado por máquina.

Uma implantação ruim poderia incentivar filtros mais rigorosos. Mantenedores poderiam rejeitar descobertas automatizadas por padrão, a menos que uma organização reconhecida realizasse validação humana.

A Anthropic também precisa observar a adaptação dos atacantes. As mesmas capacidades dos modelos que localizam descobertas defensivas podem ajudar pesquisadores maliciosos a investigar softwares amplamente implantados.

A empresa afirma aplicar controles de acesso e monitoramento em torno de capacidades cibernéticas avançadas. O OSS Scanner limita ainda mais a exposição ao operar em ambientes isolados e entregar as descobertas de forma privada.

Essas medidas não podem eliminar a corrida mais ampla. Os modelos continuarão melhorando, e capacidades semelhantes se espalharão entre provedores, empresas de segurança e sistemas locais.

Isso torna a velocidade de correção cada vez mais importante. Encontrar uma vulnerabilidade primeiro oferece pouca proteção se um projeto não consegue reproduzir, corrigir, testar e distribuir a correção antes que atacantes a explorem.

Mantenedores de código aberto devem avaliar o serviço como uma entrada adicional de segurança, não como um veredito sobre seu código. Projetos elegíveis podem revisar os requisitos de inscrição e decidir se possuem capacidade de triagem suficiente.

A melhor pergunta não é se um scanner de IA ocasionalmente comete erros. Toda técnica de segurança tem limites. A questão é se os relatórios da Anthropic economizam mais tempo de engenharia do que consomem.

O Anthropic OSS Scanner agora precisa estabelecer esse equilíbrio publicamente. Os resultados dos mantenedores nos próximos meses importarão mais do que o volume de vulnerabilidades que seus modelos afirmam encontrar.