Claude Security: o scanner de vulnerabilidades que roda dentro da sua sessão de código

Scanner de segurança tradicional trabalha por assinatura: casa um padrão de código com uma lista de vulnerabilidades conhecidas e para por aí. Funciona bem pra SQL injection óbvio, mal pra uma falha que só aparece quando você segue o dado de um arquivo até outro, três camadas depois, num fluxo que nenhuma regra estática enxerga inteiro. A Anthropic lançou um plugin pro Claude Code que ataca exatamente essa lacuna: em vez de casar padrão, ele lê o código como um pesquisador de segurança leria, com um time de agentes dedicado a cada etapa do trabalho.

O que é o Claude Security

O Claude Security é um plugin oficial (claude-security@claude-plugins-official) que roda dentro de uma sessão normal do Claude Code. Ele não é um daemon separado nem um serviço que fica escutando seu repositório: você abre o comando /claude-security, escolhe o que quer escanear (o repositório inteiro, uma área específica, o diff de uma branch, um pull request ou um commit) e o scan roda ali, contando contra o limite de uso do seu plano.

Existe também uma versão gerenciada, hospedada, disponível no plano Enterprise, que monitora repositórios continuamente e roda em Claude Mythos 5. O plugin é a versão que qualquer desenvolvedor instala e usa na hora, e alcança lugares que o serviço gerenciado não alcança: repositório no GitLab ou Bitbucket, ou numa rede que não aceita conexão de entrada.

Como funciona por dentro

A documentação oficial descreve o scan como um time de agentes, cada um com uma etapa fixa:

1. Mapeia a arquitetura. Antes de procurar qualquer falha, o time entende como o código está organizado.
2. Constrói um modelo de ameaça. A partir do mapa, decide o que vale a pena investigar.
3. Caça vulnerabilidades. Procura os problemas de verdade, cruzando componentes, não arquivo por arquivo isolado.
4. Verifica cada achado de forma independente. Um agente diferente do que encontrou o problema tenta refutar o achado antes dele entrar no relatório.

Esse último passo é o que separa a ferramenta de um scanner comum: achado só vira linha do relatório depois que um verificador tenta desmontá-lo e não consegue. É o motivo declarado pra relatório ficar curto e por que vale a pena ler cada item.

Duas ressalvas que a documentação é explícita sobre: o scan é não determinístico (duas rodadas na mesma versão do código podem achar coisas diferentes) e cada relatório carrega um carimbo de revisão, com o commit exato que foi analisado, pra nunca ficar sem saber se o relatório ainda descreve o código que você tem hoje.

Onde ele entra na esteira de segurança

A Anthropic não vende o plugin como substituto do que você já usa. A documentação posiciona seis camadas, cada uma cobrindo uma parte diferente do problema:

O ponto prático dessa tabela: o plugin roda em cima do que você já tem, não no lugar. Ele coexiste com o scanner estático que já está no seu CI e com a revisão de PR que você já faz.

Como rodar

Requisitos: um plano pago (o scan usa workflows dinâmicos, que no Pro precisam ser ligados em /config), Python 3.9 ou mais novo disponível como python3, e git para escanear diffs ou gerar patches (um scan completo funciona mesmo sem controle de versão).

Instalação, dentro de uma sessão do Claude Code:

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

O fluxo padrão é: rodar /claude-security, escolher Scan codebase, confirmar o escopo, ler o relatório na pasta CLAUDE-SECURITY- seguida da data e hora do scan (arquivo CLAUDE-SECURITY-RESULTS.md, com versão irmã em .jsonl e .sarif, essa última compatível com GitHub code scanning) e, pros achados que valem a pena, rodar /claude-security de novo e escolher Suggest patches.

Nenhum patch é aplicado sozinho. Cada um sai revisado por um agente diferente do que escreveu, roda os testes do projeto quando eles existem, e só vira patch de verdade quando essa revisão consegue confirmar três coisas: que ele resolve o achado, que não introduz vulnerabilidade nova e que não muda comportamento em nenhum outro ponto. Quando não consegue confirmar as três, você recebe uma nota curta em vez de um patch, o que é mais honesto do que entregar uma correção duvidosa.

Um detalhe de modelo vale registrar: o plugin usa Claude Fable 5.1 como modelo recomendado pra achar vulnerabilidade, e parte do trabalho pode cair pra Opus 4.8 quando o classificador de segurança do Fable 5.1 bloqueia uma etapa específica (isso é esperado, o scan continua e termina normalmente). Fable 5.1 também cortou o custo de leitura de cache pra um quarto do valor cobrado nos outros modelos Claude, o que importa aqui porque um scan de repositório grande é justamente o tipo de sessão longa que relê o mesmo contexto repetidas vezes.

O que muda pra quem entrega software pra cliente

Três coisas práticas, sem prometer o que a ferramenta ainda não prova sozinha:

• Scan de diff antes do merge é o uso que compensa o custo de token. Rodar contra o repositório inteiro toda semana é caro e demorado; rodar contra o diff de uma branch antes de abrir o PR é rápido e pega o problema antes dele nascer em produção.
• Relatório não é aprovação automática. O SARIF alimenta o code scanning do GitHub e o Markdown dá pra revisar em texto, mas achado com confiança baixa ainda precisa de olho humano, porque o scan é declaradamente não determinístico.
• Ele não troca o que você já tem, some no meio. Quem já roda análise estática no CI continua rodando; o plugin cobre a categoria de falha que exige entender o sistema inteiro (fluxo de dado entre componentes), não a que uma regra determinística já pega sozinha.

Pra quem entrega código pra cliente, a peça que mais importa é a mais chata: cada relatório carrega o commit exato que foi analisado. Isso é o que transforma "a gente rodou um scan de segurança" de afirmação vaga em algo que dá pra mostrar, com data e hash, quando o cliente perguntar.