Auditoria de código: o que um fundador não técnico está de fato comprando

Seu desenvolvedor acabou de pedir demissão, ou a agência que você contratou quer a segunda metade do pagamento. Você precisa de alguém para dizer se o código presta. Veja o que é essa inspeção, quem deve conduzi-la e como ler o resultado quando você não sabe ler código.

A mensagem chega na caixa de entrada de muito fundador mais cedo ou mais tarde, quase sempre num domingo à noite. O desenvolvedor principal pediu demissão. Ou o freelancer de dois anos atrás parou de responder. Ou uma agência está cobrando a nota final e algo no seu estômago diz que aquilo que eles construíram está preso com fita adesiva. Você encaminha o link do repositório para a única pessoa técnica em quem confia e escreve a mesma frase que todo mundo escreve: dá uma olhada nisso e me fala se está bom?

Esse pedido tem nome. Uma auditoria de código é uma revisão estruturada de uma base de código, feita por alguém que não a escreveu, para te dizer em que estado ela está: o quanto está exposta a falhas de segurança, o quão difícil será mudá-la, se ela realmente faz o que deveria, e quanto dela depende de uma única pessoa que pode ir embora. É a segunda opinião que você pede antes de confiar o futuro da sua empresa a um monte de software. O termo soa técnico, e o relatório vai ser, mas a decisão de encomendar uma auditoria é uma decisão de negócio, e ela quase sempre cai na mesa de alguém que não consegue ler uma linha do código em questão. Essa pessoa costuma ser o fundador. Este texto é para ela.

O que é, de fato, uma auditoria de código

Tire o ferramental e o jargão, e uma auditoria de código responde a uma pergunta que o fundador de fato tem: se eu continuar construindo em cima disso, em cima de que eu estou pisando?

Um auditor lê o código-fonte, roda scanners automáticos, observa como o código está organizado, verifica o que está testado e o que não está, e revisa como o sistema é colocado no ar e quem tem as chaves. Depois escreve um relatório. Os bons escrevem duas vezes: um apêndice técnico para quem herdar o código, e um resumo em português claro para a pessoa que pagou pela auditoria. Se você só recebeu o apêndice técnico, recebeu metade do que comprou.

Ajuda dizer o que uma auditoria de código não é. Não é uma análise do produto, então ela não vai te dizer se o produto é bom. Não é um teste de invasão, embora se sobreponha a um. E não é a mesma coisa que technical due diligence, que é a versão que um comprador ou investidor faz numa empresa em que está prestes a colocar dinheiro. A mecânica rima. O contexto, não. A due diligence pergunta “eu devo fechar esse negócio”. A auditoria de código pergunta “eu devo confiar no código pelo qual já paguei”. Você audita a sua própria casa. Você faz due diligence na casa dos outros.

As quatro coisas que uma auditoria de fato examina

Pesquise por aí e vão te dizer que existem “quatro tipos de auditoria”, normalmente uma lista de siglas de compliance como SOC 2 e HIPAA. Para um fundador não técnico construindo um produto de verdade, esse recorte é quase todo ruído. Aqui estão as quatro coisas que importam, na ordem em que costumam te machucar.

Segurança. Um estranho consegue entrar, ler os dados dos seus clientes ou passar o cartão deles? É aqui que o auditor verifica como as senhas são guardadas, como o sistema decide quem pode fazer o quê, e se os buracos óbvios estão abertos. É a parte que todo mundo pensa primeiro, e para uma fintech ou uma healthtech é a parte que pode acabar com a empresa.

Manutenibilidade. O quão difícil é mudar esse código daqui a seis meses? Um sistema pode ser perfeitamente seguro e ainda assim ser um pântano: sem estrutura, sem testes, cada alteração arriscando quebrar outras três coisas em algum lugar. A manutenibilidade é o assassino silencioso, porque não aparece como crise. Aparece como cada feature nova levando três vezes mais tempo que a anterior. O que o auditor está medindo aqui é, em bom português, a sua dívida técnica: os juros que você vai pagar depois pelos atalhos tomados agora.

Correção. Ele faz o que deveria fazer, e como você sabe disso? Essa é a pergunta da cobertura de testes. Código sem testes automáticos não é necessariamente errado, mas ninguém consegue mexer nele com confiança, porque não há rede embaixo do trapézio. Um auditor vai te dizer quanto do sistema é verificado automaticamente e quanto depende de alguém clicando por aí e torcendo.

Risco operacional. O que acontece às 2 da manhã quando dá pau, e quem sabe consertar? Isso cobre como o sistema é colocado no ar, se algo tem backup, onde ficam as senhas e quantas pessoas entendem a coisa inteira. Se a resposta para a última for “uma”, você não tem uma base de código, você tem um refém. É o mesmo problema de um bus factor de um, e a auditoria costuma ser a primeira vez que um fundador vê isso escrito.

Uma auditoria de verdade avalia as quatro. Se o relatório só fala de segurança, você comprou um scan de segurança e alguém chamou de auditoria.

Por que fundadores acabam precisando de uma

Ninguém acorda querendo uma auditoria de código. Você é empurrado para ela. Na nossa experiência, o gatilho é quase sempre uma de quatro cenas.

A primeira é o desenvolvedor que pede demissão. Seu único engenheiro entrega o aviso, e o produto inteiro vira, de repente, um ativo que ninguém no time consegue ler. A auditoria te diz o tamanho do buraco antes de você contratar para preenchê-lo.

A segunda é o freelancer que some. Você lançou uma versão dois anos atrás com um desenvolvedor independente ou uma pequena fábrica, a relação esfriou, e agora você quer construir em cima do que ficou. Você não faz ideia se está ampliando uma casa ou uma barraca.

A terceira é a aquisição. Você está comprando uma empresa pequena, ou um ativo de dentro de uma, e o código vem junto. É aqui que auditoria e due diligence se confundem, mas as perguntas são as mesmas: o que eu estou de fato levando.

A quarta é o instinto. Seu fornecedor atual está pedindo mais dinheiro ou mais prazo, as explicações começaram a soar como previsão do tempo, e você quer uma leitura independente antes de assinar qualquer outra coisa. Esse é o gatilho mais saudável, porque você está agindo antes da crise em vez de depois.

As quatro têm o mesmo formato. Alguém que descreve o negócio com precisão total não consegue avaliar a coisa em cima da qual o negócio roda, e a distância finalmente ficou cara o suficiente para se pagar para fechá-la.

Quem deve conduzir, e quem nunca deveria

Aqui está a regra que mais importa, e a que os fornecedores vão discretamente te convencer a abrir mão: quem escreveu o código nunca deveria ser quem audita o código. Você não pede para o eletricista inspecionar a própria fiação. Todo o valor de uma auditoria está no olho de fora, e um olho de fora que também é o autor é só um relatório de status numa fonte mais bonita.

Isso corta três opções tentadoras. Corta a agência que construiu a coisa, que é claro vai te dizer que está sólido. Corta o desenvolvedor que está saindo, cujo resumo vai ser moldado por como está sendo a saída. E em geral corta a sua própria próxima contratação, porque pedir para um candidato abençoar o código que ele está prestes a herdar o coloca numa posição impossível no primeiro dia.

O que você quer é um engenheiro sênior neutro ou uma pequena firma que faça isso para viver e não queira o contrato de reconstrução depois. Essa última parte é a importante. Um auditor que também vende desenvolvimento tem motivo para achar a base de código irrecuperável. Pergunte direto, antes de contratar: se essa auditoria disser que o código está bom, você recebe o mesmo tanto? A resposta te diz se você está comprando uma opinião ou um pitch de vendas. Na Pixel Breeders já fizemos auditorias em que o achado honesto foi “isso está em estado melhor do que você imagina, gaste o dinheiro em features”. Um bom auditor topa se convencer de menos trabalho, e os que não conseguem são justamente os que você mais precisa evitar.

Quanto tempo leva e quanto custa

Para uma base de código típica de estágio inicial, um produto, alguns anos de histórico, um time pequeno, uma auditoria de verdade leva de alguns dias a duas semanas. Uma revisão focada só em segurança pode ser três ou quatro dias. Uma auditoria completa das quatro frentes num sistema de tamanho relevante é uma a duas semanas de tempo sênior, às vezes mais se a configuração de infra for um mistério que precisa ser desvendado na marra.

O custo acompanha isso diretamente, porque você está comprando horas sênior, não uma assinatura de ferramenta. Os scanners automáticos são baratos, alguns gratuitos, e um fornecedor que se apoia inteiramente neles vai te cobrar suspeitosamente pouco. A parte cara e valiosa é uma pessoa que já viu cem bases de código lendo a sua e te dizendo quais dos duzentos problemas apontados pelo scanner de fato importam. Reserve alguns milhares para uma revisão bem delimitada e a casa das dezenas de milhares para uma auditoria minuciosa de um sistema maior. Se alguém te oferece uma “auditoria completa” por algumas centenas, é uma ferramenta rodando e te mandando a saída por e-mail, e isso você faz sozinho.

Uma coisa que vale pagar: uma cláusula de reverificação. Uma boa auditoria termina com uma lista priorizada de correções. Poder trazer o auditor de volta para confirmar que as críticas foram feitas, um mês depois, vale mais que o relatório original, porque fecha o ciclo em vez de te deixar com um PDF e uma prece.

Lendo o relatório quando você não sabe ler código

Essa é a parte sobre a qual quase ninguém escreve, e é a parte de que o fundador de fato precisa. A auditoria volta. Tem uma tabela de severidade, provavelmente com cores, com palavras como crítico, alto, médio, baixo. Você não consegue avaliar o código, mas consegue perfeitamente conduzir a decisão, porque severidade se traduz de forma limpa em linguagem de negócio.

Crítico quer dizer pare. Dados de cliente estão expostos, ou dinheiro pode se mover de um jeito que não deveria. Esses são corrigidos antes de a próxima feature subir, ponto-final, sem negociação. Alto quer dizer agende. É um risco real ou um peso real sobre o time, e vai para o topo da fila, mas não para a linha hoje à noite. Médio e baixo são o backlog. Reais, vale saber, não vale entrar em pânico. O erro que fundadores cometem é tratar uma lista longa de médios como um incêndio de cinco alarmes. Uma lista longa de médios é normal. Toda base de código que já foi para produção tem uma. O que você está procurando é a contagem de críticos e altos, e se eles se concentram nas partes do sistema que tocam dinheiro e identidade.

E tem aquela linha lá no fim que merece o próprio parágrafo, porque é onde fundadores perdem mais dinheiro.

A armadilha do reescrever

Mais cedo ou mais tarde uma auditoria, ou a pessoa que a entrega, chega a uma recomendação que soa decisiva: isso aqui já era, você deveria reconstruir do zero. Às vezes é verdade. Muito mais vezes é o conselho mais caro do prédio, e vale desconfiar dele, ainda mais quando quem dá seria justamente quem seria pago para fazer a reconstrução.

Uma reescrita joga fora não só código, mas cada bug que alguém já encontrou e corrigiu, cada caso estranho de borda que o sistema atual trata em silêncio porque um cliente real bateu nele dois anos atrás. O substituto começa limpo e ingênuo, e reaprende tudo isso do jeito difícil, em produção, com o seu nome nele. Isso não é uma opinião de nicho. A versão mais clara do argumento é o velho ensaio de Joel Spolsky, Things You Should Never Do, escrito depois de ver empresas incendiarem produtos que funcionavam em busca de um recomeço. A economia disso não mudou desde então.

A versão honesta da recomendação de reescrita é quase sempre mais estreita: uma parte disso está genuinamente podre, isole e troque esse pedaço, deixe o resto em paz. Se o seu auditor não consegue te dizer qual módulo específico precisa ser trocado e por que o resto pode ficar, ele não terminou a auditoria. Já escrevemos sobre quando uma reescrita é de fato a decisão certa, e o resumo é: menos vezes do que vão te dizer, e nunca com base numa única frase dramática.

O teste de quatro perguntas para saber se você precisa de uma

Auditorias custam dinheiro de verdade, e nem toda situação pede uma. Antes de encomendar qualquer coisa, rode estas quatro perguntas. É o mesmo formato que usamos internamente quando um fundador pergunta se vale a pena.

Primeira: estou prestes a tomar uma decisão irreversível com base nesse código? Liberar um pagamento grande, assinar um contrato de construção, fechar uma aquisição, apostar uma rodada num demo. Se sim, audite primeiro. O custo da auditoria é um arredondamento perto do custo da decisão.

Segunda: alguém do meu lado hoje consegue ler esse código? Se a resposta é não, e ele está virando estrutural, a auditoria está te comprando olhos que você não tem.

Terceira: o custo de errar aqui é medido em clientes ou só em tempo? Uma fintech movendo dinheiro de verdade e um site de conteúdo têm respostas diferentes, e a primeira deveria auditar muito mais cedo que o segundo.

Quarta: eu tenho uma pessoa independente que consegue fazer, que não quer o trabalho que vem depois? Se você não tem, encontrar essa pessoa é a tarefa de verdade, e vale mais do que apressar a auditoria em si.

Se você respondeu sim às três primeiras e tem um nome para a quarta, encomende a auditoria. Se é não em todas, o que você tem é uma base de código normal com dívida normal, e seu dinheiro rende mais entregando produto.

Uma auditoria de código, bem feita, não é um veredito baixado por alguém mais esperto que você. É uma tradução. Ela pega a única parte da sua empresa que você não consegue ler e a transforma numa lista de decisões que você consegue, sim, tomar. Os fundadores que se queimam não são os que não sabem programar. São os que continuaram assinando sem nunca pedir a tradução.

FAQ

O que significa uma auditoria de código?
Uma auditoria de código é uma revisão estruturada de uma base de software feita por alguém que não a escreveu, avaliando segurança, manutenibilidade, correção e risco operacional, e relatando em que estado ela está. Para um dono não técnico, é uma segunda opinião sobre um código que você pagou, entregue como uma lista de decisões de negócio, não como um veredito sobre o código em si.

Quanto tempo leva uma auditoria de código?
Para um produto típico de estágio inicial com alguns anos de histórico, uma auditoria minuciosa leva de alguns dias a duas semanas de tempo de engenharia sênior. Uma revisão só de segurança pode ser três ou quatro dias. A variável é quanto da infra e da arquitetura precisa ser desvendado porque ninguém documentou.

Quais são os quatro tipos de auditoria?
A resposta cheia de siglas lista frameworks de compliance, mas para um fundador as quatro lentes úteis são segurança (alguém consegue invadir), manutenibilidade (o quão difícil é mudar), correção (funciona e como você sabe) e risco operacional (o que acontece quando dá pau e quem conserta). Uma auditoria de verdade avalia as quatro, não só segurança.

Quem normalmente conduz auditorias de código?
Um engenheiro sênior neutro ou uma firma especializada que não escreve o código em si. A única regra que importa: nunca quem construiu, e de preferência ninguém que lucre com a reconstrução que possa recomendar. Pergunte se ele recebe o mesmo caso a auditoria volte limpa. A resposta te diz se você está comprando uma opinião ou um pitch de vendas.

Quanto custa uma auditoria de código?
Você está comprando horas sênior, não uma ferramenta, então o custo escala com o tamanho e a bagunça do sistema, de alguns milhares para uma revisão bem delimitada à casa das dezenas de milhares para uma auditoria minuciosa de uma base maior. Uma “auditoria completa” por algumas centenas é um scan automático com o nome de uma pessoa colado, e isso você roda sozinho.