LLMs para segurança de código: o framework de 6 passos da Anthropic

A Anthropic soltou ontem um post que, na minha visão, vai virar referência obrigatória pra quem trabalha com segurança e IA. Em resumo: até 22 de maio de 2026 eles já reportaram 1.596 vulnerabilidades em projetos open source usando LLMs como Claude — e apenas 97 foram corrigidas até agora. O ponto que mais me chamou atenção não é o volume bruto. É a tese: a barreira pra achar bug saiu do caminho. O gargalo virou verificar, triar e patchear sem queimar o time em falso positivo.

Os autores (Eugene Yan e Henna Dattani, com colaboradores da equipe de security da Anthropic) destilaram seis passos que repetem o que times de offensive security descobriram nas trincheiras. Vou destrinchar cada um com leitura de quem programa todo dia, mostrar o que dá pra reaproveitar em projeto pequeno e onde está o repositório-modelo pra você clonar hoje.

Por que o jogo mudou: descoberta ficou barata, verificação virou problema

A frase exata do post é: "discovery is now straightforward to parallelize, and the bottleneck has shifted to verification, triage, and patching". Tradução prática: se você tem orçamento de token, dá pra spawnar agentes paralelos varrendo diferentes superfícies de ataque do seu código e descobrir falha em volume. O problema é que a maioria não é explorável — e times que tentaram "forçar" a descoberta caíram em retornos decrescentes, com toneladas de duplicatas se cancelando mutuamente.

Esse padrão de paralelizar agentes vira viável agora que o Claude Code ganhou orquestração nativa. Já comentei isso em detalhe no post sobre Dynamic Workflows no Claude Code com passo a passo — quem ainda não leu, vale combinar a leitura com esse aqui. O conceito da Anthropic é: dividir a superfície de ataque por endpoint, componente ou módulo, e colocar vários agentes rodando independentes em cada partição.

Passos 1 e 2: threat model e sandbox — o investimento que se paga

O passo 1 é definir o que conta como vulnerabilidade pro seu sistema. Parece óbvio, mas o post traz a sentença que matou pra mim: "a causa mais comum de falso positivo é o modelo não entender suas trust boundaries". Sem threat model, o LLM acha "bug" em comportamento intencional do seu app. Inputs do threat model: arquitetura, requirements de segurança, histórico de git, políticas de dependência (eles citam vLLM, SQLite e ImageMagick como exemplos), e os pontos de entrada do sistema.

O passo 2 é sandbox. Aqui a recomendação é cirúrgica: container isolado pro agente que lê código, microVM (Firecracker) ou VM completa pra rodar o alvo, zero credenciais disponíveis no ambiente (sem ~/.aws, ~/.ssh, .env), rede só por proxy local até a API do modelo, e snapshots reproduzíveis. O ROI vem de um time citado no post: depois de seis semanas, "a maior alavanca de eficácia foi dar pro modelo bancada de teste e fazer ele rodar o PoC". Sandbox é o que separa "o modelo achou" de "o modelo provou".

Passo 3: Discovery — prompt curto, contexto rico, agentes paralelos

Esse é o passo onde a maioria erra por excesso de zelo. A Anthropic é direta: "forneça o objetivo e o contexto, mas deixe o 'como escanear' pro modelo". Ser prescritivo demais limita o que ele tenta. As recomendações práticas que eu tiro: (1) pedir por uma classe específica de vulnerabilidade por vez (SSRF, IDOR, prototype pollution, etc) é melhor que pedir tudo de uma vez; (2) defina o formato de saída — relatório estruturado com campos fixos vence texto livre toda vez; (3) inclua uma "escape hatch" que deixa o modelo desistir cedo de hipóteses fracas, em vez de inventar.

E paralelize. Vários agentes na mesma partição não convergem pra mesma resposta, o que é uma feature: cada um explora um ângulo diferente. Depois você faz um "system-level pass" usando os achados parciais como contexto. Pra entender melhor por que ter o modelo "vestindo" papéis diferentes funciona, vale ler o que é um harness de agente de IA e como ele transforma modelo em agente — é exatamente o tipo de coordenação que o framework presume.

Passos 4 e 5: verificação adversarial e triagem por root cause

Verificação é a parte onde o framework brilha. Discovery otimiza pra recall (achar tudo que pode ser bug). Verificação otimiza pra precisão (cortar o que não é). Misturar os dois mata os dois — o post mostra que pedir pro agente de discovery filtrar os próprios achados o leva a descartar verdadeiros positivos. A solução: agente verificador fresco, em container novo, sem estado compartilhado, com framing adversarial — "assuma que cada finding é falso positivo e prove que está errado". Times que rodaram múltiplos verificadores independentes e usaram majority vote cortaram pela metade a taxa de findings não-exploráveis. Um time chegou em 90% de exploráveis com threat model bem documentado.

A triagem (passo 5) é dedup + ranking. Dedup deve ser por root cause, não por similaridade sintática — duas chamadas diferentes pra mesma função vulnerável são o mesmo bug. O ranking segue critérios concretos: alcançabilidade a partir de entrada real, controle do atacante sobre os inputs, pré-condições, autenticação exigida, leitura vs. escrita, blast radius. A baseline que eles dão é simples: zero pré-condições e remoto não autenticado = crítico ou alto; uma ou duas pré-condições, ou caminho autenticado = médio; três ou mais, ou só local = baixo.

Passo 6: Patching — a parte que ninguém leva a sério o suficiente

Patches gerados por LLM falham de jeitos previsíveis: corrigem o sintoma em vez da causa, bloqueiam input legítimo junto com o malicioso, ou removem acesso a dependência que outro fluxo precisa. A receita da Anthropic é "a menor mudança que fecha a root cause — nada de refactor, drive-by cleanup ou reformatação". E depois rodar uma escada de validação: (1) build e novos testes passam; (2) tentar reproduzir o PoC original — tem que falhar agora; (3) suite de testes original passa sem regressão; (4) re-ataque: um agente de discovery fresco tenta achar a mesma falha de novo.

E procurar variantes em dois níveis: (1) mesmo padrão em outros call sites — o mesmo código bugado em outro lugar; (2) mesma classe de bug, em código adjacente. Se você não fizer essa caça de variantes, o time vai patchear o mesmo problema três vezes ao longo do trimestre.

Por que isso importa pra dev e empresa brasileira

Três tiradas práticas: (1) orçamento de scan é só metade do orçamento — você precisa de capacidade de verificar e triar tudo que vai sair do primeiro scan, então budget pra pipeline pós-scan antes de orçar mais scan; (2) o ganho real aparece quando o harness conecta a eventos: bug bounty dispara variant analysis, code review dispara scan, vulnerabilidade confirmada atualiza regra estática; (3) pra quem quer pôr mão na massa hoje, o ponto de partida está aberto — a Anthropic publicou um harness de referência no repositório defending-code-reference-harness no GitHub com skills prontas (threat-model, vuln-scan, triage, patch) e o comando /quickstart pra rodar no Claude Code direto.

Esse padrão casa muito com o case CLUE da própria Anthropic — escrevi sobre ele no post sobre como a Anthropic usa Claude para cibersegurança no case CLUE, que mostra os mesmos princípios aplicados em SOC. Junte os dois e você tem o playbook completo: do código fonte ao incidente em produção.

Conclusão

O framework de 6 passos não é teoria — é destilado do que times reais de offensive security fizeram nos últimos seis meses dentro da Anthropic e em parceiros. Quem ignorar threat model e sandbox vai gastar muito token achando "bug" que não existe. Quem investir nesses dois pilares vai conseguir mover a curva de eficácia rápido. Toda a fundamentação, os exemplos detalhados de prompt e os critérios completos de ranking estão no post oficial da Anthropic sobre usar LLMs pra defender código — leitura obrigatória antes de subir esse pipeline em projeto real.