Claude Code security review: como usar o Claude Security

Seu code review pega bug de lógica. Pega o N+1, pega a variável mal nomeada, pega o if invertido. Mas quem pega a SQL injection escondida no meio de um PR com 40 arquivos? Na maioria dos times, ninguém. Segurança é o review que todo mundo jura que faz e quase ninguém faz de verdade.

A Anthropic resolveu atacar exatamente esse buraco. O Claude Code ganhou um arsenal de segurança nativo: o comando /security-review, uma GitHub Action que revisa cada PR, e — a novidade que motivou este post — o plugin Claude Security, um scanner multi-agente que lê seu repositório como um pesquisador de segurança leria, entrou em beta público em 22 de julho.

Neste tutorial eu instalo o Claude Security, rodo um scan completo num projeto Laravel de laboratório, mostro como ler os findings, gero os patches e comparo o resultado com o que um scanner tradicional entrega. No final, você decide onde isso entra no seu fluxo.

TL;DR

O que é: scanner de vulnerabilidades multi-agente dentro do Claude Code — mapeia a arquitetura, monta threat model, caça vulnerabilidade e verifica cada finding antes de reportar.
Stack/Modelos: Claude Code v2.1.154+ em plano pago, plugin claude-security (beta), Python 3.9.6+, Git. Testado aqui num projeto Laravel 11.
Custo/Acesso: sem custo extra — o scan consome os limites de uso do seu plano. A versão gerenciada (monitoramento contínuo de repositórios) é produto Enterprise à parte.
Link útil: documentação oficial do Claude Security.

O que é o security review do Claude Code — e o que mudou agora

O Claude Code security review começou em agosto de 2025, quando a Anthropic lançou duas ferramentas: o comando /security-review, que roda uma passada de segurança na sua branch antes do commit, e a GitHub Action de security review, que analisa o diff de cada pull request e comenta as vulnerabilidades direto na linha de código.

Não era demo de marketing. A própria Anthropic usou a Action internamente e ela pegou, antes do merge, um RCE explorável via DNS rebinding num servidor HTTP local e uma vulnerabilidade de SSRF num sistema de proxy de credenciais. Vulnerabilidade real, em código de gente que constrói modelo de linguagem.

Em maio de 2026 veio o plugin security-guidance, que revisa o código enquanto o Claude escreve — injection, deserialização insegura, DOM API perigosa — e corrige na mesma sessão.

E em 22 de julho de 2026 chegou a peça que faltava: o plugin Claude Security, em beta público para todos os usuários de plano pago. A diferença dele para o /security-review é de profundidade. O /security-review é uma passada única na sua branch. O Claude Security é um time de agentes coordenados: um mapeia a arquitetura do repositório, outros montam o threat model por componente (entry points, sinks, fronteiras de confiança), pesquisadores caçam vulnerabilidade por categoria — injection, autenticação e acesso, memória, criptografia e secrets — e, no final, verificadores independentes revisam cada finding antes de ele entrar no relatório. Finding que não convence o painel de verificação não aparece. É o que mantém o relatório curto e legível, em vez das 400 linhas de ruído que todo SAST já te entregou.

Esse desenho — orquestrador, agentes especializados, verificação adversarial — é engenharia de IA aplicada, do tipo que separa quem usa ferramenta de quem entende o que ela faz por baixo. É exatamente o tipo de sistema que a gente desmonta e reconstrói ao vivo, toda semana, no Clã Beer and Code — a maior comunidade de engenharia de IA do Brasil, onde a régua não é assistir aula gravada, é executar com gente cobrando ritmo.

Pré-requisitos

Antes de rodar, confira:

[ ] Claude Code v2.1.154 ou superior, em plano pago (claude --version)
[ ] Dynamic workflows habilitado — no plano Pro, ative na linha "Dynamic workflows" do /config
[ ] Python 3.9.6+ disponível como python3 no PATH (python3 --version) — o plugin usa só a biblioteca padrão, nada é instalado
[ ] Git no projeto, se você quiser scan de diff e geração de patches (scan completo funciona até em pasta sem versionamento)
[ ] Um projeto para escanear — aqui vou usar uma API Laravel 11 de laboratório, com as vulnerabilidades clássicas que aparecem em código PHP de produção

Mão na massa: rodando o Claude Security num projeto Laravel

Passo 1: instale o plugin

Dentro de uma sessão do Claude Code, instale a partir do marketplace oficial da Anthropic e recarregue os plugins:

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

Se o Claude Code reclamar que o marketplace não existe, adicione antes com /plugin marketplace add anthropics/claude-plugins-official e repita a instalação.

Passo 2: rode o scan

O plugin adiciona um único comando, /claude-security, que abre um menu com três funções: escanear o repositório, escanear um conjunto de mudanças (diff de branch, PR ou commit) e sugerir patches. Você também pode falar em linguagem natural — /claude-security scan my branch ou "escaneia o commit abc1234" funcionam.

Rodei o scan completo na API Laravel. O plugin primeiro lê o repositório e oferece os escopos possíveis — repositório inteiro ou uma área focada, cada um com contagem de arquivos e custo relativo. Escolhi o repositório inteiro, confirmei (nada roda sem confirmação, porque o scan consome uma quantidade relevante de tokens do seu plano) e deixei a sessão aberta. Dica prática: rode em modo auto de permissões, senão você vira o gargalo aprovando cada passo dos agentes.

Enquanto roda, o plugin reporta cada estágio — inventário, threat model, pesquisa, verificação — e você acompanha o detalhe em /workflows. No meu projeto, um scan de porte pequeno levou o tempo de um café. Repositório grande é outra conversa: escaneie uma área por vez (a camada de API, o código de autenticação) e rode outra área depois.

Passo 3: leia o relatório

O scan escreve tudo num diretório CLAUDE-SECURITY-<timestamp>/ na raiz do repositório, com três arquivos: CLAUDE-SECURITY-RESULTS.md (o relatório humano, com cada finding identificado como F1, F2..., impacto, cenário de exploit, severidade e recomendação), CLAUDE-SECURITY-RESULTS.jsonl (os mesmos findings em formato de máquina) e um stamp de revisão que registra qual commit foi escaneado, com que profundidade e com que nível de verificação — o relatório fica amarrado ao código exato que descreve. O diretório traz o próprio .gitignore, então um git add . distraído não manda o relatório para o histórico.

No meu laboratório Laravel, os findings que subiram foram os suspeitos de sempre — e é justamente isso que impressiona, porque estavam espalhados em arquivos diferentes:

SQL injection num endpoint de busca que concatenava input do usuário dentro de DB::raw() em vez de usar binding;
IDOR num controller de faturas que buscava por Invoice::find($id) sem checar se a fatura pertencia ao usuário autenticado — o scanner traçou o fluxo da rota até a query e descreveu o cenário de exploit: troca o ID na URL, lê fatura alheia;
Mass assignment num update que passava $request->all() direto pro fill() de um model com $guarded vazio.

Nenhum desses depende de assinatura de CVE ou de regra pronta. O IDOR, em particular, é o tipo de falha que scanner tradicional não pega, porque exige entender a lógica de negócio: "essa fatura deveria pertencer a esse usuário". O Claude Security pega porque lê o código como um pesquisador — segue o fluxo do dado, entende a intenção e monta o cenário de ataque.

Passo 4: transforme findings em patches

Rode /claude-security de novo e escolha Suggest patches (ou peça direto: "corrige o finding F1"). Cada patch é construído numa cópia scratch do repositório — seus arquivos ficam intactos — e, antes de ser entregue, é revisado por um agente independente do que o escreveu, que roda os testes do projeto quando existem e lê o diff procurando problema novo. Se a revisão não consegue garantir que o patch resolve o finding sem mudar comportamento, você recebe uma nota explicando o porquê em vez de um patch.

Os patches aprovados caem em patches/, um por finding, e nunca são aplicados automaticamente. Aplicar é decisão sua:

git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch

Aplique cada patch em seu próprio PR, para revisar e testar isolado. No meu caso, o patch da SQL injection trocou a concatenação por parameter binding mantendo o estilo do arquivo — não veio refactor gratuito junto, o que já o coloca à frente de muita sugestão de IA.

Bônus: o cinto e o suspensório

O plugin é a camada profunda, mas as outras continuam valendo. Para uma checagem rápida antes do commit, o /security-review de sempre resolve em uma passada. E para garantir que nenhum PR entra sem revisão de segurança, a GitHub Action se configura em minutos:

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

A Action analisa só o diff do PR, comenta na linha exata e filtra sozinha as categorias que geram ruído — DoS teórico, rate limiting, exaustão de memória ficam de fora por padrão.

▪ Clã Beer and Code

Tutorial te mostra o caminho — no Clã você constrói junto. Aula ao vivo toda semana, projetos reais de Engenharia de IA, ao lado de quem já está em produção.

Entrar no Clã

Claude Security substitui o scanner tradicional?

Não — e a própria documentação é honesta sobre isso. SAST e dependency scanning são determinísticos: mesma entrada, mesma saída, regra auditável. O Claude Security é não-determinístico — dois scans do mesmo código podem trazer findings diferentes — e não faz análise de dependências nem enforcement de política.

O ganho está no que o scanner tradicional estruturalmente não alcança: vulnerabilidade que depende de contexto e atravessa arquivos. O IDOR do meu laboratório é o exemplo perfeito — nenhuma regra estática sabe que fatura tem dono. A conta que fecha é defesa em profundidade: SAST e dependency scan no CI para o que é padrão e assinatura, Claude Security para o que exige raciocínio, revisão humana por cima de tudo.

Limitações e pontos de atenção

Consumo de tokens. Scan completo em repositório médio usa uma fatia relevante do limite do plano. Escope o scan em repositório grande e rode o completo com parcimônia.
Não-determinismo. Não trate um scan limpo como certificado de segurança. Rode com regularidade e use o stamp de revisão para saber exatamente o que cada relatório cobriu.
Sem isolamento próprio. O plugin roda na sua sessão, com as permissões dela. Não use como defesa para analisar repositório hostil ou desconhecido — a gente já mostrou como um repositório aparentemente limpo engana seu agente de código.
Prompt injection na Action. A GitHub Action não é blindada contra prompt injection — num repo público, exija aprovação de mantenedor antes de rodar workflows em PR de terceiros.
Findings mudam de validade. Patch só é gerado se o código do finding ainda for o mesmo do scan. Mudou a branch, o plugin pede scan novo em vez de remendar com relatório velho — comportamento correto, mas que pega de surpresa quem esperava patch instantâneo.

FAQ rápido

Funciona em projeto que não é git? O scan completo sim — funciona em qualquer diretório, versionado ou não. Scan de diff e geração de patches exigem Git; outros sistemas de versionamento não são suportados.

Preciso pagar algo além do plano do Claude Code? Não. O plugin roda dentro dos limites de uso do plano pago. O que existe à parte é o produto gerenciado Claude Security (Enterprise), que monitora repositórios conectados continuamente — o plugin, por rodar local, alcança o que o gerenciado não alcança, como repos em GitLab, Bitbucket ou redes fechadas.

O scan roda no meu terminal ou na nuvem? Os agentes rodam na sua sessão do Claude Code, orquestrados localmente. O único passo que toca a rede é listar seus PRs abertos, e só quando o gh já está autenticado na sessão.

Posso confiar no patch de olhos fechados? Não — e o próprio fluxo te impede. Patch nunca é aplicado automaticamente, e quando o código corrigido não tem testes, a nota do patch avisa que a revisão rodou sem suíte. Trate como PR de um colega: leia o diff, rode os testes, aí faça o merge.

Conclusão

Rodei o Claude Security num projeto Laravel e ele entregou o que prometia: findings verificados, com cenário de exploit descrito, e patches que respeitam o estilo do código — incluindo um IDOR que passaria batido em qualquer SAST. O custo é token e tempo de scan; o retorno é uma camada de revisão que a maioria dos times simplesmente não tem.

O movimento da Anthropic é claro: segurança deixando de ser etapa para virar propriedade do fluxo de desenvolvimento, com IA revisando IA na velocidade em que IA escreve código. Quem escreve software com agente e ainda revisa segurança uma vez por trimestre está jogando o jogo antigo.

Se você quer ver o Claude Code além do autocomplete, começa pelo scan no seu projeto de estimação — e depois vai fundo no ferramental com o guia de hooks, slash commands e MCP, que transforma o agente em parte do seu fluxo de engenharia.