Claude gera provas verificadas por máquina para 239 pontos de entrada de fuzz tests em 123 bibliotecas open-source
Aprofundamento CEVIU
Aprofundamento
A Anthropic, em colaboração com a Theorem, usou o Claude para provar propriedades de segurança diretamente sobre código de montagem RISC-V em mais de 100 bibliotecas open-source. O ponto de partida foram fuzz tests do OSS-Fuzz do Google. Cada teste virou uma especificação do tipo "este teste nunca quebra para nenhuma entrada menor que 64 MB", escrita sobre as instruções RISC-V compiladas. Se o Claude prova a especificação, o fuzzing daquele ponto de entrada nunca vai achar bug.
Os números: 239 pontos de entrada em 123 bibliotecas, em poucas semanas, com cerca de 180 milhões de linhas de Rocq. Uma prova típica tem uns 600.000 linhas e cobre binários com mediana de 18.000 instruções RISC-V. As garantias valem sob premissas claras: binário estático, single-threaded, orçamento fixo de memória, CPU RISC-V e Linux. Quem precisa confiar em três coisas: os modelos formais de RISC-V e de processos Linux, os enunciados exatos dos teoremas e o verificador de provas Rocq. Isso não significa que as bibliotecas não tenham bugs, e sim que eventuais falhas estão nesses componentes ou fora do escopo da prova.
O que mudou
Em 11 de julho de 2026, o CEVIU noticiou "Verificação Formal e o Papel da IA: Avanços e Desafios para a Segurança do Software", que já apontava o custo historicamente inviável da verificação formal e o papel dos LLMs. Agora o assunto saiu do argumento geral e virou entrega medida: provas em escala sobre bibliotecas reais, com número de pontos de entrada, volume de proof code e publicação de parte dos artefatos.
Por que isso importa
Para quem mantém uma biblioteca em C ou C++ com fuzz tests, a leitura é que o teste que você já escreveu pode virar a especificação de uma prova. O custo de entrada, historicamente de anos de especialistas, parece cair. Mas as premissas (64 MB, single-threaded, memória fixa) mostram que é garantia de propriedades específicas, não de correção total. E o simples ato de tentar a prova já rendeu bugs que fuzzers dificilmente achariam.
Linha do tempo
CEVIU noticia os avanços e desafios da verificação formal com IA para a segurança do software.
Claude gera provas verificadas por máquina para 239 pontos de entrada de fuzz tests em 123 bibliotecas open-source.
Perguntas frequentes
O que o Claude provou exatamente nessas bibliotecas?
Provou que os programas sempre terminam normalmente, sem erros de segurança de memória e sem falhar asserts, para toda entrada abaixo de 64 MB. Isso vale para qualquer resposta modelada do sistema operacional e qualquer layout de memória. A prova foi feita sobre o código RISC-V compilado.
Isso significa que essas bibliotecas não têm mais bugs?
Não. Os bugs restantes podem estar nos modelos formais de RISC-V e de Linux, nos enunciados dos teoremas ou no verificador Rocq. Também podem estar fora do escopo da prova, como programas multi-thread ou entradas maiores que 64 MB.
Por que começar por fuzz tests?
Porque o desenvolvedor já definiu ali o que conta como falha: qualquer entrada que cause crash é um bug. Isso resolve o problema de escrever uma especificação do zero. Além disso, o OSS-Fuzz instrumenta C e C++ com AddressSanitizer, que derruba o programa em acessos inválidos de memória.
Posso usar isso nos meus projetos?
A Theorem oferece rodar o mesmo pipeline para outros projetos open-source e publica uma skill do Claude para quem quer começar a verificar o próprio código. Parte das provas e dos modelos também foi publicada para verificação independente.
Fontes
- anthropic.comfonte original
- Categoria
- CEVIU Web Dev
- Publicado
- 23 de outubro de 2026
- Editoria
- CEVIU Web Dev

