Quando uma IA faz o trabalho de uma equipe inteira de pentest

Eu já perdi a conta de quantas vezes ouvi que “IA não vai substituir pentesters”. E concordo — parcialmente. O que a Anthropic acabou de liberar no GitHub não substitui ninguém. Mas faz o trabalho bruto de uma equipe de segurança em horas, não semanas.

O repositório se chama defending-code-reference-harness e é, na prática, um pipeline autônomo que solta 7 agentes de IA no seu código-fonte, procurando vulnerabilidades que scanners tradicionais simplesmente não enxergam. Depois encontra, verifica, deduplica, classifica por severidade e ainda gera o patch. Tudo open source. Tudo gratuito.

E antes que você pense “mais um wrapper de LLM”, vale lembrar: usando esse mesmo pipeline, a equipe da Anthropic encontrou mais de 500 vulnerabilidades em projetos open source de produção — bugs que sobreviveram décadas de code review humano. A quantidade total de CVEs reportados já passou de 1.500.

Vamos destrinchar como funciona, o que muda na prática e como você pode rodar no seu próprio código hoje.

O problema que ninguém resolve direito

Ferramentas de análise estática existem há décadas. SAST, DAST, SCA, IAST — a sopa de letrinhas é enorme. E todas elas compartilham o mesmo problema fundamental: pattern matching.

Um scanner como o Semgrep ou o CodeQL procura padrões conhecidos. Se o bug não se encaixa numa regra pré-definida, passa batido. Funciona bem pra pegar SQL injection óbvio ou XSS trivial. Mas vulnerabilidades complexas — race conditions, use-after-free em caminhos obscuros, integer overflows que só aparecem com inputs muito específicos — essas escapam.

O motivo é simples: encontrar bugs complexos exige raciocínio. Um pesquisador de segurança não aplica regex no código. Ele entende a arquitetura, traça o fluxo de dados, formula hipóteses sobre o que pode dar errado e cria inputs maliciosos para testar cada teoria.

É exatamente isso que o pipeline da Anthropic tenta replicar. Não com regras, mas com agentes que raciocinam sobre o código.

A arquitetura: 7 estágios, do build ao patch

O pipeline é dividido em sete estágios sequenciais. Cada um faz uma coisa específica e alimenta o próximo. Vou detalhar cada estágio porque a engenharia aqui é genuinamente interessante.

1. Build — Compilação instrumentada

O primeiro passo é compilar o alvo com AddressSanitizer (ASAN), um detector de erros de memória disponível no Clang e GCC. O ASAN instrumenta o binário para detectar buffer overflows, use-after-free, double-free e outros erros de memória em tempo de execução.

# Exemplo simplificado do Dockerfile de build
FROM ubuntu:24.04
RUN apt-get update && apt-get install -y clang-18 llvm-18
ENV CC=clang-18 CXX=clang++-18
ENV CFLAGS="-fsanitize=address -fno-omit-frame-pointer -g"

O ponto crucial: ASAN só detecta problemas quando o código vulnerável é executado. Se ninguém manda o input certo, o bug nunca aparece. É aí que entram os agentes.

2. Recon — Mapeamento de superfície de ataque

Aqui o Claude analisa o código-fonte e propõe subsistemas de parsing de input para atacar separadamente. Em vez de jogar inputs aleatórios no binário inteiro (como um fuzzer tradicional), o agente identifica pontos de entrada específicos: parsers de formato, handlers de protocolo, deserializadores.

A sacada é que cada subsistema vira um alvo independente. Isso permite paralelização massiva no estágio seguinte.

3. Find — N agentes em paralelo caçam crashes

Aqui a mágica acontece. O pipeline dispara N agentes simultâneos, cada um atacando um subsistema diferente identificado no Recon. Cada agente:

1. Analisa o código do subsistema
2. Formula hipóteses sobre possíveis vulnerabilidades
3. Cria inputs malformados para testar cada hipótese
4. Executa o binário com ASAN ativado
5. Registra qualquer crash

Para um crash ser considerado válido, precisa reproduzir 3 vezes seguidas. Nada de falsos positivos por timing ou estado aleatório.

# Execução do pipeline
bin/vp-sandboxed run meu-projeto \
  --model claude-opus-4-6 \
  --runs 5 \
  --parallel \
  --stream \
  --auto-focus

4. Verify — Reprodução em container limpo

Encontrou um crash? Ótimo. Mas o pipeline não confia na própria execução. Um agente verificador separado pega o input que causou o crash e tenta reproduzi-lo em um container completamente novo, sem nenhum estado residual da execução anterior.

Isso elimina falsos positivos causados por corrupção de memória de testes anteriores ou estado compartilhado entre execuções.

5. Dedupe — Eliminação de duplicatas

Múltiplos agentes rodando em paralelo frequentemente encontram o mesmo bug por caminhos diferentes. O estágio de deduplicação usa um agente juiz que compara os stack traces e as condições de trigger de cada finding para determinar quais são bugs únicos e quais são variações do mesmo problema.

6. Report — Análise de exploitabilidade

Com os bugs únicos confirmados, o pipeline gera um relatório com:

• Descrição da vulnerabilidade
• Severidade (baseada em CWE e CVSS)
• Análise de alcançabilidade (o bug é acessível por input externo?)
• Proof of Concept (o input que causa o crash)
• Recomendação de correção

7. Patch — Geração e validação de fix

O último estágio é ambicioso: o agente gera um patch para corrigir a vulnerabilidade. Mas não para aí. O patch precisa passar em três verificações:

Se qualquer verificação falhar, o agente itera no patch até conseguir ou desistir.

O sandboxing: gVisor e isolamento de rede

Um detalhe que me chamou atenção foi a preocupação com segurança do próprio pipeline. Faz sentido — você está literalmente pedindo para uma IA criar inputs maliciosos e executar código vulnerável. Se não isolar direito, o caçador de bugs vira o bug.

A solução é gVisor, o runtime de containers do Google que intercepta syscalls no nível do kernel. Cada execução roda em um container com:

• Rede isolada (sem acesso à internet, exceto endpoints em allowlist)
• Filesystem read-only (exceto diretórios específicos de output)
• Sem acesso ao host
• Limites de CPU e memória

# Setup do sandbox
./scripts/setup_sandbox.sh
# Instala gVisor, builda imagens dos agentes, verifica isolamento

Na prática: como rodar no seu código

O ramp-up proposto pela Anthropic é de 4 passos, de “Day 1” a “Week 2+”. Vou resumir o fluxo mais realista para quem quer testar.

Passo 1: Análise estática interativa (sem executar código)

Se você não quer rodar o pipeline autônomo inteiro, pode usar apenas os Claude Code Skills — comandos interativos que funcionam dentro do Claude Code:

# Cria um threat model do seu projeto
> /threat-model bootstrap ~/meu-projeto

# Roda scan de vulnerabilidades estáticas
> /vuln-scan ~/meu-projeto

# Faz triage dos findings
> /triage ~/meu-projeto/VULN-FINDINGS.json

# Gera patches
> /patch ./TRIAGE.json --repo ~/meu-projeto

Esses skills são read/write only — não executam código, só analisam arquivos. Perfeitamente seguros para rodar em qualquer codebase.

Passo 2: Pipeline autônomo no projeto canário

O repo vem com targets de teste — projetos deliberadamente vulneráveis para validar o pipeline:

# Setup
python3 -m venv .venv && .venv/bin/pip install -e .
./scripts/setup_sandbox.sh
export ANTHROPIC_API_KEY=sk-ant-...

# Roda no target canário
bin/vp-sandboxed run drlibs \
  --model claude-opus-4-6 \
  --runs 3 \
  --parallel \
  --stream \
  --auto-focus

# Gera patches para os findings
bin/vp-sandboxed patch results/drlibs/<timestamp>/ \
  --model claude-opus-4-6

Passo 3: Customize para seu projeto

O pipeline vem configurado para C/C++ com ASAN, mas pode ser portado para qualquer linguagem. A customização exige responder três perguntas:

# Usa o skill de customização
> /customize use ~/code/meu-servico/{THREAT_MODEL.md,VULN-FINDINGS.json} \
  and ./TRIAGE.md

# Smoke test
bin/vp-sandboxed run meu-servico \
  --model claude-opus-4-6 \
  --runs 1

Os números que importam

A Anthropic não soltou esse framework do nada. Ele é a versão open source do que a equipe interna usa desde o lançamento do Claude Mythos Preview. Alguns números para contextualizar:

• 500+ vulnerabilidades encontradas em projetos open source de produção usando Claude Opus 4.6
• 1.596 vulnerabilidades reportadas ao todo para mantenedores de projetos open source
• 97 patches já aceitos e aplicados (até maio de 2026)
• 2.100+ stars no GitHub em poucos dias

O insight mais importante do blog post da Anthropic é este: a descoberta de bugs agora é trivial de paralelizar. O gargalo real migrou para verificação, triage e patching. Ou seja, encontrar o bug não é mais o problema — é confirmar que é real, classificar a severidade e gerar uma correção que não quebre nada.

Comparando com ferramentas tradicionais

Para quem trabalha com AppSec, vale a comparação direta:

Não estou dizendo que substitui fuzzers ou SAST. O ideal é rodar os três. Mas a camada de raciocínio que o Claude adiciona pega uma classe de bugs que as outras ferramentas simplesmente não alcançam.

O que isso muda para devs e equipes de segurança

Três implicações práticas que eu vejo:

1. Democratização do pentest de código

Até agora, análise profunda de vulnerabilidades exigia ou ferramentas caras (Snyk, Checkmarx, Veracode) ou pentesters especializados que cobram R$ 500+/hora. Um framework open source que roda com uma API key do Claude nivela o jogo para startups, projetos pessoais e mantenedores de open source.

2. Shift-left real, não marketing

A indústria fala de “shift-left security” há uma década. Na prática, a maioria das equipes ainda descobre bugs críticos em produção. Com skills como /threat-model e /vuln-scan rodando direto no terminal do dev, a análise de segurança acontece onde o código é escrito — não semanas depois num relatório de pentest.

3. O bottleneck agora é humano

Se uma IA consegue encontrar 500 bugs em projetos maduros, o problema não é mais “a gente não sabe onde estão os bugs”. O problema é: quem vai revisar, priorizar e aplicar 500 patches? O pipeline tenta automatizar parte disso, mas a decisão final ainda é humana. Equipes de segurança vão precisar de mais gente fazendo triage, não menos.

Limitações que ninguém vai te contar

Antes de sair rodando isso em produção, algumas ressalvas:

• C/C++ only (por padrão): O pipeline usa ASAN, que é específico para linguagens compiladas com memory safety issues. Para Python, JavaScript, Go, Java — você precisa customizar o detector. Não é plug-and-play.

• Custo de API: Rodar N agentes em paralelo fazendo múltiplas chamadas ao Claude Opus consome tokens significativos. Uma execução completa com 5 runs pode custar dezenas de dólares dependendo do tamanho do codebase.

• Não é produto: A Anthropic deixa claro no README — isso é uma referência, não um produto mantido. Se você quer algo production-ready com suporte, eles vendem o Claude Security como serviço gerenciado.

• Requer Docker + gVisor: O setup não é trivial. Você precisa de Docker, gVisor, e permissão para rodar containers privilegiados. Em muitos ambientes corporativos, isso é um blocker.

Como começar em 15 minutos

Se você tem Docker instalado e uma API key da Anthropic, o caminho mais rápido:

# Clone o repo
git clone https://github.com/anthropics/defending-code-reference-harness.git
cd defending-code-reference-harness

# Setup do ambiente Python
python3 -m venv .venv
source .venv/bin/activate
pip install -e .

# Setup do sandbox (precisa de sudo)
./scripts/setup_sandbox.sh

# Configure sua API key
export ANTHROPIC_API_KEY="sk-ant-sua-chave-aqui"

# Rode o quickstart interativo
> /quickstart

O /quickstart é um skill do Claude Code que faz um walkthrough guiado de 30 segundos explicando cada comando disponível.

Para quem só quer testar os skills de análise estática (sem Docker/gVisor):

# Instale o Claude Code se ainda não tem
npm install -g @anthropic-ai/claude-code

# Navegue até o repo clonado
cd defending-code-reference-harness

# Use os skills interativamente
> /threat-model bootstrap targets/canary
> /vuln-scan targets/canary

O repo em números

O projeto é majoritariamente Python (92,7%), com Shell scripts (3,5%) e C (2,5%) para os targets de teste e infraestrutura. A estrutura do repo:

defending-code-reference-harness/
├── .claude/skills/     # Skills interativos (/vuln-scan, /triage, etc.)
├── harness/            # Pipeline autônomo
├── targets/            # Projetos-canário para teste
├── docs/               # Blog post, pipeline details, security docs
├── scripts/            # Setup do sandbox
└── bin/                # CLI executável (vp-sandboxed)

A documentação é surpreendentemente boa. O docs/blog-post.md tem insights valiosos sobre o que a equipe aprendeu rodando o pipeline em dezenas de projetos reais. O docs/customizing.md é um guia passo a passo para portar o pipeline para outras linguagens e detectores.

Por que isso interessa além de segurança

O pattern que a Anthropic usa aqui — múltiplos agentes especializados trabalhando em paralelo com verificação cruzada — é aplicável muito além de segurança. A arquitetura de Recon → Find (paralelo) → Verify → Dedupe → Report → Patch é basicamente um template para qualquer tarefa que envolva:

• Exploração ampla de um espaço de possibilidades
• Verificação rigorosa dos resultados
• Eliminação de duplicatas
• Geração de ação corretiva

Eu não ficaria surpreso se nas próximas semanas aparecessem forks adaptando o mesmo pipeline para code review, performance profiling ou detecção de tech debt.

O repo está em github.com/anthropics/defending-code-reference-harness. Com 2.100 stars em poucos dias e a máquina de marketing da Anthropic por trás, a questão não é se vai virar mainstream — é quando. E se você trabalha com segurança de software, vale dedicar uma tarde para entender o que está acontecendo aqui. O jogo mudou, e quem não se adaptar vai ficar para trás.