Voltar
LLMs estão tornando viável a verificação formal de software em escala muito maior

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

  1. CEVIU noticia os avanços e desafios da verificação formal com IA para a segurança do software.

  2. 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

Avalie este artigo:
Categoria
CEVIU Web Dev
Publicado
23 de outubro de 2026
Editoria
CEVIU Web Dev

Quer receber mais sobre CEVIU Web Dev?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser