Três revisores de segurança de graça pro código da IA

A conta incômoda da engenharia com IA: a quantidade de código que você produz multiplicou, e a sua capacidade de revisar não subiu um milímetro. É nessa diferença que os bugs de segurança moram hoje. Não porque o Claude escreve código especialmente perigoso, mas porque volume sempre foi o que fazia a revisão funcionar — e o volume acabou de quebrar.

A resposta útil não é revisar com mais afinco. É colocar a revisão num lugar onde você não consegue esquecer dela. Três camadas, todas de graça, na ordem em que deveriam disparar.

Camada 1 — antes da edição acontecer

A Anthropic mantém um plugin chamado Security Guidance que não é um comando que você roda. É um hook de PreToolUse: ele intercepta Write, Edit e MultiEdit, varre o código procurando padrões perigosos e te avisa antes da mudança ser aplicada. Está em 235.822 instalações e é verificado pela Anthropic — guarde esses dois dados, eu volto neles no final.

O que ele procura é específico e, em boa parte, familiar:

• Injeção de comando em workflows do GitHub Actions
• Chamadas inseguras de child_process.exec() — ele sugere execFileNoThrow() no lugar
• eval() e new Function()
• Vetores de XSS: dangerouslySetInnerHTML, innerHTML
• Desserialização com pickle em Python
• Injeção de comando via os.system()

Os avisos valem por sessão, então você vê cada um uma vez em vez de ser importunado. Essa decisão de design é o motivo pelo qual ele sobrevive à primeira semana — a ferramenta de segurança que as pessoas mantêm é a que não grita lobo sem motivo.

É a camada mais barata de adotar e a primeira que eu instalaria: custa zero mudança no seu fluxo. Você não precisa lembrar de nada.

Camada 2 — antes do commit

/security-review dentro da pasta do projeto varre o código, explica o que encontrou e — a parte que importa — o Claude consegue aplicar as correções, porque ele já está no terminal com os seus arquivos. A cobertura é o pelotão clássico: injeção de SQL, XSS, falhas de autenticação e autorização, tratamento inseguro de dados, vulnerabilidade em dependências.

Falha de autenticação e autorização é o item interessante dessa lista. É a classe que um linter estruturalmente não acha, porque o bug não é um padrão — é uma checagem que está faltando, e ela só faz sentido contra a intenção da sua aplicação. É exatamente aí que um modelo lendo o código inteiro ganha de um motor de regras.

Camada 3 — antes do merge

A GitHub Action dispara em pull request novo e comenta na linha, com sugestão de correção. Essa é a camada que transforma revisão de segurança numa propriedade do repositório em vez de um hábito do seu melhor engenheiro.

A Anthropic afirma que esses recursos já pegaram vulnerabilidades reais no código deles antes de ir pra produção, e cita duas: uma falha de DNS rebinding num servidor HTTP local, encontrada e corrigida antes do pull request ser mesclado, e uma de SSRF num sistema de proxy de credenciais, sinalizada automaticamente e corrigida. As duas são o tipo de bug que passa pela revisão humana não por descuido do revisor, mas porque ele está lendo um diff, não um modelo de ameaça.

Agora revise o revisor

Essa é a parte que quase todo post sobre plugin pula. Toda skill ou plugin que você instala é um conjunto de instruções que molda o que um agente faz com o seu repositório, as suas credenciais e o seu shell. A instalação é a decisão de confiança.

Repare no que eu disse do Security Guidance: verificado pela Anthropic, 235.822 instalações. Esses dois fatos são o motivo pelo qual eu rodei ele sem ler linha por linha. Nenhum dos dois vale pro plugin médio de marketplace — e "estava no marketplace" não é auditoria.

Três checagens antes de instalar qualquer coisa:

1. Leia o SKILL.md. Inteiro. É um arquivo de texto. Se ele pede pra rodar script remoto ou ler arquivo que não tem nada a ver com a função dele, você percebe em menos de um minuto.
2. Veja quem publicou e quantas pessoas usam. Publicador verificado e número real de instalações são sinais fracos, mas são sinais. Zero instalação e autor anônimo também é sinal.
3. Procure o que ele não vai te contar que faz. Chamada de rede, leitura de credencial, qualquer escrita fora do repositório.

Depois transforme a decisão em estrutura em vez de decidir a cada instalação. Existem duas configurações gerenciadas exatamente pra isso:

{
  "strictKnownMarketplaces": true,
  "blockedMarketplaces": [
    { "source": "github", "repo": "untrusted/plugins" }
  ]
}

strictKnownMarketplaces restringe os plugins aos marketplaces conhecidos da Anthropic; blockedMarketplaces bloqueia fontes específicas. As duas são chaves de managed settings — o que significa que, se você lidera um time, essa é uma decisão que você toma uma vez por todo mundo, em vez de confiar no julgamento de cada engenheiro numa sexta à tarde.

Faça isso hoje

Instale o plugin Security Guidance — ele não muda nada em como você trabalha e começa a pegar eval() e innerHTML na hora. Depois abra o último plugin ou skill que você instalou e leia o SKILL.md de verdade. Se você não conseguir dizer em voz alta o que aquilo tem permissão de fazer, você achou o seu problema real — e não é o que o plugin estava procurando.

Fontes

• Anthropic — Security Guidance plugin
• Anthropic — Automate security reviews with Claude Code
• Claude Code docs — Settings