Passa nos testes, não é seguro

O que é e porque importa

Quando o Claude Code acaba um trabalho e te diz «feito, testes passados», parece o fim da história. Não é. Os testes verdes dizem-te uma coisa só: o código faz o que os testes verificam. E os testes verificam o que foi pedido. Se pediste «deixa-me guardar uma encomenda», o teste verifica que a encomenda fica guardada. Ninguém perguntou o que acontece se alguém a guarda sem login, ou em nome de outro utilizador.

Por isso «passa nos testes» não quer dizer «é seguro». Uma app pode passar em todos os testes e, entretanto, deixar um utilizador ler os dados de outro, aceitar duas vezes o mesmo pagamento ou deixar uma chave secreta na parte que corre no browser, onde qualquer pessoa a pode ler.

Di-lo também um estudo publicado no arXiv a 10 de outubro de 2026, «Last Secure Code Benchmark: Is the Code You Vibe Secure?». Pôs à prova seis dos agentes de programação mais avançados. O código deles passa nos testes de funcionamento em 73,6% a 91,3% das tarefas, conforme o agente. Mas até o melhor dos seis só escreve código que funciona e é seguro em 25,1% das tarefas.

Pedir à mesma sessão que volte a verificar serve de pouco: acabou de escrever aquele código e sabe porque o fez assim. O que eu faço é abrir uma segunda sessão e dar-lhe um papel preciso, o de atacante. Não sabe nada de como nasceu o código, só vê as alterações e tem uma tarefa: descobrir como as partir. Não lhe pergunto se está bem. Pergunto-lhe onde cede.

Porque importa: se constróis uma app sem seres programador, estes buracos não os vês a reler o código. E se ninguém os procurar, o primeiro a encontrá-los é um utilizador.

1. O prompt do atacante

Colo-o tal como está na segunda sessão, quando a primeira acabou e os testes estão verdes.

És um atacante, não um revisor simpático. Este código passa nos testes: não me interessa, os testes só verificam o que foi pedido. A tua tarefa é uma só: descobre como partir o que acabou de ser feito. Olha só para as alterações: corre git status e git diff HEAD (mostra também as que já estão em stage), e lê por inteiro os ficheiros novos que o git status lista (o diff não os mostra). Procura:
- quem a pode chamar: o que acontece sem login, com o login de outro utilizador, chamando o endereço diretamente;
- dados errados: campos vazios, textos compridíssimos, caracteres estranhos, números negativos, tipos errados, o mesmo pedido enviado duas vezes;
- chaves à vista: palavras-passe, tokens ou chaves secretas escritas no código, nos logs, nas mensagens de erro ou na parte que corre no browser;
- permissões: quem pode ler, alterar ou apagar dados que não são seus;
- casos limite: listas vazias, rede lenta, dois utilizadores ao mesmo tempo.
Para cada problema escreve: onde (ficheiro e linha), como o parto (os passos exatos), o que acontece, gravidade (alta, média, baixa). Ordena do mais grave. Não corrijas nada e não alteres os ficheiros: só quero o relatório.

Porque está escrito assim, linha a linha.

• «És um atacante, não um revisor simpático»: um revisor simpático tenta perceber o código e no fim tende a dá-lo por bom. Um atacante parte da ideia de que há um buraco e vai procurá-lo.
• «Corre git status e git diff HEAD»: o git diff sozinho só mostra as alterações que ainda não estão em stage, ou seja, ainda não marcadas com git add para o próximo commit. O git diff HEAD compara-as todas com o último commit, marcadas ou não. Os ficheiros que o git ainda não acompanha, porém, também não aparecem lá: o git status lista-os, e por isso o revisor lê-os por inteiro.
• «Quem a pode chamar»: uma página pode esconder um botão a quem não tem permissão, mas se o endereço que esse botão chama responde a qualquer pessoa, o botão escondido não protege nada. Por isso o prompt pede para chamar o endereço diretamente.
• «Como o parto (os passos exatos)»: com os passos podes verificar tu se o problema existe mesmo e, depois da correção, repeti-los para ver se desapareceu. Um «pode haver um risco» não o consegues verificar.
• «Não corrijas nada e não alteres os ficheiros»: quem ataca assinala e mais nada. As correções faz-as a sessão que escreveu o código, assim sabes sempre quem mudou o quê.

2. Como o uso

1. A primeira sessão diz «feito, testes passados». Não lhe peço que se volte a verificar.
2. Abro um terminal novo na mesma pasta e lanço claude: uma sessão nova, que não viu a conversa.
3. Colo o prompt antes do commit, para que git status e git diff HEAD mostrem só o trabalho acabado de fazer. Se já fiz o commit, indico-lhe eu os ficheiros.
4. Levo o relatório à primeira sessão e mando corrigir a começar pela gravidade alta. Para cada problema sério peço também um teste que o reproduza, assim da próxima vez é o teste que o verifica.

Do relatório às correções

À primeira sessão passo o relatório com este prompt:

Aqui está o relatório de outra sessão que tentou partir o teu trabalho: [cola o relatório]. Começa pelos problemas de gravidade alta, um de cada vez. Para cada um, primeiro escreve um teste que o reproduza e verifica que falha, depois corrige e verifica que o teste passa. Diz-me o que mudaste e como o verificaste. Os de gravidade baixa não lhes mexas: decido eu.

O teste que falha antes da correção é a parte que conta. Diz-te que o problema existia mesmo e não era uma ideia do revisor. E fica no projeto: se uma alteração futura voltar a abrir o mesmo buraco, esse teste fica vermelho.

Se queres ter a certeza de que não mexe em nada

No prompt está escrito para não alterar os ficheiros, mas continua a ser um pedido. Se quero um bloqueio a sério, abro a segunda sessão em plan mode:

claude --permission-mode plan

Em plan mode o Claude lê os ficheiros e corre comandos para explorar, tipo git status e git diff HEAD, mas não altera o código enquanto não aprovares um plano. Se no fim te propuser um com correções, não o aproves: o relatório chega. Numa sessão já aberta entras carregando em Shift+Tab até aparecer «plan mode on» em baixo.

3. Não expliques nada

Ao revisor não explico porque o código está feito assim. Se lho explicas, acaba por te dar razão.

Vale para cada frase que acrescentas ao prompt: «fiz assim porque…», «essa parte é provisória», «o login já é tratado por outra parte da app». São frases que põem o revisor do teu lado antes mesmo de olhar para o código. Dá-lhe as alterações e a tarefa, mais nada. As explicações servem-te depois, quando decides o que corrigir.

Os erros mais comuns

• Ler «testes passados» como «seguro»: os testes verificam o que foi pedido, por isso quando mexes em login, permissões ou dados faz sempre uma ronda com o atacante.
• Pedir à mesma sessão que ataque o próprio código: abre um terminal novo e lança claude, para que quem ataca não seja quem o escreveu.
• Lançá-lo depois do commit sem dizer que ficheiros: o git diff HEAD já não mostra o trabalho acabado de fazer, por isso indica-lhe tu os ficheiros a ver.
• Explicar ao atacante porque o código está feito assim: dá-lhe só as alterações e a tarefa, senão acaba por te dar razão.
• Corrigir sem um teste: para cada problema sério manda escrever primeiro um teste que o reproduza, assim se voltar dás por isso.
• Corrigir tudo o que encontra: começa pela gravidade alta e sobre as baixas decide tu, senão o código enche-se de defesas inúteis.

Checklist

• Os testes estão verdes e a primeira sessão acabou
• O atacante está numa sessão nova
• Nenhuma explicação acrescentada ao prompt
• Antes do commit, ou com os ficheiros indicados
• Cada problema tem ficheiro e linha, passos, efeito e gravidade
• Cada problema de gravidade alta está corrigido e tem o seu teste

Perguntas frequentes