Due Diligence Técnica: O Que Avaliam no Seu Código

Due diligence técnica é a auditoria que um investidor, um comprador ou um cliente grande faz no seu software antes de assinar. Ela não avalia se o produto funciona, isso o mercado já respondeu. Avalia o risco de continuar existindo: quem consegue mexer no sistema, quanto custa mantê-lo e o que quebra quando alguém sai.

Quem descobre o que é uma due diligence técnica durante uma descobre no pior momento possível. O cronograma já está travado, o comprador já tem o prazo dele, e as respostas precisam sair em dias.

Este guia mostra o que é perguntado, por área, e o que dá para arrumar antes.

Quem pede uma due diligence técnica e por quê

Três situações trazem o auditor até você, e elas pedem coisas diferentes.

Investidor em rodada de captação. O foco é escalabilidade e custo futuro. A pergunta por trás de tudo é quanto vai custar crescer dez vezes com este código. Um sistema que funciona para mil usuários e exige reescrita para dez mil deixa de ser assunto de engenharia e vira item de valuation.

Comprador em fusão ou aquisição. O foco é passivo. O que existe aqui que eu vou herdar. Licença de software mal resolvida, dependência de uma pessoa, contrato de fornecedor sem cláusula de saída, tudo isso vira desconto no preço ou cláusula de retenção.

Cliente enterprise antes de assinar contrato. O foco é continuidade e segurança. Se eu colocar meu processo crítico dentro do seu sistema, o que acontece se você sumir. É a forma mais subestimada, porque chega com o nome de questionário de fornecedor, por email, com cara de burocracia.

As três versões olham o mesmo lugar. A diferença está no peso que dão a cada achado.

As cinco áreas avaliadas

Arquitetura e escalabilidade

O auditor quer entender onde o sistema quebra quando o volume cresce e quanto custa consertar. Ele olha acoplamento entre módulos, pontos únicos de falha, e se existe alguma separação clara entre o que é regra de negócio e o que é infraestrutura.

Os padrões que mais pesam contra: banco de dados único servindo tudo, processamento síncrono onde deveria ser fila, e regra de negócio espalhada em camada de apresentação. Nenhum desses é fatal isolado. Juntos, dizem que qualquer mudança relevante exige tocar em muitos lugares ao mesmo tempo, e isso é exatamente o que encarece crescer.

Qualidade de código e débito técnico

Aqui interessa saber se alguém que não escreveu o código consegue mexer nele com segurança, e isso tem pouco a ver com o código ser elegante.

Os indicadores práticos são cobertura de teste nas rotinas críticas, presença de ambiente de homologação que reproduza produção, e histórico de commits que permita entender por que uma decisão foi tomada. Um repositório com mensagens de commit genéricas e sem testes não prova que o código é ruim, prova que a manutenção depende de memória de gente, e memória de gente pede demissão.

Vale entender antes como medir e priorizar dívida técnica, porque o auditor vai pedir número, não adjetivo.

Segurança e conformidade

É a área onde mais se reprova, porque tem resposta binária.

Dependências com vulnerabilidade conhecida e sem atualização, segredo versionado no repositório, ausência de controle de acesso por papel, log sem trilha de quem fez o quê. O OWASP Top 10 lista as categorias de vulnerabilidade mais críticas em aplicação web e serve de ponto de partida para essa checagem. A varredura de dependências pode ser feita com ferramenta aberta como o OWASP Dependency-Check.

Do lado de conformidade, no Brasil o piso é a Lei 13.709 de 2018, a LGPD. A pergunta vai além da política de privacidade publicada: o auditor quer saber se o sistema consegue atender um pedido de exclusão de dados, se há registro de consentimento e se dado pessoal trafega e repousa criptografado. Política no rodapé sem implementação no banco é achado, não conformidade.

Para processo de desenvolvimento, o NIST Secure Software Development Framework organiza as práticas de desenvolvimento seguro. Nos Estados Unidos, desde março de 2024, fornecedores de software do governo federal precisam assinar um formulário de atestação de desenvolvimento seguro publicado pela CISA com a OMB, o que tende a chegar por tabela a quem vende para empresas com operação lá.

Operação e continuidade

Quanto tempo leva para subir uma correção. Como se descobre que algo quebrou, por monitoramento ou por reclamação de cliente. Existe restauração de backup testada, ou só backup configurado.

A pergunta mais desconfortável dessa área é a de dependência de pessoa. Se o desenvolvedor que conhece o núcleo do sistema sair amanhã, quantos dias até alguém conseguir fazer um deploy com segurança. Sistema que só uma pessoa entende é risco de continuidade, e entra no relatório como tal.

Quem tem observabilidade com log, métrica e trace responde essa parte em minutos. Quem não tem responde com estimativa, e estimativa em due diligence conta como não sei.

Propriedade intelectual e contratos

Quem é dono do código. Parece óbvio até alguém pedir o documento que prova.

Os pontos verificados são cessão de direitos autorais assinada por todo desenvolvedor que tocou no sistema, incluindo terceirizado e estagiário; licenças das bibliotecas de terceiros, porque licença copyleft em produto proprietário é problema jurídico real; e contrato com fornecedor de desenvolvimento que defina propriedade, acesso ao repositório e o que acontece no encerramento.

Esse é o achado que mais trava negócio, porque não se resolve com trabalho técnico. Se falta assinatura de alguém que saiu da empresa há três anos, o caminho é jurídico e demorado.

O que a Out Limit encontrou no próprio site

Em 19 e 20 de setembro de 2026 rodamos no nosso próprio domínio o mesmo processo que aplicamos em cliente. O resultado serve melhor que exemplo hipotético.

O sitemap declarava 26 URLs e nenhuma delas respondia direto. Todas retornavam 308, porque o arquivo listava o domínio sem www enquanto o servidor entregava com www. A tag canonical de cada artigo apontava para o mesmo endereço que redirecionava, o que significa que o buscador descartava a canonical declarada e escolhia sozinho qual URL indexar. Perdemos o controle da canonicalização do próprio site sem perceber.

Dois artigos publicados tinham 115 e 182 palavras. Eram rascunhos que ficaram no ar, competindo por palavra-chave com as versões completas dos mesmos temas, de 827 e 934 palavras.

O dado estruturado de autoria declarava a empresa como pessoa física. O campo author saía com tipo Person e nome "Equipe Out Limit", apontando para a página institucional no LinkedIn. Afirmava ao buscador algo que não se sustenta na verificação.

O deslocamento de layout medido era 0,142, acima do limite de 0,1. A causa não era a imagem, que já declarava dimensão. Era a troca de fonte web, que refluía o texto e empurrava o bloco da capa para baixo depois da primeira pintura.

Nenhum desses achados aparece olhando o site, e todos aparecem em dez minutos de verificação com ferramenta. Corrigimos os quatro em dois dias. A causa do problema de canonicalização estava numa única constante do código, mas a correção só funcionou depois de revisar também 26 registros no gerenciador de conteúdo, que sobrescreviam o valor do código. É o tipo de detalhe que só aparece quando alguém de fato mede o resultado depois de mexer. É exatamente assim que uma due diligence funciona, e é por isso que ser auditado sem preparo surpreende.

Cinco achados fáceis de evitar e caros de explicar

Todos aparecem em varredura automática ou em uma única pergunta do auditor, e todos custam pouco para resolver antes:

1. Segredo versionado no repositório. Chave de API, senha de banco ou token no histórico do git. Mesmo removido depois, continua no histórico e é recuperável.
2. Dependência desatualizada com vulnerabilidade pública. Aparece em varredura automática, aparece no relatório, e é o achado mais fácil de evitar.
3. Ausência de ambiente de homologação equivalente a produção. Significa que toda mudança é testada em produção, com cliente dentro.
4. Cessão de propriedade intelectual incompleta. Algum desenvolvedor sem contrato de cessão assinado.
5. Nenhum teste automatizado nas rotinas críticas. Não impede fechar negócio, mas muda o preço, porque aumenta o custo estimado de manutenção.

Quando o achado não dá para corrigir a tempo

Nem tudo cabe em 90 dias. Cessão de propriedade intelectual de alguém que saiu há anos, reescrita de um módulo acoplado, troca de um fornecedor com contrato vigente, nada disso se resolve antes do prazo do comprador.

O caminho que funciona é precificar o problema em vez de escondê-lo. O auditor vai encontrar, e achado encontrado por ele custa mais caro que achado apresentado por você, porque muda a percepção de todo o resto do relatório.

O formato que funciona tem quatro linhas por item: qual é o achado, qual o impacto real se não for resolvido, quanto custa resolver em tempo e dinheiro, e qual a data em que estará resolvido. Um item com dono e data vira cronograma de integração. O mesmo item sem dono vira desconto no preço ou dinheiro retido em conta de garantia.

Há uma exceção que não admite negociação. Vazamento de dado pessoal não comunicado, uso de biblioteca com licença incompatível em produto que já foi vendido, e cobrança por funcionalidade que não existe são itens que param a operação em vez de reduzir o preço. Se algum deles estiver na sua lista, o interlocutor deixa de ser o time técnico do comprador e passa a ser o jurídico dos dois lados.

O questionário de fornecedor é a mesma auditoria com outro nome

Uma empresa de médio porte pode nunca passar por uma due diligence de aquisição e ainda assim receber questionário de segurança de cada cliente grande que atender. É a mesma avaliação, em formato de planilha, e chega sem aviso no meio de uma negociação comercial.

As diferenças práticas são três. O prazo é mais curto, porque o questionário chega no meio de uma negociação comercial que já tem data para fechar. Quem pergunta é o time de segurança do cliente, não um consultor contratado. E a resposta pode virar anexo contratual, ou seja, o que você afirma ali passa a ser obrigação.

Por isso vale montar uma base de respostas antes de precisar. Boa parte das perguntas se repete de um cliente para outro: onde o dado fica hospedado, quem tem acesso, há autenticação de dois fatores, há plano de resposta a incidente, há teste de restauração de backup, qual o prazo de notificação em caso de vazamento. Responder cada questionário do zero consome dias de engenharia sênior e gera respostas inconsistentes entre clientes, o que é pior que demorar.

Uma base pronta transforma a resposta em revisão, de dias para horas, e evita que dois clientes recebam versões diferentes da mesma informação.

Como se preparar antes de ser auditado

A preparação não é cosmética, e por isso demora. Um plano de 90 dias, na ordem que reduz mais risco por hora investida:

Primeiros 30 dias, o que é binário. Varrer o repositório atrás de segredo versionado e rotacionar tudo que for encontrado. Atualizar dependência com vulnerabilidade conhecida. Levantar quem tem acesso a quê e cortar o que sobra. São itens que reprovam sozinhos e que se resolvem com trabalho, não com decisão.

Dias 30 a 60, o que precisa de terceiro. Reunir contrato de cessão de todo desenvolvedor que tocou no sistema, inclusive quem já saiu. Levantar licença de cada biblioteca de terceiro. Revisar contrato de fornecedor procurando cláusula de propriedade e de saída. Envolve jurídico e gente de fora, então começa cedo.

Dias 60 a 90, o que vira narrativa. Documentar arquitetura em um diagrama que um estranho entenda. Escrever o procedimento de deploy e o de restauração de backup, e testar os dois. Registrar as decisões técnicas importantes e o porquê de cada uma.

Esse último bloco é o que separa uma auditoria tensa de uma tranquila. O auditor não espera encontrar um sistema perfeito, ele espera encontrar alguém que saiba onde estão os problemas. Empresa que apresenta a própria lista de dívidas, com prazo e responsável, passa uma impressão oposta à de quem é pego de surpresa.

O que fazer com isso agora

Se existe rodada, venda ou cliente grande no horizonte dos próximos seis meses, a hora de rodar o levantamento é antes de alguém pedir. Os achados de segurança e de propriedade intelectual são os que demoram mais e os que mais custam no preço final.

Se não existe nada no horizonte, o mesmo levantamento continua valendo, só que por outro motivo: ele responde quanto custa manter o que você tem e o que trava quando alguém sai. É a mesma pergunta que um diagnóstico de TI antes de reestruturar tenta responder.

Pré-diagnóstico técnico

Fazemos um levantamento do seu sistema nas cinco áreas acima e entregamos a lista de achados com prioridade e estimativa de esforço. Sem compromisso e sem acesso ao seu código, o diagnóstico parte do que é observável de fora.