Claude Code: revisão de segurança e GitHub Action em 2026

O autor do material original descreve a sua experiência: “Acabei de executar security-review no meu próprio projeto vibe e a equipa encontrou vários problemas reais em 4 minutos, que já foram corrigidos.” Este é o mesmo trabalho que costumava ocupar um dia a um consultor externo.

Encontra materiais adicionais sobre a configuração de ferramentas na documentação da Ailoot.

O que é /security-review no Claude Code?#

O comando funciona em dois modos. Local: execute /security-review no terminal e o Claude lê o repositório e produz um relatório. Do lado do servidor: o mesmo motor é instalado como GitHub Action e comenta automaticamente, em linha, cada Pull Request.

Ao contrário dos scanners SAST clássicos (Snyk Code, Semgrep, SonarQube), o /security-review não trabalha com regras fixas. Lê o código como um engenheiro em atividade: segue o fluxo de dados, compreende que framework utiliza e onde estão os limites de confiança, e deteta vulnerabilidades que nenhuma regra descreve.

Isto não significa que o /security-review substitua um pentest externo ou testes em tempo real num ambiente de staging. Pode automatizar parte da revisão inicial do código, mas este artigo não mede uma fração de cobertura da auditoria. Abaixo, explico como executá-lo corretamente e o que o Claude encontrará no seu projeto.

Como executar /security-review em 5 passos?#

Passo 1. Atualize o Claude Code. O comando funciona a partir da versão lançada a 20 de fevereiro de 2026.

claude update

Se instalou o Claude Code através do npm, também pode fazer o seguinte:

npm install -g @anthropic-ai/claude-code@latest

Confirme que /security-review está disponível:

claude /help | grep security

Passo 2. Abra o projeto e inicie sessão no Claude Code.

cd ~/projects/my-vibe-project
claude

Passo 3. Execute o comando. No Claude Code, basta introduzir:

/security-review

O Claude executa automaticamente 3 fases de análise:

1. Investigação do contexto do repositório - lê a estrutura e identifica a stack, as rotas e as consultas à base de dados.
2. Análise comparativa - compara o estado atual com padrões típicos de vulnerabilidade para esta stack.
3. Avaliação de vulnerabilidades - apresenta cada suspeita com um nível de confiança numa escala de 1 a 10. Só são incluídas no relatório conclusões com confiança ≥ 8.

Passo 4. Leia o relatório. O formato de saída é uma tabela Markdown. Para cada problema, o Claude fornece:

• Ficheiro e número da linha (por exemplo, src/auth/login.ts:42)
• Gravidade (HIGH / MEDIUM / LOW)
• Categoria (sql_injection, xss, auth_bypass, insecure_storage)
• Descrição - o que está errado
• Cenário de exploração - como um atacante poderia tirar partido do problema
• Recomendação - como o corrigir

Passo 5. Peça-lhe que aplique as correções. Depois, pode trabalhar com ele como com um agente normal:

“Aplica as correções de gravidade HIGH do relatório, uma de cada vez, com uma descrição de PR.”

O Claude abre cada ficheiro e propõe uma alteração; cabe-lhe a si confirmá-la. Num projeto real, resolvi 5 problemas em 40 minutos, em vez das 3 horas previstas.

Que vulnerabilidades encontra o /security-review?#

A documentação oficial da Anthropic descreve a lista completa do que é incluído por predefinição na análise:

Além disso, o comando abrange categorias que os scanners automatizados raramente detetam:

• Command injection - execução de dados introduzidos pelo utilizador numa shell (child_process.exec(userInput))
• Path traversal - carregamento de um ficheiro através de ../../etc/passwd
• XXE - XML com entidades externas
• Template injection - SSTI em Jinja/Handlebars/EJS
• NoSQL injection - operadores $ne, $gt em consultas MongoDB
• Utilização indevida de criptografia - utilização de MD5, modo ECB ou um IV estático

O Claude atribui uma gravidade a cada conclusão. A escala é simples:

• HIGH - exploração remota sem autenticação, fuga de dados que afeta todos os utilizadores
• MEDIUM - exploração sujeita a condições adicionais (é necessária uma sessão / uma entrada específica)
• LOW - vetor potencial, não crítico neste momento, mas que vale a pena corrigir

Convém saber: na configuração padrão, o Claude não comunica DoS, limitação de pedidos, esgotamento da memória, open redirects sem impacto comprovado, injeção de expressões regulares / ReDoS ou falsificação de registos. Isto é intencional, para não inundar o utilizador com ruído. Se estas classes forem relevantes, amplie as regras (consulte abaixo a secção sobre filtragem de falsos positivos).

Como configurar uma GitHub Action para revisão automática?#

Passo 1. Obtenha uma chave de API. Aceda a console.anthropic.com, crie uma chave de API e copie-a.

Passo 2. Coloque a chave nos secrets do repositório. No GitHub: Settings → Secrets and variables → Actions → New repository secret. Dê-lhe o nome CLAUDE_API_KEY; o valor é a sua chave.

Passo 3. Crie um ficheiro de workflow. Guarde-o como .github/workflows/security.yml:

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 }}

Passo 4. Integre o branch em main. A action será iniciada automaticamente com o próximo PR.

O que a action faz:

• É executada em cada Pull Request aberto ou sincronizado.
• Analisa as diferenças entre o branch do PR e main.
• Executa o mesmo motor que o /security-review local.
• Publica comentários em linha diretamente nas linhas de código onde identifica uma suspeita.
• Duplica o relatório completo no Job Summary.

Detalhes importantes em permissions:

• pull-requests: write - para publicar comentários em linha.
• contents: read - para ler o código. Sem write. A action não modifica o código; limita-se a comunicar os resultados.

Este conjunto é suficiente para um repositório privado. Num repositório público, pode também especificar actions: read se utilizar workflows reutilizáveis.

Como filtrar falsos positivos e alterar a sensibilidade?#

Tabela completa dos parâmetros de entrada da GitHub Action (fonte: README do repositório):

Exemplo de configuração da filtragem de falsos positivos. Crie o ficheiro .claude/security/false-positives.md:

# Regras de filtragem de falsos positivos para o nosso projeto

- Qualquer `dangerouslySetInnerHTML` dentro de `src/lib/email/layout.ts` é seguro -
  o HTML é montado a partir de modelos fidedignos e passa por `sanitize-html`
  no momento da gravação na base de dados, não no momento da apresentação.
- Não comuniques chaves de API de teste codificadas em `__tests__/fixtures/*.ts`.
  Todas as chaves começam pelo prefixo `sk-test-fake-`.
- A concatenação SQL em `src/lib/admin/migrations.ts` é aceitável - o ficheiro é executado
  apenas como root, e os dados de entrada vêm de variáveis de ambiente.

Ligue-o no workflow:

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

As instruções personalizadas de análise de segurança funcionam de forma semelhante. Crie um ficheiro com regras que sejam especificamente importantes para o seu projeto:

# Verificações adicionais para o nosso projeto

- Qualquer endpoint em `/api/admin/*` tem de verificar a função de administrador
  através de um wrapper partilhado. Sem esse wrapper, a gravidade é HIGH.
- Todos os webhooks de YooKassa / CloudPayments têm de verificar a assinatura antes de
  analisar o corpo. Sem isso, a gravidade é HIGH.
- Os tokens de magic link têm de ser de utilização única (marcados como utilizados após
  o primeiro pedido válido). Os tokens reutilizáveis têm gravidade MEDIUM.

Isto já não é uma predefinição da Anthropic: está a transmitir a sua experiência sobre o projeto através de regras que o Claude aplica sempre. Essa é a essência de “metodologia acima do modelo”.

Para saber mais sobre metodologia de contexto para Claude, consulte os guias “Como configurar CLAUDE.md” e “O Second Brain no Claude Code”.

O que é que o Claude NÃO deteta e porquê: limitações honestas?#

A Anthropic indica claramente o que está desativado por predefinição e porquê (fonte: README do repositório):

• Negação de serviço - demasiado ruído, quase sempre com baixo impacto.
• Problemas de limitação de pedidos - tratados ao nível da infraestrutura, não no código.
• Esgotamento de memória / CPU - o mesmo.
• Validação genérica de entradas sem impacto comprovado - validar cada campo cria uma avalanche de falsos positivos.
• Open redirect - muitas vezes é um comportamento intencional.

O que uma revisão de código isolada não consegue verificar por completo sem evidência de execução ou implementação:

• Configuração do servidor de produção. Cabeçalhos NGINX, políticas CORS, definições TLS, portas de escuta. É necessário verificá-los manualmente num ambiente de staging.
• Condições de corrida. Por exemplo, gastar duas vezes durante pedidos simultâneos de reembolso. A análise estática pode sinalizar padrões suspeitos, mas o comportamento concorrente continua a exigir testes.
• Falhas de lógica de negócio nos pagamentos. Se o total da encomenda for calculado no cliente e simplesmente enviado ao fornecedor de pagamentos, a gravidade é HIGH, mas o Claude nem sempre deteta este padrão sem contexto explícito sobre o funcionamento esperado do pagamento.
• IDOR ao nível da base de dados. Se a consulta SELECT * FROM orders WHERE id = $1 não verificar WHERE user_id = $session.userId, o Claude deteta-o frequentemente. Mas, se a verificação for implementada através de middleware ORM e o Claude não conseguir ver o fluxo completo de dados, poderá não a detetar.
• Resistência a engenharia social / phishing. Não tem qualquer relação com o código.

Use /security-review como revisão estática inicial. Complete-a com testes dinâmicos em staging, verificações de funções e permissões, SAST pertinente e revisão da configuração efetivamente implementada. Não se estabelece aqui uma percentagem medida de cobertura.

Decida o âmbito e a periodicidade de uma avaliação externa segundo os riscos e as alterações do sistema. Nem um comando nem uma auditoria externa periódica estabelecem cobertura de segurança de 100%.

Como o autor do material original fez uma revisão de segurança num projeto vibe#

O que surgiu. Um retrato típico de um projeto vibe médio na fase “funciona em produção, mas ainda não foi revisto”: várias suspeitas sobre o fluxo de autenticação, a lógica de processamento dos webhooks da integração de pagamentos, o tratamento de carregamentos de ficheiros e algumas notas específicas sobre o tratamento de HTML durante a apresentação. Não descrevo publicamente os pormenores; algumas recomendações já foram aplicadas e outras ainda estão em PR. Neste projeto relatado, a análise inicial foi útil e rápida; não estabelece uma percentagem de cobertura da auditoria nem um tempo geral de conclusão.

O que descartei como falsos positivos:

• Conclusões sobre DoS através de expressões regulares na validação de entradas - a carga real não incide sobre essas expressões regulares.
• Uma conclusão sobre uma chave de API codificada - era uma chave de teste com o prefixo explícito fake- em fixtures.

Quanto tempo demorou. A execução demorou 4 minutos. A revisão do relatório levou 25 minutos. A aplicação das correções, com testes, demorou cerca de uma hora. Total: cerca de hora e meia desde “comecei” até “está tudo em main”. Um pentest externo com o mesmo âmbito demora uma semana de calendário e custa dezenas de vezes mais.

Conclusão principal. O /security-review não substitui um pentest externo. Pode identificar problemas úteis ao nível do código, como na análise de quatro minutos relatada pelo autor. Reveja e teste as correções e verifique separadamente o comportamento em execução e a configuração implementada; a análise não elimina o risco de segurança do projeto.

Como integrar o /security-review na rotina antes do commit?#

O hook antes apresentado com git_commit, --severity HIGH e --fail-on-find não é uma receita funcional documentada e não deve ser usado como barreira de segurança. Este artigo não fornece um hook local verificado para bloquear commits. A GitHub Action oficial acima fornece resultados automáticos nos PR; não infira que bloqueia commits ou integrações só por comentar um PR.

Encontra uma explicação completa dos hooks no guia “Hooks no Claude Code”.

Uma alternativa com routines consiste em criar uma rotina pre-deploy-check que executa /security-review + npm run build + npm run test com um único comando. Encontra materiais adicionais na documentação da Ailoot.

Se utilizar servidores MCP, pode integrar as conclusões do /security-review num sistema de incidentes (Sentry, Linear, Notion), para que cada ocorrência com gravidade HIGH se transforme automaticamente num ticket.

Perguntas frequentes sobre /security-review#

Quanto custa uma execução? Depende da dimensão do projeto. No meu projeto com 30K linhas, uma execução utiliza cerca de $0.30-0.50 do saldo da API. Um grande repositório empresarial com um milhão de linhas custa até $5-8 por execução. São dezenas de vezes menos do que qualquer subscrição de um scanner SaaS.

Com que frequência devo executá-lo localmente? No mínimo, antes de cada lançamento em produção. Melhor ainda, antes de cada PR. Considere também executá-lo antes de commits e PRs significativos. Este artigo não fornece um hook automático verificado para bloquear commits.

Com que stacks funciona? Com qualquer uma que o Claude consiga ler. Segundo as observações do autor, estas foram verificadas: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. A qualidade é inferior em linguagens muito exóticas (Erlang, Elixir, Clojure), mas encontrará alguma coisa.

O que devo fazer se o Claude encontrar sempre a mesma “vulnerabilidade”, apesar de ela não o ser? Adicione-a a false-positive-filtering-instructions com uma explicação de “porque é seguro”. O Claude deixará de a comunicar nas execuções futuras.

Posso executá-lo apenas em ficheiros específicos? Localmente, sim: basta executar /security-review src/lib/auth/*.ts. Na GitHub Action, só é verificada a diferença do PR atual, que normalmente corresponde ao que se entende por “ficheiros específicos”.

Fontes#

Encontra materiais adicionais na documentação da Ailoot.