# Encontre vulnerabilidades de segurança no código com IA

URL: https://agentvera.dev/pt/blog/find-security-vulnerabilities-with-ai/ · Publicado: 2026-10-27

Audite seu código com um agente de IA: classes OWASP, varredura de segredos e dependências, /security-review, falsos positivos e correções com teste de regressão.

**Resumo:**

- Rode primeiro os scanners determinísticos e baratos (gitleaks, npm audit ou pip-audit, Semgrep) e depois aponte um agente de código para uma classe de vulnerabilidade por vez, rastreando o fluxo real dos dados.
- No Claude Code, /security-review analisa as mudanças da sua branch em relação à branch padrão; o plugin security-guidance revisa o código enquanto o Claude escreve.
- Trate cada achado como uma alegação: peça file:line, a origem da entrada e um caminho alcançável, corrija com um teste de regressão que falhe antes e rotacione qualquer segredo vazado antes de limpar o histórico.

Para encontrar vulnerabilidades de segurança no seu código com IA, rode primeiro os scanners determinísticos rápidos (segredos, dependências, regras estáticas) e depois dê a um agente de código uma classe de vulnerabilidade por vez, pedindo que ele rastreie como a entrada não confiável percorre o código. Trate cada achado como uma alegação a verificar, corrija com um teste de regressão e mantenha o agente longe de segredos reais o tempo todo.

Este guia trata de auditar **o seu próprio código**, de forma defensiva. Se você quer saber como impedir que o próprio agente cause estragos (prompt injection, comandos destrutivos, servidores MCP maliciosos), leia antes [segurança de agentes de código com IA](/pt/blog/ai-coding-agent-security/ "Segurança de agentes de código com IA"); este post parte do princípio de que essas proteções já estão no lugar. Os nomes de ferramentas e comandos abaixo seguem a documentação oficial de outubro de 2026.

## No que uma auditoria com IA é boa, e no que não é

Scanners estáticos e agentes de código encontram bugs diferentes, e é por isso que você quer os dois.

| | Scanners determinísticos | Agente de código |
| --- | --- | --- |
| Ponto forte | Padrões conhecidos, versões de pacotes sabidamente vulneráveis, formatos de segredos | Lógica: quem pode chamar esta rota, de onde vem este valor, o que uma verificação esqueceu |
| Ponto fraco | Não enxergam regra de negócio; barulhentos em padrões seguros | Falsos positivos, problemas não detectados, respostas diferentes a cada execução |
| Custo | Segundos, repetível | Tokens, mais lento, não repetível |
| Melhor uso | Gate de CI em toda mudança | Auditoria focada em áreas de risco e código novo |

Um agente brilha em casos como um endpoint que verifica se você está logado, mas nunca verifica se o pedido que você está lendo é seu. Nenhuma regex vê isso. Por outro lado, um agente não vai perceber com confiabilidade que o `lodash` do seu lockfile tem três anos; o `npm audit` vai.

O que nenhum dos dois faz: testar o sistema em execução. Um agente lê o código do seu checkout. Um storage na nuvem mal configurado, uma regra de firewall ou um token vazado num log de chat ficam fora do alcance dele.

## Antes de começar: um ambiente seguro

Uma auditoria de segurança é uma tarefa de muita leitura, então monte o ambiente assim.

- **Trabalhe numa branch ou num [git worktree](/pt/blog/git-worktree-parallel-agents/ "Git worktrees para agentes em paralelo").** A auditoria e as correções devem ser fáceis de revisar e fáceis de descartar.
- **Comece somente leitura.** No Claude Code, use o plan mode (Shift+Tab ou `/plan`) para a auditoria em si; no Codex, `/permissions` → Read Only ou `--sandbox read-only`. Só libere edições na hora de corrigir.
- **Mantenha os segredos fora de alcance.** Nunca cole chaves, tokens ou o conteúdo do `.env` num prompt. Se o agente precisa saber que uma variável existe, o nome basta. Um `.env.example` com valores falsos é o que ele deve ler.
- **Use credenciais de desenvolvimento.** Se o agente roda seus testes, esses testes devem falar com um banco local ou de staging com chaves descartáveis, nunca com produção.

## Passo 1: rode os scanners determinísticos

Eles levam segundos e dão ao agente pistas concretas. Todos podem ser rodados localmente de graça.

```bash
# Secrets in git history and in the working tree (gitleaks v8.19+)
gitleaks git -v .
gitleaks dir -v .

# Known-vulnerable dependencies
npm audit --audit-level=high
pip-audit -r requirements.txt

# Static analysis rules for your languages
semgrep scan --config auto
```

Algumas observações da documentação oficial:

- O **gitleaks** dividiu o antigo comando `detect` em `git` (varre commits) e `dir` (varre arquivos) na v8.19.0; os comandos antigos ainda funcionam, mas não aparecem na ajuda.
- No **npm audit**, `--audit-level` só muda o código de saída, não o relatório. `npm audit fix` faz uma instalação de verdade; `npm audit fix --force` pode instalar atualizações SemVer-major, então não rode às cegas.
- O **pip-audit** sem argumentos audita o ambiente Python atual; `-r` audita um arquivo de requirements.
- O **Semgrep** com `--config auto` busca regras adequadas ao seu projeto no Semgrep Registry, então precisa de acesso à rede. Adicione `--error` para sair com 1 quando houver achados, que é o que você quer no CI.

Salve a saída num arquivo. No passo 3 você vai entregá-la ao agente em vez de redigitar tudo.

## Passo 2: audite uma classe de vulnerabilidade por vez

“Encontre bugs de segurança neste repositório” rende uma lista rasa. Um prompt focado por classe rende análise de verdade. O [OWASP Top 10:2025](https://top10.owasp.org/2025 "OWASP Top 10:2025") é um bom mapa; estas são as classes que vale auditar primeiro numa aplicação web típica:

| Classe | O que pedir para o agente rastrear | Sinal típico |
| --- | --- | --- |
| Controle de acesso quebrado | Toda rota que lê ou altera um registro: ela verifica se o registro pertence a quem chama? | `findById(req.params.id)` sem filtro de dono ou tenant |
| Injeção (SQL, shell, XSS) | Todo lugar onde a entrada do usuário chega a uma query, a um comando de shell ou a HTML | Concatenação de strings em SQL, `exec` com entrada, renderização de HTML cru |
| Falhas de autenticação | Login, sessão, redefinição de senha e tratamento de tokens | Tokens de redefinição que nunca expiram, falta de rate limit no login |
| SSRF | Toda requisição do lado do servidor cuja URL vem do usuário | `fetch(req.body.url)` sem allow list |
| Segredos no repositório | Chaves hardcoded, tokens em config, credenciais em testes | Strings com cara de chave; o gitleaks será mais confiável |
| Cadeia de suprimentos | Dependências, scripts de instalação, permissões de workflows de CI | Actions sem versão fixada, `permissions:` amplas nos workflows |

Um prompt que funciona, em plan mode:

```text
Audit this repository for broken access control. Do not edit files.

1. List every HTTP route that reads, updates or deletes a record by ID.
2. For each one, find where the caller's identity comes from and whether
   the query is limited to records the caller owns (user or tenant).
3. Report only routes where you can show the missing check.

For each finding give: file:line, the route, where the ID comes from,
why the existing middleware does not cover it, and a severity
(high/medium/low). If you are unsure, say so instead of guessing.
```

Repita o mesmo formato para injeção, autenticação e SSRF. Uma classe por conversa mantém a [janela de contexto](/pt/glossary/context-window/ "O que é uma janela de contexto") focada, e você pode rodá-las em paralelo em sessões separadas.

Para injeção, ajuda dizer ao agente como é o “seguro” na sua stack, para ele não marcar toda query:

```text
We use parameterized queries through db.query(sql, params) everywhere.
Find any place that builds SQL, shell commands or HTML from request
data without going through db.query params, execFile with an argument
array, or the template engine's escaping. Ignore code under tests/.
```

## Passo 3: use as revisões de segurança integradas

Vários agentes já trazem uma revisão de segurança que você não precisa escrever.

**`/security-review` do Claude Code.** A referência oficial de comandos o descreve como uma análise das mudanças da sua branch atual em busca de vulnerabilidades: ele revisa o diff entre a sua branch e a branch padrão do `origin` e procura riscos como injeção, problemas de autenticação e exposição de dados. Precisa de um remote `origin`. Cobre apenas as mudanças da sua branch, então rode antes de abrir um pull request. O repositório `claude-code-security-review` da Anthropic explica como personalizá-lo: copie o `security-review.md` dele para `.claude/commands/` e acrescente suas próprias regras, por exemplo quais padrões são seguros na sua base de código.

**Plugin security-guidance do Claude Code.** Instalado com `/plugin install security-guidance@claude-plugins-official`, ele revisa o código enquanto o Claude escreve: uma checagem de padrões a cada edição (coisas como `eval(`, `child_process.exec`, `.innerHTML =`), uma revisão de segurança em segundo plano do diff de cada turno e uma revisão mais profunda quando o Claude faz commit. Você pode adicionar regras do projeto em `.claude/claude-security-guidance.md`. A documentação deixa claro que ele não bloqueia escritas e pode deixar problemas passar; é uma camada.

**`/review` do Codex.** O comando de revisão do Codex (e `codex review --uncommitted` ou `--base main` a partir do shell) é um code review geral. Peça explicitamente o foco em segurança se é isso que você quer.

**Extensão de segurança do Gemini CLI.** Instalada com `gemini extensions install https://github.com/gemini-cli-extensions/security`, ela adiciona `/security:analyze` para as mudanças da sua branch e `/security:scan-deps`, que verifica dependências com o OSV-Scanner.

Para código que já existe, e não para as mudanças de uma branch, use os prompts por classe do passo 2. Você também pode passar a saída dos scanners:

```text
Here is the output of semgrep and npm audit in scan-results.txt.
For each finding, check whether it is reachable from user input in
this codebase. Mark each as confirmed, likely false positive or
needs a human, with a one-line reason. Do not edit files.
```

## Passo 4: separe achados reais de falsos positivos

Revisões de segurança com IA soam confiantes estejam certas ou não. Peça evidências, não veredictos:

- **Origem:** por onde entra o valor não confiável? Corpo da requisição, query string, upload de arquivo, webhook?
- **Caminho:** por quais funções ele passa até chegar à chamada arriscada? Peça a cadeia com file:line de cada salto.
- **Proteção:** que validação, escape ou autorização existe nesse caminho, e por que não cobre este caso?
- **Alcançabilidade:** a rota está exposta? Um achado num script de admin morto não é o mesmo que um numa API pública.

Depois, peça uma segunda opinião. Uma sessão nova, ou melhor, outro modelo, deve checar os achados de alta severidade antes de alguém escrever uma correção. Entregue o achado e o código, não o raciocínio do primeiro agente, para que ele não simplesmente concorde. [Code review com IA](/pt/blog/ai-code-review/ "Code review com IA") descreve como pesar os achados e manter esse ciclo sob controle.

Falsos positivos comuns: SQL montado só com constantes, HTML que passa pelo escape automático de um framework, fixtures de teste com chaves falsas e requisições do servidor para uma URL interna fixa. Escreva os padrões seguros no `CLAUDE.md` ou `AGENTS.md` para que as próximas auditorias parem de marcá-los.

## Passo 5: corrija com um teste de regressão

Uma correção de segurança sem teste tende a voltar. Peça o teste primeiro:

```text
Fix the missing ownership check in GET /api/orders/:id (finding #2).

1. First write a test where user A requests user B's order and expect
   a 404. Run it and show me that it fails.
2. Then add the check in the smallest way that fits our existing
   middleware. Don't change unrelated code.
3. Run the full test suite and show me the diff.
```

O teste que falha e depois passa prova que o bug existia e que a correção o cobre. Mantenha cada correção em seu próprio commit com uma mensagem clara, para que o histórico explique o que estava errado. Para o hábito geral de corrigir com teste primeiro, veja [depurar código com IA](/pt/blog/debug-code-with-ai/ "Depurar código com IA").

A mesma disciplina vale para achados de dependências: atualize um pacote por vez, rode os testes, leia o changelog procurando mudanças incompatíveis. Um `npm audit fix --force` em massa é o jeito de uma auditoria virar uma queda do sistema.

## Se você encontrar um segredo real no repositório

Este é o único caso em que a ordem dos passos importa:

1. **Rotacione o segredo primeiro.** Revogue a chave no provedor e emita uma nova. Depois que um segredo foi enviado com push, considere-o comprometido; apagar o arquivo não desfaz o vazamento.
2. **Coloque o novo segredo no seu gerenciador de segredos ou no ambiente**, não de volta no código.
3. **Depois limpe**: remova-o do código e decida com a equipe se vale reescrever o histórico. Reescrever o histórico não adianta se a chave não foi rotacionada.
4. **Evite o próximo** com um hook de pre-commit. O gitleaks documenta esta entrada no `.pre-commit-config.yaml`:

```yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks
```

Deixe o agente ajudar nos passos 2 a 4, mas nunca colando o segredo na conversa. “A chave do Stripe em src/config.ts precisa ir para uma variável de ambiente chamada STRIPE_SECRET_KEY” é tudo de que ele precisa.

## Torne isso contínuo

Uma auditoria pontual envelhece assim que chega código novo. Coloque as checagens determinísticas no CI e deixe a revisão por IA para os pull requests:

```yaml
# .github/workflows/security.yml (excerpt)
- run: npm audit --audit-level=high
- run: semgrep scan --config auto --error
```

Para uma passada de IA em cada pull request, a GitHub Action `anthropics/claude-code-security-review` da Anthropic comenta os achados no PR. A entrada obrigatória é `claude-api-key`; as opcionais incluem `comment-pr`, `exclude-directories` e `false-positive-filtering-instructions`. Se você já roda o Claude no GitHub Actions, [Claude Code GitHub Actions](/pt/blog/claude-code-github-actions/ "Claude Code GitHub Actions") cobre a configuração e o tratamento de segredos.

## Fazendo isso com o AgentVera

O AgentVera é um app desktop para macOS, Windows e Linux que roda Claude Code, Codex, Gemini CLI e outros agentes de CLI lado a lado em terminais reais. Para auditorias de segurança, isso facilita algumas configurações:

- **[Workspace](/pt/features/workspace/ "Workspace"):** coloque um auditor somente leitura (permissão em Ask) ao lado de um corretor trabalhando num worktree, e um terceiro painel com outra CLI como segunda opinião. Cada agente mantém o próprio nível de permissão.
- **[Code review](/pt/features/code-review/ "Code review"):** ative a revisão ao fim de cada turno nas configurações do projeto, e um modelo Claude à sua escolha revisa as mudanças do corretor; os achados vêm com severidade e um link file:line e podem voltar para o agente, no máximo duas rodadas seguidas.
- **[Review inbox](/pt/features/review-inbox/ "Review inbox"):** o trabalho concluído espera em cartões, e mudanças arriscadas são sinalizadas: código de autenticação e segurança, arquivos de dependências, arquivos de CI e infraestrutura, `.env` e mudanças sem testes.
- **[Verify](/pt/features/verify/ "Verify") (Pro e Team):** um verificador separado, somente leitura, confere o resultado contra os critérios do seu pedido, como “existe um teste de regressão e ele falha sem a correção”.
- **[Agentes no Docker](/pt/features/agents-in-docker/ "Agentes no Docker"):** rode o Claude Code ou o Codex num contêiner que só enxerga a pasta do projeto, para que arquivos e chaves SSH de outros lugares da sua máquina fiquem fora de alcance durante a auditoria.
- **[Checkpoints](/pt/features/checkpoints-and-replay/ "Checkpoints e replay"):** cada turno vira um snapshot, então uma correção que deu errado se desfaz com um clique.

A grade, os worktrees, o code review e os agentes no Docker estão no plano gratuito. [Baixe o AgentVera](/pt/download/ "Baixe o AgentVera") e faça sua primeira auditoria numa branch.

## Erros comuns

- **Pedir “todos os problemas de segurança” de uma vez.** Você recebe um checklist genérico. Audite uma classe por vez.
- **Corrigir antes de verificar.** Um falso positivo “corrigido” acrescenta código que ninguém entende. Consiga a evidência primeiro.
- **Colar segredos para “ver se são válidos”.** Nunca. Rotacione.
- **Rodar `npm audit fix --force` num loop de agente.** Atualizações major quebram coisas de formas que parecem não ter relação.
- **Tratar uma revisão de IA limpa como garantia.** Significa só que o agente não achou nada desta vez. Mantenha os scanners no CI.
- **Deixar o auditor editar.** Mantenha a auditoria somente leitura e as correções numa etapa separada e revisada.

## Concluindo

Comece com o gitleaks, o auditor de dependências e o Semgrep. Depois audite uma classe OWASP por vez com um agente somente leitura, pedindo evidência com file:line e um caminho alcançável. Rode o `/security-review` (ou o equivalente do seu agente) antes de cada pull request, peça para uma segunda sessão checar os achados graves e corrija cada um com um teste de regressão que falhe primeiro. Se um segredo vazar, rotacione-o antes de qualquer outra coisa. Quando estiver pronto para colocar agentes trabalhando nas correções, [pair programming com IA](/pt/blog/ai-pair-programming/ "Pair programming com IA") mostra como você continua no lugar do navegador. Se tudo isso é novo para você, [aprender a programar com IA](/pt/blog/learn-to-code-with-ai/ "Aprender a programar com IA") é um ponto de partida mais tranquilo.

## Perguntas frequentes

**Um agente de código com IA consegue encontrar vulnerabilidades de segurança?** Sim, principalmente falhas de lógica que scanners baseados em padrões não pegam, como uma rota de API sem verificação de propriedade. Ele também gera falsos positivos e deixa coisas passar, então trate a saída como pistas a verificar e continue rodando scanners determinísticos em paralelo.

**O que o /security-review faz no Claude Code?** Ele analisa as mudanças da sua branch atual em busca de vulnerabilidades, comparando com a branch padrão do remote origin, e aponta riscos como injeção, problemas de autenticação e exposição de dados. Precisa de um remote origin. Revisa o diff, não o repositório inteiro.

**Devo passar meu arquivo .env para o agente verificar meus segredos?** Não. Nunca cole segredos reais em um prompt. Use um scanner de segredos como o gitleaks para encontrá-los, deixe o .env fora do que o agente lê e, se uma chave real já foi commitada, rotacione-a primeiro e só depois limpe o histórico.

**Como lidar com falsos positivos de uma revisão de segurança feita por IA?** Peça evidências para cada achado: arquivo e linha, de onde vem a entrada não confiável, o caminho até a chamada arriscada e por que a validação existente não cobre o caso. Faça uma sessão nova ou outro modelo verificar os achados de alta severidade antes de mudar o código.

**Uma auditoria de segurança com IA substitui um teste de invasão?** Não. Ela lê o código-fonte do seu checkout e encontra falhas prováveis cedo e a baixo custo. Não testa o sistema em execução, a configuração nem a infraestrutura. Para qualquer coisa que lide com dinheiro, saúde ou dados pessoais, inclua uma revisão profissional.

---

**Sobre o AgentVera.** AgentVera é um app desktop para macOS, Windows e Linux, desenvolvido pela Solviera Teknoloji. Ele roda 18 agentes de programação com IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) lado a lado, por projeto, em terminais reais com as instalações e logins de CLI do próprio usuário. O plano gratuito tem agentes ilimitados. Baixar: https://agentvera.dev/pt/download/ · Preços: https://agentvera.dev/pt/pricing/