A primeira vez que você vê um comentário de IA em um pull request, o loop de feedback chama atenção. Um review completo aparece em segundos, apontando possíveis problemas antes mesmo de um revisor humano abrir o arquivo. O apelo de usar uma ferramenta como o Claude para revisão de segurança de código, uma parte crítica da segurança no SDLC, é claro: encontrar problemas cedo e reduzir o trabalho manual do time. Na prática, porém, essa velocidade costuma criar uma falsa sensação de segurança. Ela funciona bem no início, mas começa a falhar à medida que o time cresce e os sistemas ficam mais complexos.
O problema é que essas ferramentas operam com um ponto cego crítico. Elas veem o código, mas não veem o sistema. Conseguem analisar sintaxe, mas não entendem intenção, histórico ou os contratos arquiteturais que mantêm uma aplicação complexa funcionando.
O Ponto Cego Crítico
Uma boa revisão de segurança depende de contexto que não está no diff. Esse contexto vive fora do código isolado. Por natureza, um LLM não tem acesso a isso. Ele analisa apenas um recorte do código, de forma isolada, e perde a visão mais ampla onde, na prática, costumam estar as vulnerabilidades mais graves.
Riscos arquiteturais e de fluxo de dados que passam despercebidos
Muitas falhas críticas de segurança não estão no código em si, mas na forma como os dados circulam entre componentes. Um LLM não conhece os limites de confiança do sistema. Ele não sabe, por exemplo, que o UserService é apenas interno ou que qualquer dado vindo de um APIGateway exposto ao público precisa ser revalidado, independentemente de validações anteriores.
Considere uma falha de autorização que passa despercebida. Um desenvolvedor adiciona um novo endpoint que verifica corretamente se o usuário tem o papel de admin. Olhando apenas para o diff, o código parece correto.
Mas um engenheiro sênior conhece uma regra implícita do sistema: um admin do Tenant A nunca deveria acessar dados do Tenant B. O código não faz a verificação de tenant ID.
O Claude não vai sinalizar isso porque não entende o seu modelo de multi-tenancy nem as regras internas de isolamento e sensibilidade de dados. Ele vê uma checagem de papel válida e segue em frente, deixando passar um possível vazamento de dados entre tenants.
Ignorar o histórico do repositório e a evolução das ameaças
Uma base de código é um documento vivo. O histórico de commits, pull requests e relatórios de incidentes contém um contexto de segurança valioso. Um revisor humano pode se lembrar de um incidente passado envolvendo validação incompleta de input em um determinado modelo de dados e ficará ainda mais atento a mudanças semelhantes. Um LLM não tem memória disso.
Por exemplo, um time pode ter corrigido uma vulnerabilidade de negação de serviço adicionando um limite rígido de tamanho em um campo de texto livre. Seis meses depois, um novo desenvolvedor, trabalhando em outra feature, adiciona um campo parecido, mas esquece a validação de tamanho. O código está sintaticamente correto, mas reintroduz um padrão de vulnerabilidade já conhecido. Um revisor experiente percebe isso imediatamente. Um LLM vê apenas o novo código, sem acesso às lições aprendidas no passado.
Incapacidade de Aprender Políticas de Segurança Específicas do Time
Todo time de engenharia desenvolve seu próprio conjunto de convenções e políticas de segurança. Elas costumam ser específicas do domínio e nem sempre estão explícitas no código.
- Talvez a política da sua empresa proíba armazenar qualquer forma de PII no Redis.
- Ou vocês tenham uma regra de usar uma biblioteca interna específica para todas as operações criptográficas, porque bibliotecas padrão já foram usadas de forma incorreta no passado.
- Seu time pode ter decidido usar UUIDv7 para todas as novas chaves primárias por razões de performance.
Um LLM não tem conhecimento desses padrões internos.
Ele pode até sugerir uma solução que viola diretamente essas regras, gerando mais trabalho para o revisor, que agora precisa corrigir tanto o código quanto a sugestão da IA. O tom confiante e autoritário do LLM pode levar desenvolvedores mais juniores a assumir que suas sugestões representam boas práticas de qualidade de código, mesmo quando contradizem padrões já estabelecidos pelo time.
Armadilhas de Escala: Quando as Limitações do LLM se Acumulam
Para um time pequeno trabalhando em um monólito, algumas dessas lacunas até podem ser gerenciadas. Mas à medida que a organização tenta lidar com o desafio de escalar o code review em um time em crescimento, com mais engenheiros, mais times e mais microsserviços, essas limitações criam problemas sistêmicos que a automação não consegue resolver.
O Gargalo da Verificação Humana
revisar a saída da própria IA. Com um fluxo constante de sugestões de baixo impacto ou irrelevantes, os engenheiros rapidamente desenvolvem fadiga de alertas e passam a tratar os comentários da IA como ruído de linter, algo fácil de ignorar.
Na prática, todo comentário gerado por IA ainda exige que alguém avalie sua validade, impacto e contexto. Isso torna os reviews mais lentos e desvia a atenção do que realmente importa. A carga cognitiva de filtrar o ruído da IA pode facilmente superar o benefício de ela capturar alguns problemas óbvios.
Lacunas de entendimento arquitetural na revisão de segurança de código com LLMs
Em sistemas distribuídos, os bugs mais perigosos costumam viver nas interações entre serviços. Um LLM revisando uma mudança em um único repositório não tem visibilidade de como essa alteração pode quebrar um contrato implícito com um consumidor downstream. Ele não percebe, por exemplo, que remover um campo de uma resposta JSON pode causar falhas silenciosas em um serviço de outro time que depende desse campo.
O mesmo vale para erros no uso de criptografia. Um LLM consegue sinalizar problemas óbvios, como o uso de um algoritmo obsoleto como DES. Mas tende a deixar passar falhas mais difíceis de detectar, como a reutilização de um vetor de inicialização (IV) em uma cifra de bloco. Identificar esse tipo de problema exige entender o estado da aplicação e o fluxo de dados ao longo de múltiplas requisições, algo que vai muito além da análise estática de um trecho de código.
Alucinações
LLMs conseguem estar errados com bastante convicção. Não é raro ver recomendações de bibliotecas de segurança que não existem, interpretações incorretas de detalhes de uma CVE real ou snippets de código falhos apresentados como “correção”.
Em segurança, isso é especialmente perigoso. Um desenvolvedor pode aceitar uma explicação que soa plausível, mas está errada, e acabar introduzindo uma nova vulnerabilidade ao tentar corrigir outra. Essa falsa sensação de confiança prejudica o aprendizado e pode levar a um resultado de segurança pior do que o original.
Por que a expertise humana ainda importa
Isso não quer dizer que ferramentas de IA não tenham espaço. O problema é tratá-las como substitutas do julgamento humano, e não como um complemento. Revisores humanos fornecem um contexto essencial que máquinas não conseguem oferecer.
Além da Sintaxe: Lógica de Negócio e Intenção
Um engenheiro sênior entende o porquê por trás do código. Ele conecta a mudança proposta ao seu objetivo de negócio e consegue fazer perguntas críticas que um LLM jamais faria.
“O que acontece se um usuário fizer upload de um arquivo com mais de 255 caracteres no nome?” ou “Essa nova permissão de usuário está alinhada com os requisitos de compliance da empresa em relação ao GDPR?”
Esse tipo de raciocínio sobre impacto no mundo real é a base de uma boa revisão de segurança
Mentoria e Construção de uma Cultura de Segurança
Code reviews são um dos principais mecanismos de transferência de conhecimento dentro de um time. Quando um engenheiro sênior aponta uma falha de segurança, ele não se limita a dizer “isso está errado”. Ele explica o risco, referencia uma decisão passada ou um documento interno e usa o review como um momento de aprendizado.
Esse processo aumenta a consciência de segurança de todo o time e fortalece uma cultura de responsabilidade compartilhada. Um comentário automático de um bot não oferece nada disso. Ele só parece mais um item de checklist para resolver.
Um Modelo Híbrido de Revisão
O objetivo não é rejeitar ferramentas novas, mas ser intencional sobre como usá-las. Uma postura de segurança saudável usa automação para ampliar o julgamento humano, não para substituí-lo.
Aumentar, Não Substituir: Onde LLMs Fazem Sentido
O melhor uso de LLMs em code review é como uma primeira passada automatizada para uma classe bem específica de problemas. Por exemplo:
-
Segredos hardcoded e chaves de API
-
Uso de bibliotecas ou funções sabidamente inseguras (como
strcpyem C oupickleem Python) -
Padrões comuns que indiquem SQL injection ou XSS
A saída deve ser tratada como sugestão, não como veredito. A autoridade final continua sendo o revisor humano.
Invista em Contexto
Obter resultados consistentemente úteis de um LLM exige um investimento alto em fornecer contexto correto. Isso envolve diagramas arquiteturais, informações de fluxo de dados e políticas internas do time, muitas vezes guiado por práticas avançadas de prompt engineering.
Esse contexto também precisa ser mantido atualizado, o que cria uma carga contínua de manutenção. Antes de tornar um LLM uma etapa obrigatória no CI/CD, é preciso entender esse custo e esses limites.
Cultive uma Postura de Segurança Robusta para Crescer
No fim das contas, uma cultura de segurança forte depende de julgamento humano. Automação funciona bem para tarefas simples, repetitivas e sem contexto. Isso libera engenheiros mais experientes para focar nos riscos complexos e cheios de dependências, onde a experiência realmente importa. Equilibrar a eficiência da automação com o julgamento de quem conhece o sistema é a única forma de construir uma prática de segurança que escala de verdade.
