Análise aprofundada · Cerca de 8 min de leitura
O estudo de provas de Claude em 123 bibliotecas delimita as garantias do software, sem torná-las universais
Anthropic e Theorem relatam provas para 239 pontos de entrada de fuzzing em 123 bibliotecas, com hipóteses explícitas sobre a máquina e limites para o que os resultados demonstram.
- Publicado aqui
- Data da fonte
- Fonte verificada
Em um artigo de pesquisa de 22 de outubro, a Anthropic descreve o trabalho com a Theorem que usa Claude para gerar provas de software verificadas por máquina. O resultado útil é uma garantia sobre programas executáveis selecionados sob um modelo definido, e não um certificado de que uma biblioteca inteira ou qualquer implantação seja segura.
Ouça as notícias
Ouça este artigo ou continue ouvindo as notícias.
Preparando a leitura…
Voz do dispositivo
O navegador ou dispositivo processa a voz. O AISubHub não envia o texto a uma API de áudio. As vozes e a reprodução com a tela bloqueada variam conforme o dispositivo.
Ao continuar, uma frase curta pode se repetir.
Resumo
- Os pesquisadores relatam provas de ausência de falhas que causem encerramento anormal para 239 pontos de entrada de 123 bibliotecas do OSS-Fuzz, após corrigir os problemas encontrados quando necessário, para entradas inferiores a 64 MB e sob as hipóteses declaradas.
- O experimento principal trata de programas RISC-V de uma única thread, vinculados estaticamente à musl, e do comportamento modelado do Linux. Ele não abrange automaticamente implantações comuns em x86 ou ARM.
- Experimentos separados com tarefas pequenas comparam os requisitos de tokens dos modelos e o compartilhamento de provas. As economias relatadas são específicas desses experimentos, não uma garantia geral de preço ou desempenho.
Uma prova abrange um ponto de entrada em uma máquina definida
A unidade de cobertura importa. Um ponto de entrada do OSS-Fuzz é uma maneira fornecida pelo desenvolvedor para inserir dados em um programa e sinalizar falhas. A Anthropic relata ter concluído, ao longo de várias semanas, provas para 239 desses pontos de entrada em 123 bibliotecas. Isso não significa 239 bibliotecas inteiramente verificadas, nem todas as rotas possíveis nas 123 bibliotecas. O projeto produziu cerca de 180 milhões de linhas de código de prova em Rocq; uma prova típica tinha aproximadamente 600.000 linhas, enquanto os binários apresentavam uma mediana de 18.000 instruções RISC-V.
A afirmação é delimitada pela execução modelada: entradas menores que 64 MB, um orçamento fixo de memória, uma única thread, um executável RISC-V estático vinculado à musl e determinadas respostas do Linux e disposições de memória. Essas condições definem o enunciado matemático. Na leitura do AISubHub, o denominador da cobertura e a configuração de compilação são mais úteis para avaliar o resultado do que apenas o impressionante total de linhas de prova.
O fuzzing se transforma em uma afirmação verificada por um pequeno núcleo
O fuzzing experimenta muitas entradas geradas e pode descobrir um contraexemplo, mas passar nesses testes não esgota o espaço de entradas. Neste trabalho, os pesquisadores transformam um teste de fuzzing existente e seu executável compilado em uma especificação formal. Claude constrói um argumento de que o teste selecionado não pode sofrer um encerramento anormal para nenhuma entrada permitida. As asserções já presentes em um teste também podem codificar propriedades relevantes, como recuperar os dados originais após compactá-los e descompactá-los.
O modelo não pode declarar sua própria prova correta. O Rocq confere a prova em relação ao enunciado. A confiança, portanto, se desloca para o enunciado exato, a semântica de RISC-V e Linux e o verificador, incluindo o hardware e o software subjacentes. Esse é um alvo de revisão menor do que ler milhões de linhas geradas, mas continua sendo uma dependência real. Uma prova válida não pode estabelecer que um modelo de máquina impreciso descreva fielmente um sistema em produção.
Por que uma tentativa de prova malsucedida ainda pode gerar uma correção útil
Segundo os pesquisadores, as tentativas de prova expuseram problemas, entre eles uma falha em um descompactador que exigia uma entrada de cerca de 20 MB com uma disposição incomum e uma falha em um decodificador de imagens que exigia uma entrada de 64 MB e mais de 2 GB de memória. Esses exemplos explicam por que uma busca dominada por entradas pequenas pode deixar de encontrar comportamentos relevantes. São descobertas relatadas pela fonte, não vulnerabilidades reproduzidas de forma independente pelo AISubHub.
O processo podia corrigir um programa, regenerar sua especificação e então provar o artefato corrigido. Uma prova desse novo artefato não deve ser apresentada como prova da versão original sem modificações. Também existe o risco de um atalho: um agente poderia remover comportamentos úteis para facilitar um enunciado de ausência de falhas. Os autores descrevem penalidades para patches, incentivos para caracterizar as entradas cujo comportamento muda e auditoria dos patches. Essas salvaguardas tratam de um modo de falha; não eliminam a necessidade de verificar se uma correção preserva o comportamento pretendido.
A economia de tokens vem de dois experimentos diferentes
Para um conjunto separado de 36 tarefas pequenas de verificação, o artigo afirma que Opus 5.5 prova metade delas com cerca de 40% menos tokens que Opus 5. Cada tarefa recebeu três tentativas independentes de um único agente, com um orçamento de cinco milhões de tokens por tentativa, e o gráfico a contabilizava quando a primeira tentativa bem-sucedida terminava. Trata-se de uma comparação de um conjunto de tarefas e de um orçamento específicos. O artigo não identifica todos os modelos usados no trabalho maior com 123 bibliotecas; portanto, esse trabalho não deve ser inteiramente reclassificado como um resultado de Opus 5.5.
Um experimento com espaço de trabalho compartilhado permitiu que os agentes reutilizassem as provas uns dos outros e relatou 17% menos tokens que o trabalho isolado. Seu gráfico de 36 provas mostra menor uso de tokens em 30 das 34 comparações com tentativas individuais concluídas; agentes isolados não terminaram duas tarefas. Reutilizar provas de inicialização do ambiente de execução e do detector de erros de memória oferece um mecanismo concreto de economia. Nenhum dos percentuais fornece um custo universal em dólares, uma redução do tempo decorrido ou um benefício de implantação medido de forma independente.
Os outros casos medem diferentes tipos de correção
O artigo também descreve um experimento com zlib em relação a uma especificação derivada de um RFC, usando semântica de x86. É um caso separado, não uma evidência de que os resultados principais em RISC-V já se apliquem a todo software x86. Um interpretador em Rust para um subconjunto amplo de Python foi verificado com Verus em relação à semântica modelada de CPython e, depois, comparado empiricamente com CPython em mais de 1,7 milhão de programas gerados aleatoriamente.
Os 99,95% de comportamentos coincidentes relatados pertencem a essa comparação empírica. Não constituem uma prova de compatibilidade com qualquer programa Python. A distinção importa: uma prova estabelece um enunciado formal específico, enquanto um percentual de testes descreve um experimento com uma amostra. Combinar esses resultados em uma pontuação geral de precisão do modelo apagaria as diferenças entre especificações, ferramentas e casos-limite restantes.
O ganho de engenharia está em uma fronteira mais clara
Os autores deixam lacunas explícitas. O AddressSanitizer não detecta alguns erros de memória; o projeto não abrangeu todos os pontos de entrada; nem mesmo todos os pontos de entrada de fuzzing cobririam todo o comportamento de uma biblioteca ou seu código morto. Um programa chamador também pode usar a biblioteca incorretamente fora das hipóteses verificadas. Implantações comuns usam vinculação dinâmica, glibc, x86 ou ARM, que diferem do experimento principal. Algumas provas são retidas para evitar revelar problemas ainda sem correção, e o roteiro para um ecossistema mais amplo continua sendo uma proposta.
Análise do AISubHub: um próximo passo prático é relacionar uma compilação exata, um ponto de entrada de teste, um limite de entrada e um modelo de máquina confiável a cada garantia declarada, reavaliando-a quando esses elementos mudarem. Isso pode complementar testes e revisão, em vez de justificar sua remoção de todo um projeto. Lemos o artigo e suas figuras necessárias, mas não executamos novamente as provas, não auditamos o apêndice externo nem os repositórios publicados, não validamos a segurança dos patches nem reproduzimos a economia de tokens. Os resultados e as expectativas futuras continuam atribuídos aos pesquisadores.
Por que importa
Análise do AISubHub: provas geradas poderiam reduzir o custo de estabelecer e reutilizar uma propriedade de software delimitada e passível de revisão. O resultado útil é o artefato verificado e seu enunciado exatos, com suas hipóteses, e não uma afirmação geral de que a IA tornou o software livre de erros.
Limites e disponibilidade
Esta é uma análise do relato publicado pelos pesquisadores, não uma auditoria de segurança ou reprodução independente. Os limites de entrada, arquitetura, vinculação, memória e pontos de entrada do experimento principal continuam essenciais; o apêndice externo e o conteúdo dos repositórios não foram auditados.
Fontes e evidências
Data da fonte: · Fonte verificada:
Conteúdo editorial com apoio de IA, verificado em fontes primárias. Alegações dos fornecedores são atribuídas; inclusão não é recomendação.