Auditoria de Segurança com o Claude Code: Um Fluxo Prático para 2026

Os nomes de comandos e plugins deste artigo vêm da documentação oficial da Anthropic (consultada em 08/2026); o Claude Code muda com frequência, então confira o marketplace /plugin de novo antes de auditar.

O que é uma auditoria de segurança com o Claude Code?

Uma auditoria de segurança com o Claude Code é a prática de usar o Claude Code como um "revisor de segurança de IA" - lendo o significado do seu código para encontrar vulnerabilidades, em vez de só casar padrões como um linter tradicional. Como o modelo entende o fluxo de dados e a intenção de uma função, ele pega problemas que as ferramentas baseadas em regex costumam deixar passar: entrada de usuário fluindo para uma string SQL concatenada, um endpoint sem verificação de autorização ou uma chave de API jogada direto no código-fonte.

As classes de vulnerabilidade que o Claude Code tende a pegar incluem: injeção (SQL, comando, NoSQL, XXE), autenticação e autorização quebradas (IDOR, escalada de privilégios, sessões fracas), exposição de dados (segredos hardcoded, PII em logs), criptografia fraca (RNG ruim, má gestão de chaves), configuração incorreta (CORS, cabeçalhos de segurança) e risco de cadeia de suprimentos (dependências com CVEs conhecidos).

Este guia cobre quatro abordagens:

• O /security-review nativo - um comando embutido do Claude Code mais uma GitHub Action oficial da Anthropic, lançada em agosto de 2025 (anthropics/claude-code-security-review, acessada em 08/2026). Ele revisa as mudanças pendentes, pontua a severidade e sugere correções, com um filtro de falsos positivos embutido.
• O plugin claude-security - instale com /plugin install claude-security@claude-plugins-official, que adiciona um comando /claude-security abrindo um menu de varredura profunda multiagente (não um comando de varredura simples): mapear a arquitetura → construir um modelo de ameaças → caçar vulnerabilidades → um agente independente verifica antes de reportar. Gratuito (conta no uso do seu plano), exige dynamic workflows. Veja a seção dedicada mais abaixo.
• O plugin security-guidance - revisa automaticamente o código que o Claude acabou de escrever em 3 camadas (casamento de padrão instantâneo, revisão em segundo plano no fim do turno, revisão profunda no commit/push) - complementa auditorias periódicas com uma camada de monitoramento contínuo. Veja nosso artigo sobre boas práticas de segurança para detalhes.
• A skill ak-security pronta - um pacote de prompts cobrindo STRIDE + OWASP A01-A10, auditoria de dependências consciente da stack, red-teaming multipersona e um modo --fix, para você nunca ter que escrever um prompt longo à mão. Pago, parte do AgentKit Engineer Kit.

A documentação oficial sobre o modelo de segurança do Claude Code fica em code.claude.com/docs/en/security (acessada em 08/2026) - vale a leitura antes de dar à IA permissão para rodar comandos no seu repositório.

Antes de auditar: preparação

Três minutos de preparo mantêm a sessão limpa e reversível:

• Claude Code instalado e com login feito. Se você ainda não chegou lá, siga o guia de instalação do Claude Code.
• Uma árvore de trabalho Git limpa (git status não mostra nada pendente). Você quer um diff claro para distinguir o que a IA propõe, e para reverter com git restore se um patch quebrar algo.
• Defina o escopo logo de cara: uma única pasta (src/api/**), os arquivos que você está alterando agora ou o repositório inteiro. Um escopo estreito é mais rápido e mais barato em tokens.
• Audite apenas código CONFIÁVEL. Este é o aviso importante que eu faço questão de dar cedo: quando você deixa a IA ler código do repositório ou PR de um estranho, conteúdo malicioso nesse código pode injetar instruções (prompt injection) que enganam o modelo. Para código não confiável, revise-o manualmente ou rode-o em um ambiente isolado.
• Auditando um repositório desconhecido/não confiável? Rode-o em um sandbox. Se você tiver que auditar um repositório que não conhece, rode o Claude Code dentro do /sandbox (Seatbelt no macOS, bubblewrap+socat no Linux/WSL2) para isolamento em nível de SO - uma camada mais forte que um modo de permissão comum. Veja sandboxing do Claude Code.
• Verifique as permissões de comando. Revise permissões e execução segura no Claude Code para que a IA não possa rodar um comando destrutivo por conta própria durante a varredura. Em 08/2026, o modo auto é o modo inicial padrão no Pro/Max/Team - um comando arriscado que a auditoria talvez sugira (digamos, um --fix que roda npm install) passa pelo classificador em vez de um prompt manual a cada vez, então ainda revise sua allowlist antes de começar.

O fluxo de auditoria do Claude Code em 6 passos

Esta é a espinha dorsal da sessão inteira. Trabalhe em sequência do estreito para o amplo, para que os resultados fiquem legíveis e você não queime tokens à toa.

Passo 1 - Defina o escopo

Comece nomeando exatamente o que você quer revisar. Para uma mudança pequena, deixe o Claude focar no diff; para um repositório grande, cerque-o com globs de diretório nas áreas sensíveis (auth, pagamentos, uploads, APIs públicas). Peça ao Claude para ler cada arquivo no escopo antes de analisar - senão o modelo tende a adivinhar pelos nomes das funções. Um prompt de abertura:

Read all files in src/api/ and src/auth/ first.
Do not change anything yet. Just list the areas with an attack
surface (external input, DB access, auth handling) so I can pick a scope.

Passo 2 - Rode o /security-review nas mudanças pendentes

Para as mudanças que você está prestes a commitar, rode o comando nativo direto na sessão do Claude Code:

/security-review

Isso revisa o diff pendente, classifica a severidade e propõe uma correção para cada achado. Roda no modelo Claude mais forte disponível (configurável) - pense nele como um revisor de segurança lendo seu PR antes de um humano chegar. Este é o lugar mais rápido para "fazer shift left": pegar problemas enquanto o código ainda está quentinho e não chegou à branch principal.

Passo 3 - Escaneie o repositório inteiro com STRIDE + OWASP

Para cavar mais fundo que o diff, dê ao Claude um prompt estruturado de modelagem de ameaças. O STRIDE mapeia bem certinho no OWASP Top 10. Um modelo para copiar e colar:

Audit all in-scope code across the 6 STRIDE categories, mapped to the OWASP Top 10:
- Spoofing -> A07 (identification/authentication failures)
- Tampering -> A03 (injection), A08 (data/software integrity)
- Repudiation -> A09 (missing logging/monitoring)
- Info Disclosure -> A02 (crypto), A01 (access control)
- Denial of Service -> note it, but only report with clear impact
- Elevation of Priv -> A01 (broken access control)

For each finding, record: severity, category, file:line, a short description,
and a concrete fix. Do not report theoretical issues you cannot tie to real impact.

Passo 4 - Audite as dependências

As vulnerabilidades muitas vezes moram não no código que você escreveu, mas nas bibliotecas que você trouxe. Rode a ferramenta certa para sua stack e depois deixe o Claude sintetizar e priorizar:

npm audit # Node.js
pip-audit # Python
govulncheck ./... # Go
bundle audit # Ruby

Depois cole a saída no Claude: "Ranqueie estes CVEs pela explorabilidade real no meu projeto e ignore qualquer coisa que só esteja em devDependencies e nunca chegue à produção." O Claude ajuda a cortar o ruído - nem todo CVE está no seu caminho de execução real.

Passo 5 - Caçe segredos hardcoded

Peça ao Claude para escanear chaves de API, senhas, tokens e chaves privadas embutidas diretamente em arquivos de código e de configuração. Uma observação sobre higiene de credenciais: ao reportar, mascare os valores reais para <REDACTED_TOKEN> antes de logar ou commitar o relatório - não deixe um segredo vazar justamente pelo arquivo que audita em busca dele.

Scan the whole repo for hardcoded secrets (api keys, passwords, tokens,
private keys, DB connection strings). For each finding, record only file:line
and the TYPE of secret, and mask the value to <REDACTED>. Do not print real values.

Passo 6 - Classifique a severidade e exporte o relatório

Peça ao Claude para reunir todos os achados em uma única tabela por severidade, com limiares de ação claros:

Para guardar os resultados, peça ao Claude para exportar um relatório em Markdown com um resumo da contagem por severidade no topo ("2 Críticos, 3 Altos...") - esse formato encaixa direitinho num rastreador de issues ou numa revisão para sua liderança. Se você roda auditorias com regularidade, guarde relatórios datados numa pasta security/ (com as partes sensíveis no gitignore) para poder comparar execuções e notar quais vulnerabilidades reaparecem ou escapam da revisão.

Uma sessão de auditoria de verdade: como ler os achados

Aqui está a parte que a maioria dos concorrentes quase sempre pulam: uma tabela de achados de verdade, não uma descrição de recurso. Abaixo está um resultado ilustrativo de um projeto Node/TypeScript de exemplo (API + auth) para você ver como a saída se parece - rode no seu próprio repositório para obter sua própria tabela:

Como ler: vá de cima para baixo por severidade. O achado #1 bloqueia o release - sem discussão. O #2 e o #3 entram direto na sprint. O #4 (IDOR) costuma ser subestimado, mas é uma falha de escalada de acesso extremamente comum. Para cada linha, abra o file:line exato, confirme que o problema é real (não um falso positivo) e só então corrija - não corrija no escuro seguindo o relatório.

Um truque rápido de verificação antes de corrigir: pergunte de volta ao Claude, "Prove que o achado #4 é explorável: escreva uma requisição concreta que o usuário A usaria para ler o pedido do usuário B." Se o modelo consegue montar um cenário de exploração específico, é uma vulnerabilidade real; se ele enrola ou precisa supor condições irreais, é provavelmente um falso positivo e você pode baixar a prioridade. Esse passo adversarial filtra o ruído e ajuda você a explicar o risco para o resto do time em linguagem concreta de atacante, em vez de jargão abstrato.

Corrigindo uma vulnerabilidade - um antes/depois de verdade

Pegue o achado #1 (Crítico, SQL injection) como exemplo. Aqui está o tipo de código fácil de errar:

// BEFORE - vulnerable to SQL injection
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = '" + id + "'";
 return db.query(sql); // the id input flows straight into the SQL string
}

E depois de corrigir com uma consulta parametrizada:

// AFTER - parameterized, the driver escapes it
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = $1";
 return db.query(sql, [id]); // the id value travels through the parameter channel, not the SQL string
}

Por que é mais seguro: na segunda versão, o id não é mais concatenado na string SQL, e sim passado por um canal de parâmetro separado. O driver do banco de dados o trata como dado, não como comando - então uma string como ' OR '1'='1 não consegue mais mudar a estrutura da consulta.

Para um fluxo automatizado, a skill pronta oferece o --fix para corrigir os achados um de cada vez, rodar um teste de guarda contra regressões depois de cada patch e então commitar cada correção separadamente. Mas sempre revise o diff antes de fazer merge - e quando um patch quebra um teste, não chute. Em vez disso, depure com a IA uma correção que quebra testes para achar a causa real.

Automação: revisão de segurança em cada Pull Request

Para ter cada PR escaneado automaticamente, use a GitHub Action oficial. Adicione um arquivo .github/workflows/security.yml:

name: Security Review
on: [pull_request]
jobs:
 review:
 runs-on: ubuntu-latest
 permissions:
 pull-requests: write
 contents: read
 steps:
 - uses: actions/checkout@v4
 - uses: anthropics/claude-code-security-review@main
 with:
 claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

A Action comenta os achados direto no PR, então o revisor os vê na hora.

Ressalva obrigatória: segundo a Anthropic, esta Action ainda não está endurecida contra prompt injection. Rode-a apenas em PRs confiáveis e habilite "Require approval for all external contributors" nas configurações das suas Actions - senão um PR malicioso de um estranho poderia injetar instruções que enganam o processo de revisão.

Para completar a camada defensiva, combine-a com um fluxo de trabalho Git seguro com o Claude Code e considere adicionar um pre-commit hook que escaneia segredos antes de o código chegar ao remoto.

Varredura profunda gratuita com o plugin claude-security

Esta é uma camada de varredura profunda multiagente, oficial e gratuita - bem diferente do /security-review do Passo 2, que revisa um diff numa única chamada de modelo. O claude-security roda um time inteiro de agentes na sua sessão: um mapeia a arquitetura do repositório, um constrói um modelo de ameaças a partir disso, um grupo caça vulnerabilidades contra o modelo de ameaças, e então um agente independente verifica cada achado antes de ele entrar no relatório final - é esse passo de verificação independente que torna o relatório mais confiável que uma única passada de varredura.

Requisitos: Claude Code v2.1.154+ em um plano pago, precisa de dynamic workflows para orquestrar seus agentes (no Pro você mesma tem que ligá-los na linha "Dynamic workflows" em /config); Python 3.9.6+ disponível no seu PATH como python3 (a ferramentaria do plugin usa só a biblioteca padrão, nada extra é instalado); e Git para varreduras de mudanças e para exportar patches (uma varredura do repositório inteiro ainda funciona sem o Git).

Instale e rode:

/plugin install claude-security@claude-plugins-official
/claude-security # opens the menu: Scan codebase / Scan changes / Suggest patches
/claude-security scan my branch # or call a job directly in plain language

O plugin lê seu repositório primeiro, depois oferece uma varredura completa ou uma área focada com uma estimativa de custo para cada opção - útil em um repositório grande, já que uma varredura completa pode usar um número significativo de tokens e precisa do Claude Code aberto até terminar. Nada roda até você confirmar.

Os resultados chegam em um diretório CLAUDE-SECURITY-<timestamp>/ com timestamp, bem dentro do seu repositório: CLAUDE-SECURITY-RESULTS.md (um relatório legível, cada achado com um ID como F1 mais severidade, confiança e um cenário de exploração), uma versão .jsonl legível por máquina e um carimbo de revisão - um arquivo que registra exatamente qual commit foi escaneado, com que profundidade e se mudanças não commitadas foram incluídas, para que um relatório sempre se amarre ao código exato que descreve. Esse diretório carrega seu próprio .gitignore, então um git add descuidado nunca o varre para dentro de um commit.

Para corrigir: rode /claude-security de novo, escolha "Suggest patches" e selecione quais achados tratar. Cada patch é revisado por um agente independente daquele que o escreveu antes de ser entregue, e nunca é aplicado automaticamente - os patches chegam em patches/F<n>.patch, e você mesma roda git apply depois de revisar.

Versus a skill ak-security: as duas realmente se sobrepõem agora, e não adianta fugir disso. A vantagem do claude-security: gratuito, verificação independente por um agente separado e patches que você pode git apply na hora. A vantagem do ak-security: um framework empacotado de STRIDE + OWASP + red-team de 4 personas + varredura de segredos em um comando arrumadinho, familiar se você já usa o AgentKit para outras coisas. Nenhum substitui totalmente o outro - se você ainda não tem o AgentKit, o claude-security é forte o suficiente para começar de graça.

Red-team avançado: auditando a partir de 4 personas de atacante

Uma passada de STRIDE é boa, mas as vulnerabilidades reais tendem a aparecer quando você pensa como um atacante específico. Rodar a auditoria a partir de 4 pontos de vista diferentes rende um ganho de informação claro:

• Adversário de Segurança - procura bypass de auth, variantes de injeção, IDOR: "Se eu logar com uma conta comum, consigo ler ou editar os dados de qualquer outra pessoa?"
• Cadeia de Suprimentos - dependências com CVEs conhecidos, CI/CD envenenado, typosquatting em pacotes.
• Interno (Insider) - escalada de privilégios horizontal/vertical, exportação de dados em massa, abuso das permissões de uma conta interna.
• Infraestrutura - SSRF, segredos vazando em variáveis de ambiente, configurações de contêiner/rede mal ajustadas.

Escrever todas as 4 personas à mão dá muito trabalho, porque cada ângulo precisa do próprio conjunto de prompts e checklist. É exatamente aqui que a modelagem de ameaças pronta e estruturada te poupa horas de escrita de prompt.

Rodar as 4 personas é uma passada periódica de varredura profunda; para uma camada contínua que pega problemas no momento em que o Claude escreve código (em vez de esperar pela sua próxima auditoria), veja o plugin security-guidance em nosso artigo sobre boas práticas de segurança - as duas camadas se complementam, não se substituem.

Usando a skill ak-security pronta (pule a escrita de prompt)

Em vez de escrever à mão o prompt de STRIDE, as 4 personas de red-team e o fluxo --fix toda vez, o bundle do AgentKit — agora $149 (de $198) empacota tudo isso na skill ak-security (parte do Engineer Kit, $99; o site lista garantia de devolução do dinheiro e atualizações vitalícias, e não menciona cobrança recorrente). Como usar:

/ak:security src/api/**/*.ts # scan a narrow scope
/ak:security full --red-team --fix # whole repo, 4 personas, auto-patch

Ela reúne STRIDE + OWASP A01-A10, auditoria de dependências consciente da stack, detecção de segredos, pontuação de severidade e patching sequencial com um teste de guarda. Veja quais skills de segurança o Engineer Kit inclui para pesá-la contra suas necessidades.

Para ser sincera: esta skill realmente se sobrepõe ao plugin gratuito claude-security acima agora - não espere que ela "transforme a IA num pentester" mais do que o plugin nativo faz. A vantagem do ak-security: reúne STRIDE + OWASP + red-team de 4 personas + varredura de segredos/dependências em um comando arrumadinho, familiar se você já usa o AgentKit em outros lugares; a vantagem do claude-security: verificação independente por um agente separado e patches que você pode git apply na hora, de graça. Nenhum substitui totalmente o outro - o kit vale a pena quando você já tem o AgentKit e quer ficar em um só ecossistema, não porque seja "fundamentalmente mais forte".

Uma linha para desambiguar: o AgentKit aqui é um kit para o Claude Code (agentkit.best, a CLI ak), não o AgentKit da OpenAI (Agent Builder/ChatKit).

Limites reais, e quando NÃO confiar na IA

Segurança está pertinho do território YMYL - ser honesta sobre os limites importa mais do que o hype:

• Prompt injection. Não audite código desconhecido no escuro. Código não confiável pode injetar instruções que levam o modelo a ignorar vulnerabilidades ou a rodar comandos não intencionais.
• Falsos positivos e falsos negativos. Por padrão, o /security-review filtra as classes de DoS, rate-limiting, exaustão de recursos, open-redirect e validação de entrada que ele não consegue amarrar a um impacto demonstrável - então "escaneado limpo" não quer dizer "perfeitamente seguro". Por outro lado, a IA ainda deixa passar falhas sutis de lógica de negócio (race conditions, TOCTOU, lógica de autorização complexa).
• Ela não substitui um pentest profissional. Esta é uma ferramenta de shift-left para pegar problemas cedo e barato, não uma certificação de segurança. SAST/DAST e pentest manual ainda são necessários para sistemas críticos.
• Custo de tokens. Escanear um repositório grande consome tokens e tempo significativos; cerque o escopo nos diretórios sensíveis em vez de rodar full toda vez.

Perguntas frequentes (FAQ)

O comando /security-review é gratuito?

O comando e a GitHub Action são open source da Anthropic, então não há uma taxa separada para usá-los. O custo real é o token/uso do Claude Code sob qualquer plano em que você esteja (Pro, Max ou a API por token).

Como uma auditoria do Claude Code é diferente do SAST tradicional?

O SAST em geral casa padrões e regras fixos, então tende a ser barulhento. O Claude Code lê semântica e fluxo de dados, então pega problemas dependentes de contexto (como IDOR ou lógica de autorização) que o casamento de padrões deixa passar - ao custo de ser menos determinístico e precisar de confirmação humana.

A IA pode substituir um pentest profissional?

Não. É uma camada de shift-left para pegar problemas cedo e barato, não uma certificação. Sistemas críticos ainda precisam de pentest manual, ao lado de SAST/DAST no pipeline.

É seguro auditar o código de outra pessoa?

Há um risco de prompt injection: código não confiável pode injetar instruções que enganam o modelo. Audite apenas código confiável, ou rode-o em um ambiente isolado com aprovação manual habilitada para contribuidores externos.

Quantos tokens e quanto tempo leva uma auditoria?

Depende do escopo. Revisar um diff pequeno leva poucos minutos e poucos tokens; escanear um repositório grande leva bem mais tokens e demora visivelmente mais. Cerque o escopo nos diretórios sensíveis para economizar.

Como a skill ak-security é diferente de escrever meu próprio prompt?

Ela empacota STRIDE + OWASP, 4 personas de red-team e o fluxo --fix com teste de guarda em um único comando, poupando esforço de escrita de prompt. Em capacidade de detecção, é mais ou menos equivalente a escrever um bom prompt você mesma - a diferença é conveniência e consistência, não ser "fundamentalmente mais forte".

Como o plugin claude-security é diferente da skill ak-security?

As duas realmente se sobrepõem agora. O claude-security é gratuito, roda multiagente com um passo de verificação independente e exporta patches que você pode git apply na hora. O ak-security é pago (parte do AgentKit), condensado em um comando com um framework pronto de STRIDE + OWASP + 4 personas + varredura de segredos/dependências. Nenhum substitui totalmente o outro - escolha com base em se você já tem o AgentKit e se quer o gratuito ou a opção mais compacta.

O plugin security-guidance substitui auditorias periódicas?

Não. O security-guidance é uma camada de checagem pontual contínua que roda no momento em que o Claude escreve código (casamento de padrão instantâneo, revisão em segundo plano no fim do turno, revisão profunda no commit/push) - ele pega problemas cedo, mas não substitui uma auditoria abrangente, periódica ou sob demanda, como o claude-security ou o fluxo de 6 passos acima. As duas camadas se complementam.

Conclusão e próximos passos

Uma auditoria de segurança com o Claude Code não vai substituir um especialista, mas transforma a caça a vulnerabilidades num hábito barato e rápido - rode o /security-review antes de cada release, faça uma varredura STRIDE periódica ou rode o claude-security para uma passada de varredura profunda gratuita, ligue o security-guidance para revisão contínua enquanto você escreve, e automatize em PRs confiáveis. Depois, expanda para uma revisão de código com IA abrangente e reforce a base com boas práticas de segurança para o Claude Code. E não esqueça: uma auditoria periódica antes de cada release vale mais que uma varredura profunda que você depois esquece.