A revisão manual de código é a inspeção linha por linha do código-fonte feita por uma pessoa, para encontrar falhas de segurança que dependem do contexto: quem pode chamar uma função, o que as regras de negócio permitem e se um controle que parece estar presente realmente se sustenta. A análise automatizada trabalha com padrões. A revisão manual de código trabalha raciocinando sobre a intenção.
A diferença entre as duas pode ser medida. No benchmark da Fluid Attacks com 36 ferramentas AppSec de terceiros contra uma aplicação web com 1.201 vulnerabilidades em 105 categorias CWE, um pentester encontrou 743 falhas que nenhuma ferramenta reportou: 61,9 % do total, com 86,8 % da exposição ao risco da aplicação. O benchmark mede os testes manuais de um pentester, não apenas a revisão de código seguro, e esta página o usa para mostrar o que a análise manual acrescenta às ferramentas automatizadas.
Esta página aborda o que é a revisão manual de código, como escolher o que é revisado primeiro, o que um revisor verifica, o que muda na revisão de código gerado por IA e como saber se a revisão realmente reduziu o risco. Para a metodologia completa do serviço em quatro etapas, consulte Revisão de Código Seguro.
O que é revisão manual de código?
A revisão manual de código é a inspeção sistemática do código-fonte por revisores humanos para encontrar falhas de segurança e confirmar que o código segue os padrões de segurança. A documentação da Fluid Attacks a define nesses termos e acrescenta que essa análise especializada “frequently finds severe and complex vulnerabilities that automated tools alone cannot find”.
Antes de continuar, duas distinções. A revisão manual de código não é o mesmo que uma revisão por pares comum: a revisão por pares pergunta se o código funciona e se lê bem, enquanto a revisão manual de código pergunta se um atacante pode abusar dele. As duas usam listas de verificação diferentes e, geralmente, pessoas diferentes. Ela também não é o oposto da análise automatizada. No processo da Fluid Attacks, SAST e SCA rodam primeiro, e os achados automatizados são usados para filtrar falsos positivos e orientar a investigação manual mais profunda.
Por que a revisão manual de código continua importando
Os scanners reconhecem padrões conhecidos; a revisão manual de código resolve o significado. A OWASP DevSecOps Guideline, em sua atualização de outubro de 2026, expõe a divisão sem rodeios: “Automated scanners find known patterns; human review finds the flaws that need context”, e observa que “Scanners rarely detect broken access control or business-logic flaws”.
Dois padrões colocam a revisão de código dentro do processo formal de desenvolvimento. Nenhum exige a revisão manual de código como tal: o NIST deixa para a organização a escolha entre revisão humana e análise com ferramentas, e o PCI DSS aceita revisão manual, automatizada ou combinada.
NIST SP 800-218 (SSDF 1.1, fevereiro de 2022) dedica a prática PW.7 à revisão de código legível por humanos. A tarefa PW.7.1 pede que a organização decida “whether code review (a person looks directly at the code to find issues) and/or code analysis” se aplica; a PW.7.2 pede que a revisão seja feita com base em padrões de codificação segura e que os achados sejam registrados e priorizados no fluxo de trabalho da equipe de desenvolvimento.
PCI DSS v4.0.1: o requisito 6.2.3 estabelece que “Bespoke and custom software is reviewed prior to being released into production” e permite que a revisão seja feita “using either manual or automated processes, or a combination of both”. O requisito 6.2.3.1 regula especificamente o caso manual: o revisor deve ser alguém diferente do autor do código, deve ter competência em técnicas de revisão e codificação segura, e a gerência deve aprovar o resultado antes da liberação.
A Fluid Attacks mapeia a prática PW.5.1 do NIST SSDF, práticas de codificação segura, para sete requisitos de segurança que um revisor pode verificar.
Nenhum dos dois padrões trata a revisão de código como burocracia. O NIST pede que os problemas e as correções recomendadas sejam registrados e priorizados no fluxo de trabalho da equipe de desenvolvimento, e o PCI DSS pede correções antes da liberação.
A revisão manual de código na Fluid Attacks
A Fluid Attacks executa a revisão manual de código como Secure Code Review, um serviço do plano Advanced em que os analistas inspecionam o código-fonte junto com os testes automatizados que rodam no mesmo repositório.
O que revisamos e em que ordem
Ninguém lê um milhão de linhas à mão, então a ordem é o método. A Fluid Attacks usa IA para prever os arquivos de alto risco e revisá-los primeiro, e modelos estatísticos “identify the systems and components that require the most attention”. O esforço de teste segue o risco, não uma cobertura uniforme de arquivos.
Como é um achado
Um achado da revisão manual de código só é útil se um desenvolvedor puder agir sobre ele. Cada um chega à plataforma com o arquivo e a linha afetados, uma pontuação de severidade CVSS v4.0, seu status de remediação e a fraqueza à qual corresponde na base de dados pública da Fluid Attacks. Esse link torna um achado da revisão manual de código verificável: qualquer pessoa pode abrir a entrada e ler o impacto, a recomendação e o requisito de segurança vinculado.
Com o que um revisor compara: a fraqueza 013 e o requisito de segurança ao qual ela está vinculada.
Revisão manual de código versus análise automatizada, com números próprios
Avaliador | Precisão | Recall (vulnerabilidades) | Recall (exposição ao risco) |
|---|---|---|---|
Pentester da Fluid Attacks | 100 % | 89,6 % | 98,9 % |
Scanner da Fluid Attacks | 99 % | 22,7 % | 8,8 % |
Ferramenta de terceiros com mais verdadeiros positivos | 72 % | 21,6 % | 4,0 % |
Média das demais ferramentas de terceiros | — | 1,7 % | — |
Resultados do benchmark da Fluid Attacks contra uma aplicação web com 1.201 vulnerabilidades; a linha do pentester corresponde a testes manuais. Dezessete ferramentas não conseguiram identificar nem dez.
O limite dos nossos próprios números: mais achados não é mais risco coberto
Lida por colunas, a tabela diz algo que os números principais escondem. O próprio scanner da Fluid Attacks alcança 22,7 % de recall em número de vulnerabilidades, mas apenas 8,8 % da exposição ao risco: encontra uma parcela respeitável das falhas e uma parcela pequena do perigo. As vulnerabilidades que pesam são as que precisam de contexto, e esse é o argumento completo a favor da revisão manual de código expresso como uma proporção.
Mais uma ressalva sobre o escopo. A análise da Fluid Attacks de testes de segurança de 2023 em sistemas de clientes constatou que 71,4 % da exposição ao risco foi reportada apenas por métodos manuais. Esse número descreve os métodos manuais em conjunto, não a revisão manual de código sozinha.
Onde a revisão termina: o reattack
Uma revisão manual de código que para no relatório deixa aberta a pergunta mais importante. Quando um desenvolvedor corrige um achado, o cliente solicita um reattack na plataforma e, nos achados manuais, um pentester faz a verificação (Platform FAQ). Sobre funções privilegiadas, Juan Restrepo, Certified DevSecOps Professional, escreve na análise da Fluid Attacks sobre o ataque hacker à Binance:
“In our Secure Code Review, analysts trace who can call each of these functions and with which identity”.
(Em nossa Revisão de Código Seguro, os analistas rastreiam quem pode chamar cada uma dessas funções e com qual identidade).
Como decidir o que revisar primeiro
Uma revisão de código baseada em risco é o que torna a revisão manual de código viável em escala. Em vez de distribuir a atenção por igual, ela concentra as horas de revisão onde um erro muda em quem se confia. A OWASP DevSecOps Guideline lista os tipos de mudança que justificam um olhar mais profundo:
Código sensível para a segurança: autenticação, gerenciamento de sessões, autorização, criptografia, processamento de entradas, desserialização e upload de arquivos.
Mudanças nos limites de confiança: novos endpoints públicos, integrações com terceiros, novos armazenamentos de dados e mudanças em CORS ou na exposição de rede.
Mudanças em build e entrega: fluxos de CI, Dockerfiles, manifestos de infraestrutura e scripts de liberação, revisados como código de produção.
Mudanças em dependências: pacotes novos ou atualizados e diferenças nos lockfiles, com verificação de procedência, mantenedores e scripts de instalação.
Mudanças grandes ou incomuns: diffs muito grandes, código gerado e mudanças de colaboradores novos, que devem ser divididas ou atribuídas a um segundo revisor.
Tudo nessa lista compartilha uma propriedade: o dano não fica restrito à linha. Um novo endpoint público ou uma integração redesenha os limites de confiança do sistema, e a OWASP pede que essas mudanças sejam verificadas contra o modelo de ameaças, o que exige um contexto que um scanner raramente tem. Uma revisão manual de código baseada em risco justifica seu custo aí, não em mudanças que alteram o que uma tela exibe.
Uma lista de verificação para a revisão manual de código mantém esse foco de forma repetível. Validação de entradas, autenticação e gerenciamento de senhas, controle de acesso e gerenciamento de sessões, criptografia e proteção de dados, tratamento de erros e logging, e configuração do sistema são os tópicos recorrentes, cada um vinculado a um requisito de segurança que o revisor pode verificar em vez de deixá-lo a critério.
Revisão completa versus revisão de mudanças
A revisão manual de código tem duas formas. O Secure Code Review Cheat Sheet da OWASP as separa: as revisões completas (baseline) “examine the entire codebase comprehensively”, enquanto as revisões de mudanças (diff-based) “focus on code changes only”.
Revisão manual de código completa | Revisão manual de código de mudanças | |
|---|---|---|
Escopo | Toda a base de código | Apenas as linhas que uma mudança adiciona ou altera |
Quando fazer | Aplicações novas, versões principais, incorporação de sistemas legados, conformidade, análise pós-incidente | Pull requests, commits, desenvolvimento diário, validação contínua |
O que responde | Que risco já está em produção | Que risco esta mudança introduz |
Frequência | Em marcos e eventos que a disparam | A cada mudança |
As duas funcionam juntas. A abordagem híbrida da OWASP combina revisões completas para componentes de alto risco com revisões de mudanças para alterações rotineiras, e escala da revisão de mudanças para a completa quando surgem preocupações de segurança relevantes. Uma equipe que faz revisão manual de código apenas nos pull requests nunca examina o código que herdou.
O que a revisão manual de código encontra e os scanners não veem
As falhas reservadas à revisão manual de código compartilham um traço: o código está sintaticamente correto e mesmo assim está errado. O controle de acesso quebrado é a família mais clara: a OWASP observa que os scanners, incluindo o Teste Estático de Segurança de Aplicações (SAST), raramente o detectam, porque uma verificação de permissão pode existir no código e mesmo assim verificar a coisa errada para o usuário errado. Estas entradas da base de dados da Fluid Attacks mostram o que uma revisão manual de código realmente procura.
O que o analista revisa | Fraqueza da base de dados | O que verifica |
|---|---|---|
Autorização e funções | Que uma conta padrão não consiga obter privilégios de administrador. Requisito vinculado: 035, gerenciar modificações de privilégios. | |
Gestão de segredos | Que não haja credenciais no repositório nem em seu histórico do git. Requisito vinculado: 156. | |
Controle de acesso a objetos | Que um usuário não consiga chegar aos dados de outro alterando um valor de chave. Requisito vinculado: 176. | |
Concorrência | Que a verificação e o uso de uma entrada aconteçam de forma atômica. Requisito vinculado: 337. |
As falhas de lógica de negócio entram na mesma lista. Se uma transferência de dinheiro aceita um valor negativo, todas as verificações de tipo passam e o saque se transforma em depósito. Nenhum arquivo de regras descreve essa falha, porque a regra que ela quebra só existe no negócio, e por isso os scanners raramente detectam essas falhas. Uma condição de corrida se comporta da mesma forma: cada linha é válida, e só a ordem de chegada expõe o problema.
A falha goto fail da Apple em 2014 (CVE-2014-1266) mostra o mesmo traço em uma única linha. Uma linha goto fail; duplicada dentro de SSLVerifySignedServerKeyExchange, sem chaves ao redor do condicional, tornou inalcançáveis as verificações de certificado restantes e fez a função retornar sucesso, o que permitiu que atacantes man-in-the-middle falsificassem servidores SSL. A análise da falha do pesquisador de segurança David A. Wheeler conclui: “Just about any manual review is very likely to have found this”. Ele também lista outros controles que a teriam detectado, entre eles a detecção de código inalcançável, o uso obrigatório de chaves e a análise de cobertura de testes, então a revisão manual de código funciona melhor como um controle entre vários.
Revisar código gerado por IA
A revisão manual de código gerado por IA é hoje o caso de maior volume, e o modo de falha mudou com ela. O código compila, é fácil de ler e omite controles que ninguém pediu. O Secure Coding with AI Cheat Sheet da OWASP traça a linha da responsabilidade: “AI-generated code must have a human owner”, porque “AI tools do not accept responsibility for the code they generate. The developer who accepts and commits the code does”.
Três coisas que uma revisão manual de código precisa verificar aqui e que os hábitos gerais de revisão não cobrem:
Dependências que não existem. A OWASP observa que os assistentes “frequently suggest package names that do not exist on public registries”, uma brecha para um atacante que registre o nome inventado.
Controles omitidos por silêncio. A DevSecOps Guideline aponta para “Missing authorization and input validation, which models omit when the prompt does not mention them”.
Compreensão por parte do autor. A mesma diretriz estabelece um filtro útil: “If the author cannot describe how it works, it is not ready to merge”. Ela também sustenta que o código gerado “needs at least the same scrutiny as code from an unknown contributor”.
Um revisor automatizado que comenta a mudança não substitui aqui uma revisão manual de código. A OWASP é explícita ao dizer que comentários de revisão gerados por IA não substituem a revisão humana, e que “a human with accountability must still approve security-relevant changes”. A análise da Fluid Attacks sobre como o desenvolvimento com agentes desloca a responsabilidade chega à mesma conclusão: a execução escala, o julgamento não.
Como medir se a revisão funcionou
Na revisão manual de código, encontrar uma falha não é o resultado. Um estudo empírico de 135.560 comentários de revisão de código no OpenSSL e no PHP, de pesquisadores da Universidade de Melbourne e da Singapore Management University (2023), constatou que os revisores levantaram preocupações de segurança em 35 de 40 categorias de fraquezas de codificação, e que de 30 % a 36 % dessas preocupações foram apenas reconhecidas, sem correção, enquanto de 18 % a 20 % ficaram sem solução porque revisores e desenvolvedores discordaram sobre a solução.
Esse é o número a gerenciar. Um programa de revisão manual de código que reporta achados e nunca verifica o fechamento está medindo atividade, não risco. Três métricas descrevem o resultado: a proporção de achados corrigidos, o tempo entre o relatório e a correção verificada e a proporção de reattacks aprovados na primeira tentativa. A precisão e o recall descrevem o quão bem a revisão manual de código detecta; essas três descrevem se ela fez diferença.
O Heartbleed mostra por que muitos leitores não equivalem a uma revisão que funcionou. O código defeituoso do heartbeat do OpenSSL foi introduzido em dezembro de 2011 e lançado no OpenSSL 1.0.1 em 14 de março de 2012; a correção chegou na versão 1.0.1g em 7 de abril de 2014 (heartbleed.com). O relato da CSO observa que qualquer pessoa podia ler o código e “presumably hundreds did”, e que a falha “lurked undetected for two years” até que Neel Mehta, do Google, decidiu fazer uma auditoria linha por linha do código do OpenSSL. No momento da divulgação, a Netcraft encontrou a extensão heartbeat habilitada em 17,5 % dos sites SSL, cerca de meio milhão de certificados emitidos por autoridades certificadoras confiáveis. Por isso as três métricas acima medem resultados, não atividade.
Revisão manual de código versus revisão automatizada de pull requests
São trabalhos diferentes, e confundi-los gera uma falsa sensação de segurança. Um revisor automatizado de pull requests analisa as linhas que uma mudança adiciona; uma revisão manual de código analisa o que essa mudança significa para o sistema.
O Peer Reviewer Assistant da Fluid Attacks ilustra com precisão a metade automatizada. Ele reporta “the vulnerabilities that the change introduces”, compara com a base do merge e reporta apenas as linhas adicionadas, usando SAST, SCA e varredura de segredos. Publica um comentário de resumo por mudança, faz sua verificação de status falhar quando uma pontuação CVSS 4.0 ultrapassa o limite “Minimum to break the build” e, o que é importante, não bloqueia merges sozinho, a menos que a equipe torne a verificação obrigatória.
O que ele não consegue fazer é decidir se uma mudança de autorização bem escrita é a mudança de autorização certa. Essa continua sendo uma pergunta da revisão manual de código e, junto com os testes de invasão manuais, é a razão pela qual as técnicas humanas rodam junto com as automatizadas, em vez de uma substituir a outra.
▶️ Vídeo: mostramos como nossa ferramenta baseada em IA faz revisão de segurança automática e contextual nos pull requests, e onde o critério humano continua necessário. (em espanhol)
Conclusões
A revisão manual de código lê o código pelo que ele deveria fazer, e é aí que os scanners raramente olham. O benchmark da Fluid Attacks mostra o quanto a diferença pode ser grande para os testes manuais em geral: 86,8 % da exposição ao risco da aplicação estava em falhas que nenhuma ferramenta automatizada reportou. Os padrões apontam na mesma direção (o PCI DSS v4.0.1 exige revisão de código antes da liberação e o SSDF do NIST a nomeia como prática), mas a conformidade é o piso, não a razão.
A versão prática da revisão manual de código é mais restrita do que “revisar tudo”. Faça uma revisão de código baseada em risco para escolher os alvos, separe a passada completa da passada por mudança, aplique mais escrutínio ao código escrito por um modelo e verifique se cada achado foi realmente fechado. As práticas de codificação segura dão ao revisor o padrão de comparação; o reattack dá à organização a prova. Uma revisão manual de código que termina no relatório fez a parte cara do trabalho e pulou a parte que reduz o risco.
Perguntas frequentes
Qual é a diferença entre revisão de código e revisão manual de código?
A revisão de código é a prática geral de avaliar o código-fonte com base em padrões, e pode ser feita por ferramentas ou por pessoas. A revisão manual de código é especificamente a metade humana: um revisor lendo o código para encontrar falhas de segurança que dependem do contexto, como a lógica de autorização, as regras de negócio e os limites de confiança. A análise automatizada verifica os padrões para os quais foi configurada.
As ferramentas automatizadas podem substituir a revisão manual de código?
Não. No benchmark da Fluid Attacks com 36 ferramentas AppSec de terceiros contra uma aplicação web com 1.201 vulnerabilidades, a ferramenta de terceiros com mais verdadeiros positivos alcançou 21,6 % de recall e 4,0 % da exposição total ao risco, enquanto um pentester fazendo testes manuais alcançou 89,6 % de recall com 100 % de precisão. As ferramentas cobrem amplitude a baixo custo; a análise manual cobre mais das falhas que carregam o risco.
O PCI DSS exige revisão manual de código?
Não especificamente. O requisito 6.2.3 do PCI DSS v4.0.1 exige que o software sob medida e personalizado seja revisado antes de ir para produção, e aceita processos manuais, automatizados ou ambos. Se a organização escolher a revisão manual, o requisito 6.2.3.1 acrescenta condições: o revisor não pode ser o autor do código, deve ter competência em codificação segura e técnicas de revisão, e a gerência deve aprovar o resultado.
Como o código gerado por IA deve ser revisado?
Com o mesmo escrutínio aplicado a uma mudança de um colaborador desconhecido. A OWASP exige que esse código tenha um responsável humano que o tenha revisado e entendido, e aponta três problemas recorrentes: pacotes sugeridos pelo modelo que não existem, autorização e validação de entradas omitidas porque o prompt não as mencionava, e autores que não conseguem explicar como o código funciona.
A Fluid Attacks faz revisão manual de código?
Sim. Sua revisão manual de código é o serviço Secure Code Review do plano Advanced, em que analistas de segurança inspecionam o código-fonte em paralelo com os testes automatizados no mesmo repositório. A IA prevê os arquivos de alto risco para que os revisores comecem por eles, os achados chegam com arquivo, linha, severidade CVSS v4.0 e um link para a entrada da fraqueza, e um pentester verifica as correções dos achados manuais quando um reattack é solicitado.
Revise o código antes que um atacante o faça
Nossos analistas fazem revisão manual de código no seu código-fonte desde o primeiro commit, junto com os scanners, para que as falhas sobre as quais uma ferramenta não consegue raciocinar sejam encontradas enquanto ainda são baratas de corrigir. Teste gratuito · Fale conosco.
Comece agora com a solução de segurança de aplicações da Fluid Attacks
