Código-Fonte como Evidência: Critérios de Análise em Disputas Técnicas e Contratuais

Sumário técnico

O código-fonte pode ser uma das evidências mais relevantes em disputas envolvendo desenvolvimento de software, customização de sistemas, propriedade intelectual, continuidade de projetos, falhas de funcionamento, alegações de plágio, uso indevido de componentes, descumprimento contratual ou divergências sobre entregas técnicas.

Entretanto, a análise de código-fonte em contexto pericial exige cautela. O código não deve ser examinado de forma isolada, como se fosse suficiente para explicar toda a controvérsia. Ele precisa ser interpretado em conjunto com requisitos, contrato, documentação técnica, repositórios de versionamento, ambiente de execução, dados, logs, testes, histórico de commits, arquitetura, bibliotecas, dependências, integrações e evidências de uso.

Em disputas corporativas, o exame técnico de código-fonte busca responder perguntas objetivas: o software entregue corresponde ao escopo contratado? O código permite executar as funções previstas? Há indícios de cópia, reutilização não autorizada ou incorporação de componentes de terceiros? As falhas alegadas decorrem de defeitos no código ou de fatores externos? O projeto foi desenvolvido de modo rastreável? Há elementos suficientes para manutenção, auditoria ou continuidade por outro fornecedor?

A finalidade da análise não é produzir uma avaliação genérica de “bom” ou “mau” código, mas identificar achados técnicos relevantes para a controvérsia.

1. Quando o código-fonte se torna relevante

Nem toda disputa de software exige exame de código-fonte. Em muitos casos, a controvérsia pode ser esclarecida por requisitos, logs, testes, documentos de aceite, tickets de suporte ou registros de implantação. A análise de código torna-se especialmente relevante quando há discussão sobre elementos que dependem da estrutura interna do sistema.

Situações recorrentes incluem:

Descumprimento de escopo
Quando se discute se determinada funcionalidade foi efetivamente desenvolvida ou apenas simulada na interface.

Falhas técnicas recorrentes
Quando defeitos, erros, inconsistências ou comportamentos inesperados precisam ser relacionados a trechos específicos de implementação.

Propriedade intelectual
Quando há alegação de reprodução, apropriação, reutilização indevida ou desenvolvimento derivado de código preexistente.

Licenciamento
Quando se discute o uso de bibliotecas, frameworks, componentes open source, SDKs, APIs ou módulos proprietários.

Continuidade de projeto
Quando a organização precisa verificar se o código entregue permite manutenção, evolução ou transição para outro fornecedor.

Autoria e evolução
Quando o histórico de desenvolvimento, commits, branches ou padrões de contribuição podem ajudar a reconstruir o desenvolvimento do projeto.

Segurança
Quando vulnerabilidades ou falhas de controle precisam ser avaliadas no código, como validação de entradas, criptografia, permissões, autenticação ou exposição de dados.

2. O que deve ser preservado

A coleta de código-fonte deve preservar não apenas arquivos finais, mas também elementos que permitam compreender sua origem, evolução e contexto. Uma pasta compactada com código pode ser útil, mas frequentemente é insuficiente para análise técnica aprofundada.

Materiais frequentemente necessários

• repositório de versionamento;
• histórico de commits;
• branches e tags;
• arquivos de configuração;
• dependências;
• documentação técnica;
• scripts de build;
• scripts de implantação;
• arquivos de ambiente;
• pipelines de CI/CD;
• issues, tickets e pull requests;
• comentários de revisão;
• registros de merge;
• releases;
• changelogs;
• testes automatizados;
• documentação de APIs;
• diagramas de arquitetura;
• contratos de licenciamento;
• inventário de bibliotecas;
• evidências de homologação;
• logs de execução;
• bases de teste, quando aplicável.

A preservação deve manter metadados relevantes e, quando possível, registrar valores de integridade dos arquivos ou pacotes coletados. Em disputas complexas, a ausência do histórico de versionamento pode limitar de forma significativa a análise.

3. Perguntas orientadoras do exame técnico

A análise pericial de código-fonte pode ser organizada por perguntas. Essa abordagem evita que o relatório se transforme em uma revisão ampla e pouco conectada ao objeto da disputa.

Pergunta 1 — O código examinado corresponde à versão discutida?

Antes de analisar conteúdo, é necessário verificar se o material fornecido corresponde à versão relevante do sistema. Em muitos projetos, há múltiplas versões, ambientes, branches, forks ou pacotes de implantação.

Pontos analisáveis:

• identificação da versão;
• data dos commits;
• tags de release;
• correspondência com ambiente de produção;
• compatibilidade com artefatos implantados;
• divergência entre repositório e código em execução;
• documentação de entrega;
• histórico de alterações após a controvérsia.

Sem essa verificação, há risco de analisar código que não corresponde ao sistema efetivamente utilizado.

Pergunta 2 — As funcionalidades contratadas estão implementadas?

Essa análise exige comparar requisitos e entregas com módulos, classes, funções, rotas, componentes, telas, APIs, regras de negócio e integrações presentes no código.

O exame pode indicar:

• funcionalidade implementada;
• funcionalidade parcialmente implementada;
• funcionalidade ausente;
• funcionalidade presente, mas inacessível;
• funcionalidade simulada;
• funcionalidade dependente de integração externa;
• funcionalidade implementada de forma incompatível com o requisito.

A conclusão deve estar vinculada a requisitos específicos, e não a expectativas genéricas.

Pergunta 3 — As falhas alegadas decorrem do código?

Quando há alegação de defeito, o exame pode buscar relação entre comportamento observado e implementação. Porém, falhas percebidas pelo usuário podem decorrer de código, dados, configuração, infraestrutura, permissões, integração, parametrização ou uso.

A análise pode envolver:

• reprodução da falha;
• identificação de exceções;
• leitura de logs;
• revisão do fluxo de execução;
• verificação de tratamento de erros;
• análise de consultas;
• validação de regras de negócio;
• exame de dependências;
• comparação entre ambiente de teste e produção.

A conclusão deve distinguir defeito de código, falha de configuração, limitação do sistema e problema externo.

Pergunta 4 — O código contém componentes de terceiros?

Em disputas de licenciamento ou propriedade intelectual, é relevante verificar a presença de bibliotecas, frameworks, trechos reutilizados, componentes proprietários, pacotes open source ou dependências com restrições de uso.

Elementos analisáveis:

• arquivos de dependência;
• manifests;
• headers de licença;
• comentários;
• pacotes importados;
• repositórios públicos;
• bibliotecas embarcadas;
• arquivos minificados;
• módulos de terceiros;
• documentação de licenciamento.

A análise deve ser cuidadosa, pois o uso de componentes de terceiros não é necessariamente irregular. O ponto técnico é verificar quais componentes existem, sob quais condições são utilizados e se há compatibilidade com o escopo contratual ou licença aplicável.

Pergunta 5 — Há indícios de cópia ou desenvolvimento derivado?

Em alegações de plágio, apropriação ou reprodução indevida, a análise pode comparar estruturas, nomes, comentários, arquitetura, fluxos, algoritmos, organização de arquivos, padrões de codificação e similaridades não triviais.

Deve-se distinguir:

• semelhanças decorrentes de padrões de mercado;
• uso comum de frameworks;
• trechos gerados automaticamente;
• código boilerplate;
• bibliotecas públicas;
• implementação independente de mesma funcionalidade;
• similaridade estrutural relevante;
• reprodução literal ou quase literal;
• adaptação de código preexistente.

A análise de similaridade exige critérios técnicos e documentação dos trechos comparados.

Pergunta 6 — O código é auditável e mantível?

Em disputas sobre continuidade de projeto, pode ser necessário verificar se o material entregue permite manutenção razoável por equipe técnica. Isso não significa exigir perfeição, mas avaliar se há elementos mínimos para compreensão, compilação, execução e evolução.

Aspectos examináveis:

• organização do repositório;
• documentação de instalação;
• dependências declaradas;
• scripts de build;
• testes;
• padrões de nomenclatura;
• modularidade;
• separação de responsabilidades;
• comentários relevantes;
• ausência de credenciais expostas;
• configuração de ambientes;
• documentação de APIs;
• consistência entre código e documentação.

A avaliação deve ser proporcional ao porte do projeto, ao contrato, à metodologia adotada e ao grau de maturidade esperado.

4. Tipos de análise aplicáveis

O exame de código-fonte pode empregar diferentes abordagens, conforme o objeto da controvérsia.

A escolha da abordagem deve ser justificada no relatório técnico.

5. Repositórios e histórico de desenvolvimento

Repositórios de versionamento são fontes relevantes porque documentam a evolução do software. Eles podem indicar quando uma funcionalidade foi criada, alterada, removida, corrigida ou incorporada a determinada versão.

Elementos relevantes incluem:

• autores dos commits;
• datas e horários;
• mensagens de commit;
• branches;
• merges;
• pull requests;
• revisões;
• tags de release;
• alterações por arquivo;
• comparação entre versões;
• períodos de baixa ou intensa atividade;
• correções após abertura de chamados;
• alterações posteriores ao litígio.

O histórico deve ser analisado com cautela. Mensagens de commit podem ser imprecisas, autores podem usar contas compartilhadas, datas podem depender de configurações locais e nem toda alteração relevante tem descrição adequada. Ainda assim, quando preservado corretamente, o versionamento contribui para a rastreabilidade do projeto.

6. Código-fonte, ambiente e execução

Código-fonte não funciona no abstrato. Ele depende de ambiente de execução, banco de dados, variáveis de configuração, serviços externos, permissões, infraestrutura, versões de bibliotecas e dados.

Por isso, a análise deve considerar:

• linguagem e versão;
• frameworks;
• banco de dados;
• dependências;
• sistemas operacionais;
• containers;
• configurações;
• variáveis de ambiente;
• serviços externos;
• APIs;
• filas;
• certificados;
• permissões;
• arquivos de configuração;
• dados mínimos para teste;
• scripts de implantação.

Quando esses elementos não estão disponíveis, a análise pode ficar limitada à leitura estática do código, sem reprodução de comportamento. Essa limitação deve ser explicitada.

7. Segurança e exposição de informações sensíveis

O exame de código-fonte pode revelar riscos de segurança. Entre os achados possíveis estão:

• credenciais gravadas no código;
• chaves de API expostas;
• senhas em arquivos de configuração;
• ausência de validação de entrada;
• consultas vulneráveis;
• falhas de autorização;
• criptografia inadequada;
• logs com dados sensíveis;
• armazenamento inseguro;
• dependências desatualizadas;
• permissões excessivas;
• exposição de endpoints administrativos.

Em contexto pericial, esses achados devem ser relacionados ao escopo da análise. A identificação de uma vulnerabilidade não implica, automaticamente, que ela tenha sido explorada ou que tenha causado o dano discutido. A relação causal deve ser demonstrada por evidências complementares.

8. Limitações frequentes

A análise de código-fonte pode ser afetada por limitações relevantes, como:

• ausência de repositório completo;
• falta de histórico de commits;
• versões não identificadas;
• indisponibilidade do ambiente de execução;
• dependências ausentes;
• código parcialmente entregue;
• arquivos compilados sem fonte correspondente;
• documentação inexistente;
• ausência de dados de teste;
• credenciais ou chaves não fornecidas;
• impossibilidade de acesso a sistemas integrados;
• código alterado após os fatos;
• uso de componentes proprietários sem documentação;
• logs indisponíveis;
• escopo contratual ambíguo.

Essas limitações não impedem necessariamente o exame, mas condicionam o alcance das conclusões.

9. Como apresentar achados técnicos

Relatórios sobre código-fonte devem evitar transcrições extensas e descontextualizadas. Trechos de código podem ser necessários, mas precisam estar vinculados à questão técnica discutida.

Uma apresentação adequada deve indicar:

• qual arquivo ou módulo foi examinado;
• qual versão ou commit foi considerado;
• qual requisito ou falha está relacionada;
• qual comportamento técnico foi observado;
• qual evidência complementar confirma ou limita o achado;
• qual conclusão pode ser extraída;
• quais hipóteses permanecem abertas.

Em disputas corporativas, a clareza é tão importante quanto a profundidade técnica. O relatório deve ser compreensível para advogados, gestores, árbitros, magistrados, assistentes técnicos e especialistas de TI.

10. Entregáveis técnicos possíveis

A análise de código-fonte pode resultar em diferentes entregáveis:

• relatório técnico de exame de código-fonte;
• parecer sobre aderência entre código e requisitos;
• análise de versionamento;
• relatório de similaridade;
• parecer sobre licenciamento de componentes;
• análise de manutenibilidade;
• relatório de falhas técnicas;
• análise de vulnerabilidades relacionadas ao escopo;
• matriz entre requisitos e implementação;
• linha do tempo de desenvolvimento;
• subsídios para quesitos;
• assistência técnica em litígio ou arbitragem;
• nota técnica para negociação contratual;
• relatório de limitações para continuidade de projeto.

Cada entregável deve respeitar o escopo e a profundidade efetivamente examinados.

Considerações finais

O código-fonte pode ser uma evidência técnica central em disputas de software, mas seu valor depende do contexto em que é analisado. A leitura isolada do código raramente é suficiente para resolver uma controvérsia corporativa. É necessário relacioná-lo a requisitos, versões, entregas, documentação, logs, testes, ambiente de execução, histórico de desenvolvimento e impactos observados.

A engenharia forense de software busca transformar o código-fonte em evidência compreensível, rastreável e tecnicamente fundamentada. Para isso, diferencia funcionalidades implementadas, defeitos, limitações, componentes de terceiros, padrões de desenvolvimento, histórico de alterações e condições de execução.

Em disputas contratuais, arbitrais ou judiciais, a análise de código-fonte deve ser proporcional ao objeto discutido e transparente quanto às suas limitações. Seu objetivo não é avaliar o estilo de programação de forma abstrata, mas esclarecer fatos técnicos relevantes para a tomada de decisão.

Imagem: iStock.com/whyframestudio