"Revisão de segurança com Claude Code" costuma significar uma de três coisas: rodar o comando /security-review no terminal, adicionar a GitHub Action de revisão de segurança da Anthropic aos seus pull requests, ou simplesmente pedir ao Claude Code (ou a outro agente de IA) que audite um trecho de código. As três são úteis. Nenhuma é um programa de segurança completo, e as três enviam seu código para um provedor de modelos.

Neste guia você vai ver o que a Anthropic realmente oferece, no que essas revisões são boas e ruins, o que acontece com o seu código, os riscos específicos do código gerado por IA e um fluxo prático que combina a revisão de um agente de IA com um scanner dedicado e testes.

O que a Anthropic oferece para revisão de segurança

O comando /security-review

O Claude Code traz o comando /security-review. Você roda no terminal antes do commit e o Claude analisa suas mudanças pendentes em busca de problemas de segurança, com severidade e uma correção sugerida para cada achado. Segundo a central de ajuda da Anthropic, ele procura coisas como SQL injection, cross-site scripting, falhas de autenticação e autorização, tratamento inseguro de dados e vulnerabilidades em dependências, e está disponível para usuários do Claude Code em planos pagos individuais (Pro ou Max) e em contas de API Console com pagamento por uso.

O comando é definido como um prompt em Markdown. Se o padrão não encaixa no seu stack, você pode copiar o security-review.md do repositório da Anthropic para a pasta .claude/commands/ do seu projeto e editar, por exemplo para explicar quais são seus helpers de autorização ou para pular categorias que você já cobre com outra ferramenta.

A GitHub Action

A Anthropic publica uma action open source, anthropics/claude-code-security-review, que roda o mesmo tipo de análise em pull requests. Ela dispara em eventos pull_request, revisa o diff e publica os achados como comentários de review nas linhas afetadas. Os inputs principais são uma claude-api-key obrigatória, o modelo, exclude-directories, um timeout e um caminho para custom-security-scan-instructions. Ela também aplica um filtro de falsos positivos que, por padrão, descarta categorias como negação de serviço, rate limiting, esgotamento de recursos, validação de input genérica sem impacto comprovado e open redirects.

Um aviso do README merece atenção: a action não é endurecida contra ataques de prompt injection e só deve ser usada para revisar PRs confiáveis. A Anthropic recomenda ativar "Require approval for all external contributors" para que o workflow só rode depois que um maintainer olhar o PR. Em um repositório público, isso não é opcional.

Claude Code Security

Em fevereiro de 2026 a Anthropic anunciou o Claude Code Security, uma capacidade separada que escaneia codebases inteiras e sugere patches para revisão humana. Ele foi lançado como research preview limitado para clientes Enterprise e Team. A Anthropic descreve um processo em várias etapas no qual o Claude reexamina os próprios resultados para filtrar falsos positivos e atribui severidade e nível de confiança, e deixa claro que nada é aplicado sem aprovação humana. A empresa também relatou ter encontrado mais de 500 vulnerabilidades em codebases open source em produção usando o Claude Opus 4.6 durante sua pesquisa.

No que a revisão de segurança com IA é boa

  • Ela lê intenção, não só sintaxe. Um modelo percebe que um controller filtra as queries pelo usuário atual e o vizinho não, que é exatamente a cara de uma vulnerabilidade IDOR. Motores de regras têm dificuldade com isso.
  • Ela explica. Os achados vêm com a narrativa de como o bug é explorado e uma correção proposta, o que ajuda devs que não são especialistas em segurança.
  • É barata de rodar cedo. Um comando antes do commit pega problemas enquanto quem escreveu ainda tem todo o contexto na cabeça.
  • É flexível. Você pode orientá-la com instruções próprias sobre convenções do framework, bibliotecas internas ou seu modelo de ameaças.

Limites para levar em conta

  • Escopo e contexto. O comando e a action focam nas mudanças em revisão. Um diff pode parecer seguro enquanto o problema real está em um middleware, uma policy ou um helper fora do diff. As janelas de contexto são grandes, mas o modelo raciocina sobre o que recebe.
  • Não determinismo. Duas execuções sobre o mesmo código podem gerar achados diferentes. Para um revisor, tudo bem; para um gate de compliance que precisa ser repetível, é desconfortável.
  • Falsos positivos e falsos negativos. O filtro reduz o ruído, e categorias excluídas (como DoS ou open redirects) não são reportadas mesmo quando importam para você. Uma revisão limpa não prova que o código é seguro.
  • Prompt injection. Código, comentários, documentação e texto de issues são input para o modelo. Um PR malicioso pode tentar convencer o revisor a não reportar algo, e é por isso que a Anthropic limita a action a PRs confiáveis.
  • O que está fora do seu código. CVEs em dependências, segredos enterrados no histórico do git e configuração de cloud exigem dados e ferramentas que uma revisão de diff não substitui.

A própria orientação da Anthropic vai na mesma linha: revisões automáticas devem complementar, e não substituir, as práticas de segurança existentes e o code review manual.

O que acontece com o seu código

O Claude Code roda na sua máquina, mas para falar com o modelo envia prompts, contexto de código e respostas pela rede (TLS 1.2 ou superior). O que acontece depois depende da conta, segundo a documentação de uso de dados da Anthropic:

  • Contas comerciais (Team, Enterprise, API): retenção padrão de 30 dias, e a Anthropic não treina modelos com código ou prompts enviados sob termos comerciais, a menos que o cliente opte por isso.
  • Contas de consumidor (Free, Pro, Max): 30 dias de retenção se você não permitir o treinamento; 5 anos se permitir que seus dados sejam usados para melhorar modelos.
  • Zero data retention está disponível para contas Claude for Enterprise qualificadas, habilitado por organização.
  • Provedores cloud: o Claude Code também pode usar Amazon Bedrock, Google Cloud ou Microsoft Foundry, onde valem os controles desse provedor.

Para muitos times isso é perfeitamente aceitável. Vira um problema quando:

  • contratos ou NDAs com clientes limitam quais subprocessadores podem ver o código fonte;
  • o repositório é sua propriedade intelectual central (um motor de trading, um modelo próprio, um conjunto de regras de detecção);
  • uma regulação ou auditoria exige provar onde o código foi processado e por quanto tempo;
  • o repositório tem segredos ou dados regulados em fixtures, que viajam junto com o contexto.

A alternativa é um modelo hospedado por você, para que o código nunca saia de uma infraestrutura que você controla. Os prós e contras estão em IA self-hosted para segurança de código.

Riscos de segurança do código gerado por IA

Agentes de IA escrevem muito código rápido, e os bugs que introduzem não têm nada de exótico. São os clássicos, produzidos em ritmo maior e revisados com menos cuidado:

  • Autorização ausente. O endpoint funciona na demo, então ninguém percebe que ele carrega objetos por ID sem checar o dono. Broken access control lidera o OWASP Top 10 2025.
  • Injeção. SQL, comandos de shell e templates montados com strings continuam aparecendo, principalmente em scripts de admin "rápidos". Veja SQL injection.
  • Segredos no código. Chaves coladas em um arquivo de config para algo funcionar, e depois commitadas.
  • Dependências. Versões antigas vindas dos dados de treinamento do modelo, ou nomes de pacotes que não existem e que um atacante pode registrar (às vezes chamado de slopsquatting).
  • Padrões permissivos. CORS com curinga, modo debug ligado, tokens de CI amplos demais, containers rodando como root.
  • Permissões do agente. Um agente que executa comandos, lê a web e faz push de código é, ele mesmo, uma superfície de ataque se ler conteúdo não confiável.

Um fluxo prático: revisão com IA, scanner e testes

  1. Antes do commit: rode /security-review (ou o equivalente do seu agente) na mudança. Corrija o que é real e anote o que você não concorda.
  2. Em cada pull request: rode a action de revisão com IA em PRs confiáveis, mais checagens determinísticas de dependências e segredos. Um code review com IA dedicado ou um scanner que olhe o repositório inteiro pega o que uma revisão de diff não enxerga.
  3. Testes de autorização: para cada endpoint que recebe um ID, adicione um teste em que uma segunda conta tenta ler e alterar os dados da primeira. Testes são determinísticos; são eles que mantêm corrigido um bug corrigido.
  4. Scans periódicos do repositório completo para encontrar vulnerabilidades no código acumuladas em muitas mudanças pequenas, e um scanner de segurança de APIs para os seus endpoints.
  5. Revisão humana nas áreas de alto risco: auth, pagamentos, multi-tenancy, criptografia. Um code review seguro estruturado ainda vence qualquer ferramenta em lógica de negócio.
  6. Testes externos quando o que está em jogo justifica: um pentest ou pentest assistido por IA contra um ambiente rodando.

Onde a Nurbak entra

A Nurbak foi feita para a etapa que revisões de diff não cobrem: você conecta o GitHub e escaneia um repositório inteiro. A análise roda no próprio modelo de IA self-hosted da Nurbak, então não envia seu código para a OpenAI nem para a Anthropic. Ela reporta vulnerabilidades exploráveis, incluindo IDOR/BOLA e autorização ausente, com arquivo e linha, além de CVEs em dependências e segredos no histórico do git, com um score de 0 a 100 e explicações em linguagem simples.

Para ser preciso sobre o Claude: o auto-fix opcional é outra história. Se você pedir à Nurbak que abra um Pull Request com a correção e um teste de regressão de segurança, essa correção é gerada com Claude, só com o seu consentimento explícito, e o consentimento fica registrado em um audit trail. O scan grátis mostra completos os 3 achados mais importantes, e os planos começam em USD 79 por mês. Mais detalhes na página de code review com IA.

Resumo

As ferramentas de revisão de segurança do Claude Code são uma boa primeira linha: rápidas, explicativas e fáceis de adotar, principalmente o /security-review antes do commit e a GitHub Action em pull requests confiáveis. Trate-as como um revisor, não como um gate. Combine com scan do repositório completo, checagem de dependências e segredos, testes de autorização e revisões humanas ou pentests periódicos, e decida conscientemente qual código pode sair da sua infraestrutura.

Leituras relacionadas