Revisão de código com foco em segurança

O pentest ataca o sistema em funcionamento, de fora. A revisão lê o código-fonte, de dentro. O pentest demonstra que uma falha pode ser explorada; a revisão alcança trechos que o teste externo não chega a exercitar, como rotas administrativas pouco usadas e tratamento de erro. As duas abordagens se complementam.

O SAST analisa o código parado com ferramentas e cobre o repositório inteiro em pouco tempo. O DAST testa a aplicação rodando, enviando requisições como um atacante faria. A revisão manual é a leitura feita por uma pessoa que entende a regra de negócio, e é ela que percebe, por exemplo, que um usuário consegue abrir o pedido de outra empresa trocando um número na URL.

Faz. A própria OWASP registra que é difícil automatizar a busca por falhas de autenticação, controle de acesso e uso inseguro de criptografia, e que essas ferramentas geram muitos falsos positivos. A falta de verificação de autorização (CWE-862) subiu para o 4º lugar do CWE Top 25 de 2025. A revisão manual concentra o tempo nesses pontos e usa o resultado da ferramenta como ponto de partida.

O acesso é de leitura, temporário e limitado aos repositórios do escopo, com acordo de confidencialidade assinado antes do início. O código não é enviado a ferramentas ou serviços externos sem autorização por escrito, e o acesso é revogado ao fim do trabalho.

Depende do tamanho do código, das linguagens e de quanto dele entra no escopo, por isso o prazo é definido depois de uma leitura inicial do repositório. Em sistemas grandes, é comum começar pelos módulos de maior risco, como autenticação, permissões, pagamento e integrações, e ampliar depois.

Acesso de leitura ao repositório e a indicação do commit ou da versão a revisar, para que todos analisem o mesmo código. Uma visão geral da arquitetura, a lista de perfis de usuário e o contato de um desenvolvedor que conheça o sistema também ajudam. Se houver ambiente de homologação, ele serve para confirmar os achados.

Os critérios são os mesmos. O que muda é a atenção a padrões repetidos, porque o código gerado tende a replicar a mesma solução em muitos arquivos. Quando uma rota esquece de conferir a permissão, é comum que dezenas de outras tenham o mesmo problema, e a correção precisa ser feita no ponto central.

Não basta. A orientação do próprio GitHub é revogar ou trocar a chave primeiro, porque o conteúdo continua acessível em clones, forks e caches mesmo depois de reescrever o histórico. Com a chave revogada, o que ficou no histórico deixa de servir para acesso.

Serve. Cada achado indica arquivo, linha, risco e correção sugerida, com referência à categoria CWE e ao requisito correspondente do OWASP ASVS. A revisão de código também é uma das práticas previstas no Secure Software Development Framework do NIST (SP 800-218, prática PW.7), que costuma aparecer em questionários de fornecedores.