Revisão de segurança com o Claude Opus 5.5: o que dá para achar no código e o que continua sendo trabalho humano

Código que funciona e código seguro são duas coisas diferentes, e os benchmarks do modelo novo mostram que a distância entre as duas segue grande

Fala aí, beleza? A Anthropic lançou o Claude Opus 5.5 em 22 de setembro de 2026, primeiro modelo da família 5.5, com foco declarado em programação, cenários agênticos, análise e segurança

O que isso muda numa leitura de segurança de código? Muda bastante no custo e no escopo do que dá pra varrer de uma vez, muda pouco no fato de que a decisão de risco continua sendo sua…

O que mudou com o Claude Opus 5.5 na frente de segurança

O identificador na API é claude-opus-5-5

O preço de tabela é de US$ 4 por milhão de tokens de entrada e US$ 20 por milhão de tokens de saída, uma queda de 20% em relação ao Opus 5

Janela de 1 milhão de tokens de contexto por padrão, sem header beta, e até 128 mil tokens de saída máxima

Tem também um modo rápido (fast mode), até 2,5x mais veloz, a US$ 8 por milhão de entrada e US$ 40 por milhão de saída

E o item que ninguém olha e que pesa MUITO em varredura de repositório: leitura de cache a US$ 0,20 por milhão de tokens, 60% menos que no Opus 5

Por que o cache importa aqui? Porque revisão de segurança agêntica relê as mesmas coisas várias vezes: o mesmo arquivo de configuração, o mesmo módulo de autenticação, o mesmo schema. Se a releitura é barata, o agente pode ir e voltar no código sem que a conta explode

E aí entra um segundo número que confunde bastante gente: a Anthropic afirma que o Opus 5.5 sai cerca de 40% mais barato pra rodar que o Opus 5, além de gerar saída mais de 30% mais rápido

Calma, 20% e 40% não são a mesma conta. Os 20% são a queda do preço de tabela por token. Os 40% são a estimativa da própria Anthropic pro custo total de rodar o trabalho, que é outra medida

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Outro detalhe que pega gente distraída: o Opus 5.5 começa em esforço (effort) medium por padrão, enquanto os outros modelos que suportam effort começam em high (o Opus 4.7 usa xhigh). A Anthropic afirma que o Opus 5.5 em medium iguala ou supera o Opus 5 em high nas avaliações de código e trabalho de conhecimento

No Claude Code, o nível de esforço se ajusta pelo comando /effort ou pelo seletor /model

Tome cuidado! Níveis de esforço salvos não são herdados ao migrar pro Opus 5.5: o modelo inicia no padrão dele. Depois de atualizar, reconfira com /effort

A partir do Claude Code 2.1.280, de 22 de setembro de 2026, o Opus 5.5 virou o Opus padrão. Na mesma release, o padrão dos planos Pro e Team Standard mudou de Sonnet para Opus

Se você tem script ou integração antiga apontando pra um modelo Claude já aposentado, esse é um bom momento pra conferir

Que tipos de problema aparecem numa leitura de código

A revisão automatizada de segurança do Claude Code procura, de forma declarada: injeção de SQL, XSS, falhas de autenticação, tratamento inseguro de dados e vulnerabilidades de dependências

Já o plugin security-guidance, que age enquanto o código está sendo escrito, mira injeção, desserialização insegura, APIs de DOM inseguras e também casos como criptografia fraca, que casamento simples de string não detecta

Repara no padrão: tudo ali é coisa que está escrita no código

É como revisar um contrato lendo o contrato: dá pra ver a cláusula esquisita, o valor errado, o campo em branco. Não dá pra saber se a outra parte vai cumprir

O que a leitura pega bem:

• entrada que chega e vai direto pra uma query, um comando de shell ou o DOM, sem passar por validação
• coisa sensível escrita literalmente no arquivo, que é o caso clássico do segredo hardcoded
• checagem de permissão que existe em um caminho e falta no outro, quando os dois caminhos estão visíveis no mesmo diff
• dependência com vulnerabilidade conhecida
• desserialização de dado que veio de fora
• criptografia frouxa, do tipo algoritmo errado pra tarefa errada

O que NÃO se resolve lendo:

• comportamento em runtime, com carga real, sessão real e dado real
• regra de negócio: se o usuário A deveria poder ver o recurso do usuário B é decisão de produto, não de sintaxe
• configuração de infra que não vive no repositório
• cadeia de chamadas que atravessa serviços diferentes, cada um em um repo diferente

Uma ferramenta de leitura te dá candidatos, não um veredito

Se você nunca pôs o Claude pra achar falha de segurança no seu código, vale começar pelo comando embutido antes de partir pra varredura grande

/security-review, plugin Claude Security e security-guidance: qual usar quando

São três coisas diferentes, com naturezas técnicas diferentes, e muita gente trata as três como "o Claude revisa segurança"

A revisão em background do security-guidance é a mais interessante tecnicamente: ela lê o código ao redor, incluindo chamadores, sanitizadores e arquivos relacionados, antes de reportar. Não é só o diff isolado

Como pedir a revisão por área de risco em vez de arquivo por arquivo

Aqui está o ponto que muda o resultado na prática. Pedir "revisa esse arquivo" é o modo mais caro e mais cego de fazer segurança, porque você já decidiu onde o problema está antes de olhar

O plugin Claude Security inverte isso: ele lê o repositório primeiro e depois te oferece o escopo

1. Instale o plugin numa sessão de terminal do Claude Code:

/plugin install claude-security@claude-plugins-official

2. Se aparecer erro de marketplace não encontrado, adicione o marketplace oficial e tente a instalação de novo:

/plugin marketplace add anthropics/claude-plugins-official

Esse é o erro comum número um, e ele assusta sem motivo: não é problema no plugin, é só o marketplace que ainda não estava registrado na sua máquina

3. Rode o plugin e escolha a opção Scan codebase:

/claude-security

4. Deixe ele ler o repositório antes de responder qualquer coisa. Depois da leitura, o plugin oferece o repositório inteiro ou uma área focada, informando a contagem de arquivos e o custo relativo de cada opção

5. Não sabe qual área escolher? Responda I don’t know: nesse caso o plugin escolhe um padrão adequado ao tamanho do repositório. Sério, use isso em vez de chutar

6. Precisa de escopo menor, do tipo "o que entrou essa semana"? Aponte a varredura pro diff de um branch, o diff de um pull request ou um único commit

7. Com o relatório na mão, transforme os achados escolhidos em patches. E aí é você que revisa e aplica cada um, sem piloto automático

O erro comum que estraga a varredura inteira: fechar o Claude Code no meio. A varredura roda localmente na sessão e exige o Claude Code aberto até terminar. Somando a isso, ela pode consumir um número significativo de tokens e conta nos limites de uso do seu plano, então não é coisa pra disparar no repositório inteiro cinco vezes por dia

Colocando a revisão no fluxo: comando, PR e durante a escrita

Varredura grande é evento. O que segura o dia a dia é o que roda sozinho

1. No branch em que você está trabalhando, rode a passada sob demanda:

/security-review

Ele cobre apenas as alterações do branch atual. Não espere relatório de repositório inteiro daqui

2. Quer ajustar o que a revisão prioriza no seu projeto? O prompt que dirige o comando é público no repositório anthropics/claude-code-security-review. Copie o arquivo security-review.md para a pasta .claude/commands/ do seu projeto e edite ali

3. Para os pull requests, use a GitHub Action do mesmo repositório, configurada no workflow com comment-pr: true e o secret CLAUDE_API_KEY. Ela revisa cada PR ao ser aberto e posta comentários inline com achados e correções sugeridas

O erro comum deste passo: a chave precisa estar habilitada para Claude API e Claude Code. Chave habilitada só pra metade não vai funcionar e o sintoma vai parecer problema de workflow

4. Relatório cheio de ruído? A Action aceita instruções próprias de filtragem de falsos positivos pelo input false-positive-filtering-instructions, documentado em docs/custom-filtering-instructions.md

5. Por último, a camada que age antes de tudo isso, instalada a partir do marketplace oficial:

/plugin install security-guidance@claude-plugins-official

Ele trabalha em três momentos: na edição (casamento determinístico de string, sem modelo), no fim do turno e no commit, com chamada Claude separada partindo do diff, e no git commit ou git push feito pela ferramenta Bash, com uma revisão agêntica em background mais profunda

E o erro clássico de quem monta só a Action: esperar que ela cubra código que não entrou no PR. Configuração que nasceu fora de PR, script de migração aplicado na mão, arquivo que ninguém tocou desde 2023: nada disso passa por lá

Os números dizem que melhorou, e ainda assim a distância continua grande

Na avaliação da Sonar, o Opus 5.5 gerou 152 vulnerabilidades no benchmark contra 230 do Opus 5, 34% menos

Os achados de segurança BLOCKER caíram 53%, de 19 para 9 por mLOC, e o total de achados caiu 42%, de 18.814 para 10.941

E tem um detalhe bonito nesse resultado: ele escreve 27,5% menos código que o Opus 5 pra fazer as mesmas tarefas, mantendo a mesma taxa de aprovação. Menos código, menos superfície pra dar errado

Agora o balde de água fria

No benchmark de código seguro da Endor Labs, o Claude Code com Opus 5.5 marcou 68,7% de FuncPass (código funcional) e 33,5% de SecPass (código funcional e seguro). O Opus 5 tinha ficado em 73,7% de FuncPass e 32,4% de SecPass

O benchmark é composto de 200 tarefas de 108 projetos Python open source, cobrindo 77 classes de CWE. E a mediana da diferença entre FuncPass e SecPass no quadro completo é de 45 pontos percentuais

Ou seja: funcionar e ser seguro continuam sendo campeonatos diferentes, e o placar entre um e outro quase não mexeu

Tem ainda um achado da CodeRabbit que contraria a intuição de todo mundo: esforço maior não achou mais bug de forma consistente na revisão de código

No benchmark com 80 padrões de bug conhecidos (OSS August), a configuração Standard, de esforço menor, pegou levemente mais problemas conhecidos que a Max, com menos comentários reportados e maior precisão acionável. Só nos 13 casos mais difíceis (Signal) a Max abriu vantagem, pegando 10 de 13 contra 8 da Standard e 5 da baseline

Veredito: o Opus 5.5 gera menos vulnerabilidade que o antecessor e escreve menos código pra fazer o mesmo, o que é ganho real. Mas gerar menos vulnerabilidade não é gerar código seguro, e subir o effort no máximo não é sinônimo de revisão melhor. Se você ia mandar tudo em esforço altíssimo "pra garantir", os dados não te apoiam

O que continua sendo trabalho humano

A documentação da própria Anthropic é honesta e vale citar: a revisão de segurança é ferramenta assistiva de melhor esforço, não garantia

Os achados são sugestões e não substituem revisão humana, SAST/DAST, varredura de dependências ou pentest. O revisor pode deixar passar vulnerabilidades, pode gerar falsos positivos e pode se comportar de forma diferente entre bases de código, linguagens e versões de modelo

Tem mais: o próprio prompt do /security-review manda focar apenas em achados HIGH e MEDIUM, e diz explicitamente que é melhor perder alguns problemas teóricos do que encher o relatório de falsos positivos

Essa é uma escolha de design defensável, e é também a razão pela qual relatório limpo não é atestado de segurança. Ele é um relatório limpo dentro de um escopo (o diff), com um filtro de severidade (HIGH e MEDIUM), numa rodada específica

A doc do security-guidance pede a mesma coisa em outras palavras: trate como uma camada de defesa em profundidade, não como solução completa de segurança

O que sobra pro humano, então:

• o modelo de ameaças do seu negócio, que ninguém lê no código
• a lógica de autorização: quem pode ver o quê, e por quê
• a decisão de risco, que é aceitar, mitigar ou parar o deploy
• SAST/DAST, varredura de dependências e pentest, que a própria doc lista como coisas que a revisão não substitui
• o que fazer com achado de severidade baixa que o filtro descartou, mas que no seu contexto é grave

Vale saber também como a Anthropic trata o assunto no nível do modelo. O Opus 5.5 tem as capacidades cibernéticas mais fortes já liberadas pela empresa e iguala ou supera o Claude Mythos 5.1 em todas as avaliações internas de cyber

As salvaguardas cyber aplicam a mesma política do Opus 5, com margem de segurança temporariamente mais ampla contra jailbreaks, e funcionam em três estágios: no primeiro, uma sonda olha as ativações internas do Claude, filtra todo o tráfego e escala o que for marcado como relacionado a cyber

Na prática, a maioria das tarefas de cibersegurança é redirecionada ao Claude Opus 4.8 de forma transparente (a requisição bloqueada volta respondida pelo modelo mais antigo). Identificar e corrigir bugs como parte do desenvolvimento de software de rotina permanece no Opus 5.5

Traduzindo: revisar o seu código do dia a dia é caso de uso normal, segue no modelo novo. Trabalho de cyber mais pesado pode sair respondido por outro modelo sem você perceber, e isso explica variação de qualidade que parece aleatória

O modelo passou por avaliações externas antes do lançamento, entre elas METR e Frontier Design, e a Anthropic diz que ele alcançou o melhor resultado até hoje na avaliação de alinhamento mais abrangente da empresa

Conclusão

Ordem de adoção que faz sentido, do mais barato pro mais caro:

1. security-guidance primeiro, porque ele age enquanto o código nasce e a camada de edição não usa modelo nenhum
2. /security-review no branch e a GitHub Action no PR, pra que nada entre sem uma passada
3. varredura por área com o plugin Claude Security de forma periódica, não diária, lembrando que ela consome tokens e conta nos limites do seu plano

E o próximo passo prático, que leva dez segundos: depois de atualizar, abra o Claude Code e reconfira o /effort ou o seletor /model, porque o Opus 5.5 inicia no padrão dele (medium) e não herda o nível que você tinha salvo

A Anthropic já anunciou Sonnet 5.5 e Haiku 5.5 como previstos para as semanas seguintes ao lançamento do Opus 5.5, então esse fluxo de revisão vai ganhar opções mais baratas pra rodar em cima do diff…

Se a sua régua era "o relatório veio vazio, então está seguro", troca essa régua hoje. O relatório vazio diz o que a ferramenta não achou naquele escopo, e isso é bem diferente de segurança 🙂

Até o próximo post!