Dá para confiar na revisão de segurança do Claude Code? O que ele pega e o que passa batido

Terceirizar a revisão de segurança pro agente é uma tentação grande demais pra ignorar

Você acabou de fechar uma feature, o diff tá gordo, ninguém do time tem contexto pra revisar hoje, e tem um modelo ali do lado que lê código melhor que muita gente

A Anthropic foi no ponto: em 6 de agosto de 2025 anunciou a revisão automatizada de segurança no Claude Code, com o comando /security-review no terminal e uma action pra analisar pull requests

Depois, em 27 de maio de 2026, soltou um plugin que revisa enquanto o código está sendo escrito, o security-guidance

Ou seja, a pergunta não é mais "existe?"

A pergunta é: do que dá pra confiar, e onde o humano continua obrigatório? Bora destrinchar 🙂

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que existe hoje: o comando, a action do GitHub e o plugin

São três coisas diferentes e vale não misturar, porque cada uma roda num momento distinto

1) O comando /security-review

Rodado dentro da sessão do Claude Code no terminal, ele revisa as mudanças pendentes

É o "dá uma olhada nisso aqui antes de eu commitar"

2) A GitHub Action oficial

Mantida pela Anthropic e hospedada no repositório anthropics/claude-code-security-review

Ela lê o diff do pull request e publica os achados como comentários de review nas linhas afetadas

Mesma ideia do comando, só que no fluxo do PR, onde o time já olha

3) O plugin security-guidance

Esse é de outra natureza: não é sob demanda, é contínuo

Vem do marketplace oficial anthropics/claude-plugins-official, é gratuito e está disponível em todos os planos do Claude Code

A instalação é um comando dentro da sessão:

/plugin install security-guidance@claude-plugins-official

Se você conhece um linter que roda no save, a analogia funciona bem: o plugin fica no caminho enquanto o código nasce, o comando e a action olham o resultado depois

Comando de revisão x plugin em tempo real: qual usar em cada momento

Repara numa coisa importante da coluna do plugin: os achados de alta severidade do fim do turno são devolvidos ao Claude pra ele corrigir

Isso é MUITO diferente de um relatório que ninguém lê

O que ele pega bem: os problemas que moram no próprio código

As categorias que a revisão busca são estas:

• Ataques de injeção, inclusive SQL injection
• Falhas de autenticação e autorização
• Exposição de dados
• Problemas criptográficos
• Tratamento inseguro de dados
• XSS
• Vulnerabilidades em dependências

E por que essa classe de problema sai bem numa revisão feita por modelo?

Porque a abordagem não é casamento de regra

A própria Anthropic descreve o método como leitura semântica: o Claude lê o código "como um pesquisador de segurança humano faria: entendendo como os componentes interagem, rastreando como os dados se movem pela aplicação e capturando vulnerabilidades complexas que ferramentas baseadas em regras não pegam"

Na prática, é o tipo de coisa que está escrita ali, no arquivo, esperando alguém ler com atenção

Do lado determinístico, a camada de padrão do plugin sinaliza construções que todo mundo já conhece de nome mas continua deixando escapar no cansaço:

• eval() e new Function()
• child_process.exec() e os.system()
• desserialização com pickle e yaml.load
• vetores de XSS no DOM, tipo dangerouslySetInnerHTML e innerHTML
• segredos escritos direto no código
• injeção de comando em workflows do GitHub Actions

Essa camada nem chama modelo, é checagem por padrão na hora da edição do arquivo

É o óbvio sendo pego cedo, que é justamente onde custa barato consertar

O que passa batido: exclusões explícitas, filtro de confiança e o que só aparece rodando

Agora a parte honesta

Tem coisa que não passa batido por acidente, passa batido por projeto

1. Categorias excluídas de propósito

O prompt que conduz a revisão é aberto, publicado no repositório anthropics/claude-code-security-review, no arquivo .claude/commands/security-review.md

E ele descarta categorias inteiras de achado de propósito:

• negação de serviço (DoS) e exaustão de recursos
• preocupações de rate limiting e sobrecarga de serviço
• consumo de memória ou CPU
• segredos e credenciais em disco quando já protegidos por outro meio

Ou seja: se o seu medo é o endpoint que derruba a aplicação com uma enxurrada de requisições, essa revisão não foi feita pra isso

Não é falha, é escopo… mas você precisa saber, senão o relatório limpo vira falsa sensação de segurança

2. O filtro de confiança corta o "talvez"

Pra segurar a enxurrada de falso positivo, existe um limite de confiança: achado que não atinge esse limite é descartado antes de chegar em você

Faz sentido pra usabilidade, mas o efeito colateral é direto: achado incerto e real pode simplesmente sumir do relatório

O que você vê é a parte de cima da peneira, não tudo que o modelo levantou

3. O método lê código, não vê a aplicação rodando

O comando e a action fazem análise estática assistida por modelo: leem código e diff

O plugin é misto, lembra? Tem a camada de padrão na edição, que é casamento determinístico e nem chama modelo, e as camadas de modelo que leem o diff do turno e o código ao redor no commit

Mas o ponto em comum é o que importa aqui: nenhuma delas executa a aplicação

Então falha que só aparece no comportamento em execução (combinação de estado, ordem de chamada, dado real trafegando) fica fora do alcance por construção

Aqui vale a mesma desconfiança saudável que a gente aplica quando o agente mexe nos testes pra fazer passar: verde na tela não é prova de comportamento correto

Veredito: onde a revisão humana continua obrigatória

O ganho é real e tem número: segundo dados internos da Anthropic, houve queda de 30% a 40% nos comentários relacionados a segurança em pull requests abertos com o plugin ativo

Isso é bastante coisa, principalmente pra time pequeno que hoje não tem revisão nenhuma

Mas a documentação oficial não deixa margem pra interpretação criativa: é uma ferramenta assistiva e de melhor esforço, sem garantia

Os achados são sugestões, não veredito

E mais: o revisor pode deixar passar vulnerabilidade, gerar falso positivo e se comportar de forma diferente entre bases de código, linguagens e versões de modelo

A doc é explícita também em dizer que isso não substitui revisão humana de código, SAST/DAST, varredura de dependências ou teste de intrusão

Então o veredito é esse, sem cavalo de pau: serve como primeira peneira antes do humano, não como o humano

Regra de bolso de quando a revisão humana é inegociável:

• Lógica de autorização e regra de negócio: quem pode ver o quê é uma decisão do seu produto, não uma propriedade do arquivo
• Tudo que depende de comportamento em execução: se só aparece com a coisa rodando, nenhuma das duas abordagens vai ver
• As categorias excluídas do prompt: DoS, rate limiting e consumo de recursos não estão sendo olhados, ponto
• Mudança destrutiva e irreversível: o custo do erro é alto demais pra confiar em sugestão de ferramenta assistiva

Conclusão

A revisão de segurança do Claude Code não é a bala de prata, e a graça é que a própria Anthropic não vende ela assim

O melhor uso é empilhar as camadas:

1. Plugin durante a escrita, pra pegar o óbvio cedo (o eval(), o segredo hardcoded, o innerHTML esquecido)
2. Comando ou action antes de mandar o PR, pra ler o diff com calma
3. Revisão humana e as ferramentas dedicadas por cima: SAST/DAST, varredura de dependências, teste de intrusão

Cada camada pega o que a anterior não pega, e nenhuma delas é substituta da outra

Próximo passo concreto, bem simples: instala o plugin com /plugin install security-guidance@claude-plugins-official numa sessão do Claude Code e roda /security-review nas mudanças pendentes do seu próximo commit

Lê os achados como sugestão, não como laudo, e vê o que aparece

E me conta nos comentários: o que a revisão pegou no teu projeto? E o que ela deixou passar e só um humano viu? Esse segundo caso é o mais interessante de todos =)

Até o próximo post!