Auditoria de código: o que verificar em uma base de código herdada

Uma auditoria de código é uma revisão estruturada de uma base de código que mostra o que você realmente tem em mãos: o que roda, o que é arriscado e o que vai custar dinheiro mais adiante. Quando você herda um software de uma agência ou de um desenvolvedor que saiu, a auditoria é a primeira informação concreta que você recebe.

A ordem importa mais do que as ferramentas. A ordem que sigo nos primeiros 30 dias de uma transição é: primeiro os acessos, depois o build, depois os fluxos de dinheiro, depois os riscos. Este artigo segue essa ordem, para que você mesmo possa fazer a auditoria ou verificar se alguém a fez direito.

O que é uma auditoria de código e quando você precisa de uma?

Uma auditoria de código revisa o código-fonte, a infraestrutura e a operação para responder perguntas práticas. Dá para alterar isso com segurança? Isso pode perder dinheiro ou dados? O que quebra se a única pessoa que entende o sistema for embora? Não é uma proposta de reescrita nem um julgamento do talento dos desenvolvedores anteriores. Muitos problemas vêm de prazos apertados e falta de orçamento, não de engenheiros ruins.

Situações comuns que levam a uma auditoria

• Você está saindo de uma agência, ou uma agência está saindo do seu projeto.
• O único desenvolvedor pediu demissão, foi desligado ou parou de responder mensagens.
• O app foi gerado com ferramentas de IA e está prestes a receber usuários reais.
• Você está planejando uma migração e precisa saber o que realmente existe no sistema.
• Você está comprando uma empresa ou captando investimento e alguém vai fazer perguntas difíceis. Esse é um exercício relacionado, chamado due diligence técnica.

Se tudo funciona, o time é estável e você entende o sistema, talvez não precise de uma auditoria completa. Ainda assim, uma verificação leve de acessos e backups é um seguro barato.

Você tem acesso a tudo: repositórios, hospedagem, domínios, segredos?

Comece aqui, porque todo o resto depende disso. Um padrão que procuro em toda transição é o código estar bem enquanto um ativo crítico, como o domínio, está registrado no e-mail pessoal de um ex-prestador de serviço. Isso é um risco de negócio, não técnico, e pode ficar escondido até o dia em que uma renovação falha.

Faça um inventário e confirme que você, como empresa, tem acesso de proprietário a cada item:

Assim que tiver os acessos, troque as credenciais que o time anterior conhecia. Isso inclui chaves de API, senhas de banco de dados e logins compartilhados. É prática padrão depois de qualquer mudança de time.

O projeto faz build e deploy do zero?

É a primeira coisa que testo em qualquer transição, e ela revela muito: em uma máquina limpa, alguém consegue seguir o README, rodar o projeto localmente e publicar um deploy? Se a resposta for não, você encontrou um problema sério. Um sistema que só um notebook ou uma pessoa consegue publicar é frágil.

Verifique estes pontos:

1. Clonar e instalar. A instalação funciona com comandos documentados? As versões de runtime estão fixadas?
2. Execução local. Precisa de dados de produção ou de segredos que ninguém encontra? Existe um seed ou um banco de testes?
3. Testes. Existem testes, e eles passam? Uma suíte de testes pequena e confiável vale mais do que uma grande e quebrada.
4. Deploy. É automatizado por um pipeline ou depende de passos manuais que alguém fazia de memória?
5. Ambientes. Existe um ambiente de staging parecido com produção, ou toda mudança vai direto para o ar?
6. Rollback. Se uma release falhar, como você volta para a versão anterior?

Anote cada lacuna que encontrar. Anote também as dependências abandonadas, fixadas em versões muito antigas ou que exigem runtimes em fim de vida. Elas definem o custo de toda mudança futura.

Os fluxos de dinheiro (pagamentos, autenticação, cobrança) são seguros?

Depois do build, revise tudo o que toca em receita ou identidade. Chamo isso de fluxos de dinheiro: pagamentos, checkout, assinaturas, faturamento, login, redefinição de senha e permissões. Um bug numa página de configurações é um incômodo. Um bug aqui custa dinheiro ou expõe contas.

Trabalhei no time de carrinho e checkout da Total Wine & More, uma varejista americana com 190 milhões de visitas por ano no site. Com esse volume de tráfego, falhas que parecem casos raros podem aparecer com muito mais frequência do que você imagina. A lição que tirei disso vale para qualquer tamanho: fluxos de dinheiro merecem mais escrutínio do que o resto do código, por menor que seja o produto.

O que revisar em pagamentos e cobrança

• O valor do pagamento é calculado no servidor, ou o cliente pode enviar um preço?
• Os webhooks do provedor de pagamentos são verificados com assinatura e tratados com segurança se chegarem duplicados ou fora de ordem?
• Vocês armazenam dados de cartão? Normalmente não deveriam; quem deve guardá-los é o provedor.
• Os status de assinatura no seu banco de dados batem com os do provedor de pagamentos?
• O que acontece quando um pagamento falha no meio de um pedido?

O que revisar em autenticação

• Como as senhas são armazenadas e redefinidas? Os links de redefinição são de uso único e de curta duração?
• Sessões ou tokens expiram e podem ser revogados?
• Cada endpoint verifica não só quem é o usuário, mas também se ele pode acessar aquele registro específico?
• Existe uma forma de encontrar e desativar as contas de administrador?

Depois, rastreie uma transação real de ponta a ponta, do clique no botão à linha no banco de dados e ao painel do provedor. Isso ensina mais do que ler arquivos isoladamente.

Quais problemas de segurança aparecem com mais frequência?

Em projetos herdados, os achados raramente são exóticos. Estes são os que verifico primeiro:

• Segredos no repositório. Chaves de API e senhas commitadas no código ou no histórico do git. A correção é trocá-las; apagar o arquivo não basta.
• Verificações de autorização ausentes. Um usuário logado consegue ler ou editar dados de outro usuário trocando um ID na requisição.
• Regras de acesso ao banco de dados deixadas abertas. Isso é especialmente comum em apps construídos às pressas sobre backends gerenciados como o Supabase, onde as políticas de row level security precisam ser ativadas e escritas de forma deliberada. A ferramenta não é o problema; o que você audita é a configuração.
• Webhooks sem assinatura ou sem verificação. Qualquer pessoa que descubra a URL pode forjar um evento de pagamento.
• Dependências desatualizadas. Vulnerabilidades conhecidas em pacotes que ninguém atualizou. Rode o comando de auditoria do seu ecossistema e leia os resultados por severidade.
• Permissões amplas demais. Logins de administrador compartilhados, papéis na nuvem com acesso total, buckets de armazenamento públicos.
• Tratamento fraco de entradas. Entradas não validadas chegando a queries, uploads de arquivos ou páginas renderizadas.
• Sem backups, ou com backups nunca testados. Um backup que você nunca restaurou é uma esperança, não um backup.
• Logs e monitoramento ruins. Dados sensíveis nos logs e nenhum alerta quando os erros disparam.

Este é um checklist prático, não um teste de invasão formal. Se você lida com dados regulados, como dados de saúde ou de cartão de pagamento, consulte uma empresa de segurança qualificada e seu advogado sobre suas obrigações. Este artigo não é aconselhamento jurídico.

O que o relatório de auditoria deve conter?

Um relatório que só lista problemas é difícil de colocar em prática. A versão útil ajuda um fundador não técnico a decidir o que fazer em seguida. Eu esperaria estas partes:

1. Resumo. Uma página: condição geral, os principais riscos e uma recomendação clara.
2. Inventário de acessos e propriedade. O que você tem, o que falta e quem precisa entregar.
3. Achados de build e deploy. Se o projeto roda do zero e os passos necessários para corrigir as lacunas.
4. Revisão dos fluxos de dinheiro. O que foi rastreado, o que foi encontrado e o que exige ação urgente.
5. Achados de segurança. Cada um com severidade, evidência e uma correção sugerida.
6. Notas de manutenibilidade. Cobertura de testes, idade das dependências, estrutura do código, documentação e a dívida técnica que vai atrasar o trabalho futuro.
7. Plano priorizado. O que fazer nesta semana, neste mês e depois, com esforço estimado em termos relativos, como pequeno, médio e grande.

Desconfie de relatórios que prometem prazos exatos antes de o build funcionar, ou que concluem que o código precisa ser reescrito sem mostrar evidências. Na minha experiência, um caminho incremental que mantém o produto no ar costuma ser mais seguro do que uma reescrita completa, que também tende a custar mais porque o sistema antigo precisa continuar rodando em paralelo. Quando liderei a migração de uma plataforma de candidaturas a vagas em produção na avanzzada, levamos toda a arquitetura para uma nova stack enquanto as pessoas continuavam usando o sistema todos os dias, e fazer isso peça por peça foi o que tornou isso possível. Ainda assim, é uma regra prática, e a auditoria é onde você a testa contra o seu sistema real.

Quer uma segunda opinião sobre a sua base de código herdada?

Se você está assumindo uma base de código e quer a visão de um colega, mande um e-mail para me@filipeeduardo.dev com uma breve descrição da situação. Terei prazer em dar uma olhada e dizer o que eu verificaria primeiro.