Proveniência de código-fonte em investigações corporativas: correlação entre Git, CI/CD, artefatos de build e endpoints

Introdução

Suspeitas de apropriação indevida de código-fonte costumam chegar à investigação formuladas de maneira aparentemente simples: um ex-colaborador teria levado um repositório; um fornecedor teria incorporado módulos desenvolvidos para a contratante; um concorrente teria lançado produto com funções, estruturas ou defeitos semelhantes; ou uma equipe terceirizada teria reutilizado componentes além do escopo autorizado.

Do ponto de vista pericial, porém, a semelhança entre dois conjuntos de arquivos é apenas uma parte do problema. A questão tecnicamente relevante é a proveniência: quais objetos digitais existiam, em que sequência foram criados ou transformados, quais identidades e sistemas participaram dessas operações e que vínculos podem ser demonstrados entre o código, os ambientes de desenvolvimento e os artefatos efetivamente distribuídos.

Essa reconstrução exige correlacionar fontes que registram aspectos diferentes do ciclo de vida do software. O Git preserva objetos e relações de ancestralidade; a plataforma de hospedagem registra eventos de servidor, revisões e controles de acesso; os sistemas de integração e entrega contínuas documentam etapas de construção; repositórios de pacotes e registries conservam artefatos; e os endpoints dos desenvolvedores podem conter clones locais, arquivos ainda não versionados, históricos do ambiente de desenvolvimento, comandos, caches e fragmentos apagados.

Nenhuma dessas fontes, isoladamente, costuma responder de forma segura quem criou determinado trecho, quando ele foi efetivamente produzido, se houve acesso autorizado, como um binário foi obtido ou se uma coincidência decorre de reutilização, geração automática, dependência pública ou evolução independente. A conclusão pericial emerge da convergência entre vestígios tecnicamente independentes, da avaliação das hipóteses alternativas e da explicitação dos limites do material disponível.

O objeto pericial: proveniência, autoria, acesso e derivação

Em uma investigação corporativa, convém separar conceitos frequentemente tratados como equivalentes:

• proveniência do código-fonte descreve a origem e a evolução de revisões, inclusive os processos de alteração, revisão e integração;
• proveniência de build relaciona um artefato produzido ao código, às dependências, ao ambiente e ao processo usados em sua construção;
• autoria técnica procura atribuir determinada contribuição a uma pessoa ou processo;
• posse ou acesso demonstra que uma identidade ou dispositivo teve condições de obter certo conteúdo;
• similaridade mede características comuns entre implementações;
• derivação avalia se um objeto pode ter sido produzido a partir de outro, consideradas as transformações intermediárias.

A própria especificação SLSA distingue proveniência de fonte, voltada à criação das revisões e aos controles de mudança, de proveniência de build, que conecta o produto da compilação ao código utilizado para gerá-lo (SLSA — Provenance). Essa separação é importante porque um histórico de commits pode documentar a evolução de uma biblioteca sem demonstrar que determinado pacote foi construído a partir dela; inversamente, um artefato pode estar vinculado a um commit por metadados de pipeline sem que o campo de autoria desse commit identifique de modo confiável a pessoa que escreveu o conteúdo.

Antes da coleta, a investigação deve converter a alegação empresarial em proposições técnicas verificáveis:

1. uma versão delimitada do código corporativo existia em determinada data;
2. o produto examinado contém elementos idênticos ou derivados daquela versão;
3. os elementos coincidentes possuem poder discriminante e não decorrem apenas de componentes públicos, estruturas triviais, frameworks ou geração automática;
4. determinada conta, dispositivo ou organização teve acesso ao material relevante;
5. os registros disponíveis mostram aquisição, transformação, integração, build ou distribuição compatíveis com a hipótese investigada;
6. explicações alternativas foram identificadas e testadas.

Essas proposições orientam o escopo e evitam que a análise seja reduzida a uma porcentagem de similaridade. Também mantêm a perícia em seu domínio próprio: descrever tecnicamente os vestígios e o grau de suporte às hipóteses, sem substituir a avaliação jurídica sobre titularidade, licença, segredo empresarial, vínculo contratual ou responsabilidade.

O modelo de dados do Git e seu valor probatório

O Git é um sistema endereçado por conteúdo. Em termos simplificados, armazena blobs para conteúdos de arquivos, trees para diretórios, objetos de commit para revisões e objetos de tag anotada. Cada commit aponta para uma árvore de nível superior, para um ou mais commits pais, e contém informações declaradas de autor, committer, datas e mensagem. A documentação oficial descreve essa estrutura em Git Objects.

Esse modelo oferece propriedades úteis à reconstrução:

• conteúdos idênticos normalmente produzem o mesmo identificador de objeto dentro do mesmo formato de hash;
• o commit referencia um estado completo do projeto, e não apenas uma lista textual de alterações;
• os vínculos entre pais formam um grafo de ancestralidade;
• branches e tags são referências mutáveis ou nomeadas para objetos do grafo;
• objetos ainda existentes podem sobreviver à exclusão de uma referência.

O identificador de um objeto permite verificar sua integridade no contexto do algoritmo utilizado pelo repositório. Historicamente, o Git utiliza SHA-1 e possui mecanismos de transição para SHA-256 (Git hash function transition). Em um relatório, portanto, é necessário registrar o formato do repositório e evitar tratar o identificador Git como se fosse, por si só, um hash pericial universal do arquivo adquirido. Para preservação, é recomendável calcular também hashes externos com algoritmo contemporâneo, sobre os contêineres, exports e imagens coletados.

Autor, committer, pusher e revisor são entidades diferentes

Os campos author e committer de um commit são metadados incorporados ao objeto. Nome, e-mail e data podem ser definidos no cliente que cria o commit; por isso, não constituem autenticação autônoma de identidade. O autor declarado representa quem teria produzido a alteração, enquanto o committer representa quem formou aquela revisão específica. Em operações como rebase, cherry-pick ou aplicação de patch, essas identidades e datas podem divergir.

Uma plataforma colaborativa acrescenta outros papéis: a conta que enviou os objetos ao servidor, a identidade que abriu o pull request, os revisores, quem aprovou ou realizou o merge, a credencial que acionou uma automação e o principal de serviço usado pelo pipeline. A atribuição robusta depende da correlação entre esses papéis e fontes externas, como:

• autenticação corporativa e federação SSO;
• registros de auditoria da plataforma;
• chaves SSH, tokens e aplicativos autorizados;
• endereços IP, agentes de usuário e horários de sessão;
• cadastro e ciclo de vida da conta;
• custódia do endpoint e uso interativo da estação;
• mensagens, tickets e revisões relacionadas à tarefa.

Assinaturas criptográficas em commits e tags elevam a confiança apenas quando a assinatura é validada e a investigação consegue demonstrar a titularidade, a vigência e a política de confiança da chave. O comando git verify-commit, por exemplo, verifica a assinatura GPG presente em commits assinados (Git — verify-commit); ele não demonstra sozinho quem controlava a chave no momento nem se houve compartilhamento, comprometimento ou uso automatizado.

Reescrita de histórico, referências e objetos inalcançáveis

O grafo visível na branch principal não equivale à totalidade histórica do repositório. Rebase, squash, filtering, amend, force-push e cherry-pick podem produzir novos commits, novos identificadores e relações de ancestralidade diferentes, ainda que parte substancial do conteúdo permaneça igual. A exclusão de uma branch remove a referência, mas os objetos por ela alcançados podem continuar armazenados por algum tempo.

Os reflogs registram atualizações locais de referências e, no caso de HEAD, movimentos como trocas de branch. Eles podem revelar commits que deixaram de ser alcançáveis pelo histórico corrente (Git — reflog). Entretanto, são artefatos locais, sujeitos a expiração e não necessariamente transferidos por clone. O git fsck pode localizar objetos pendentes ou inalcançáveis e, sob determinadas opções, materializá-los em .git/lost-found (Git — fsck).

Essas operações devem ser realizadas em cópia de trabalho, de forma documentada. Atividades de manutenção executadas pelo próprio Git podem consolidar objetos e remover conteúdo inalcançável ou entradas de reflog conforme políticas de expiração; a documentação de git gc descreve esses mecanismos (Git — gc). Abrir um repositório em ferramentas que disparem manutenção, fazer novos checkouts ou executar comandos sem registrar seus efeitos pode alterar precisamente os vestígios procurados.

Preservação distribuída do ambiente de desenvolvimento

Uma aquisição adequada não se limita a baixar o repositório remoto. git clone pode resultar em clone raso, parcial ou esparso, e certas referências podem não ser trazidas para a cópia (Git — clone). Um mirror ou git bundle pode preservar objetos e referências selecionados e é valioso como exportação lógica (Git — bundle), mas não inclui necessariamente arquivos não rastreados, diretório de trabalho, reflogs locais, histórico da IDE, logs de servidor ou vestígios apagados no endpoint.

A preservação deve ser planejada por camada.

Plataforma de hospedagem

Sempre que disponíveis e pertinentes ao escopo, devem ser coletados:

• repositórios, objetos, referências, tags e configurações;
• pull requests ou merge requests, revisões, comentários e aprovações;
• regras de proteção de branches e rulesets;
• membros, equipes, permissões e alterações de acesso;
• chaves de implantação, tokens, aplicativos e credenciais técnicas, preservando-se segredos por meios seguros;
• webhooks e eventos de API;
• registros de auditoria e autenticação;
• execuções de workflows, logs e artefatos;
• pacotes, releases, imagens e metadados de registries.

Em serviços como GitHub, o log de auditoria organizacional permite consulta e, conforme o plano e a configuração, exportação ou integração por API e streaming. A cobertura e a retenção precisam ser verificadas no caso concreto (GitHub — Reviewing the audit log). Registros de servidor são especialmente relevantes para estabelecer quando a plataforma recebeu uma operação e qual conta ou credencial a realizou, mas não determinam necessariamente quando o conteúdo foi escrito no endpoint.

Endpoints de desenvolvimento

A estação do desenvolvedor pode conter elementos ausentes do servidor:

• diretório .git, refs locais, reflogs, stash e objetos inalcançáveis;
• arquivos modificados, não rastreados e ignorados;
• clones alternativos, worktrees, forks e repositórios embutidos;
• histórico local da IDE, backups automáticos e extensões;
• comandos de shell, terminais, scripts e logs de ferramentas;
• arquivos temporários do compilador, linker e empacotador;
• caches de dependências e artefatos;
• arquivos exportados, patches, arquivos compactados e mídias removíveis;
• clientes de sincronização, e-mail e mensageria, se incluídos no escopo autorizado;
• telemetria de EDR, eventos do sistema de arquivos e registros de conexão;
• credenciais configuradas, observadas as restrições legais e de segurança.

Quando houver risco de alteração, a aquisição forense deve preceder a exploração lógica do conteúdo. O método — imagem física, aquisição direcionada, coleta remota ou combinação — depende do sistema, da volatilidade, da proporcionalidade e do objetivo investigativo. O NIST SP 800-86 recomenda integrar técnicas forenses à resposta a incidentes e documentar a coleta, o exame, a análise e o relato (NIST SP 800-86). Em coletas remotas, devem ser registrados o agente empregado, sua versão, privilégios, período, conectividade, arquivos selecionados, falhas e efeitos conhecidos sobre o sistema.

Preservação antes da interpretação

Uma sequência defensável compreende:

1. registrar autoridade, escopo, sistemas, contas, períodos e fusos horários;
2. documentar o estado inicial e reduzir ações automáticas de manutenção quando isso puder ser feito com segurança;
3. adquirir as fontes originais por método adequado;
4. calcular hashes dos conjuntos preservados e manter cópias de trabalho separadas;
5. registrar ferramentas, versões, parâmetros, logs e exceções;
6. somente então executar comandos de reconstrução, recuperação ou comparação.

Essa separação protege tanto a integridade do vestígio quanto a reprodutibilidade da análise.

CI/CD como elo entre fonte e produto

O pipeline de integração e entrega contínuas transforma uma revisão em testes, pacotes, imagens, binários e implantações. Em uma investigação de proveniência, ele pode fornecer o elo que falta entre um commit e o produto distribuído.

Os elementos de maior interesse incluem:

• definição do workflow vigente na data da execução;
• identificador da execução e evento disparador;
• repositório, referência e commit resolvidos;
• identidade que iniciou ou autorizou a tarefa;
• imagem, sistema operacional e versão do runner;
• compiladores, SDKs, ferramentas e parâmetros;
• lockfiles e resolução efetiva de dependências;
• caches restaurados e suas chaves;
• variáveis e metadados de segredos, sem exposição indevida dos valores;
• logs das etapas, resultados de testes e arquivos intermediários;
• hashes, assinaturas e destino dos artefatos;
• ações de publicação, promoção e implantação.

Uma referência textual ao SHA do commit dentro do log é informativa, mas sua força aumenta quando coincide com o checkout observado, o conteúdo efetivamente obtido, o digest do artefato publicado e um registro independente no registry. Também é necessário verificar se o workflow poderia ser alterado pela própria revisão investigada, se ações de terceiros foram fixadas por versão imutável e se runners persistentes permitiam resíduos de execuções anteriores.

Builds reprodutíveis e suas limitações

Quando a construção é reprodutível, o examinador pode recompilar o código em ambiente controlado e comparar o resultado byte a byte com o artefato questionado. Uma correspondência exata constitui vínculo técnico forte entre as entradas e o produto, desde que todas as entradas tenham sido corretamente delimitadas.

Muitos builds, contudo, incorporam timestamps, identificadores aleatórios, caminhos absolutos, ordem variável de arquivos, downloads de rede, dependências mutáveis, dados do host ou diferenças de compilador. Nesse cenário, a divergência de hash entre a recompilação e o artefato original não demonstra automaticamente uso de código diferente. O exame deve localizar as regiões variáveis, normalizar apenas o que for tecnicamente justificável e comparar estruturas internas, símbolos, recursos, mapas de fonte e comportamento.

Atestações, SLSA e in-toto

Atestações de build estruturam declarações sobre o artefato, o ambiente e as entradas utilizadas. O SLSA define proveniência como informação verificável sobre onde, quando e como um artefato foi produzido (SLSA — Build Provenance). O in-toto, por sua vez, procura tornar transparentes as etapas executadas, por quem e em que ordem ao longo da cadeia de software (in-toto).

Em plataformas compatíveis, uma atestação pode incluir o digest do artefato, o repositório, o commit, o workflow, o ambiente e a identidade OIDC que participou da construção. O GitHub documenta que suas atestações podem estabelecer proveniência de build para binários e imagens de contêiner (GitHub — Using artifact attestations).

Para fins periciais, a atestação deve ser tratada como uma declaração verificável, não como verdade presumida. O exame deve validar:

• assinatura e integridade do envelope;
• identidade do emissor e raiz de confiança;
• digest do objeto ao qual a declaração se refere;
• política exigida no momento relevante;
• proteção do workflow e do construtor;
• possibilidade de execução por runners comprometidos ou credenciais indevidas;
• compatibilidade entre a atestação, os logs, o registry e o artefato adquirido.

SLSA e in-toto podem elevar a qualidade dos vestígios produzidos pelo ciclo de desenvolvimento, mas não substituem a análise contextual do controle exercido sobre cada componente da cadeia.

Exame dos artefatos de build

O código relevante pode não estar disponível em forma textual no ambiente investigado. A análise então se desloca para binários, pacotes, imagens de contêiner, firmware, aplicações móveis, bibliotecas e arquivos de implantação.

Dependendo da tecnologia, podem ser examinados:

• cabeçalhos, seções, tabelas de símbolos e informações de depuração;
• nomes de classes, métodos, namespaces e pacotes;
• mapas de fonte e arquivos auxiliares;
• strings, recursos incorporados, consultas, schemas e mensagens de erro;
• assinaturas de compilador, linker, empacotador e nível de otimização;
• bibliotecas estáticas ou dinâmicas e versões de dependências;
• manifestos, camadas e histórico de imagens de contêiner;
• arquivos de configuração e infraestrutura como código;
• SBOMs e documentos de proveniência;
• padrões comportamentais observados em execução controlada.

Um hash idêntico demonstra identidade byte a byte entre os objetos comparados. Não demonstra, sozinho, quem os criou, quem detém direitos sobre eles ou por qual caminho um dos examinados obteve o arquivo. Já hashes diferentes não afastam derivação: recompilação, alteração de metadados, ofuscação, minificação, recompacotamento ou mudança de dependências podem alterar o resultado sem eliminar a relação com a fonte.

SBOMs ajudam a delimitar componentes, versões e relacionamentos declarados. O SPDX é um padrão aberto para comunicar composição, proveniência, licenças e informações relacionadas, reconhecido como ISO/IEC 5962:2021 (SPDX — Overview). Ainda assim, uma SBOM deve ser validada contra o artefato real: pode estar incompleta, desatualizada, ter sido gerada em etapa diversa ou omitir código copiado diretamente.

Comparação de código e avaliação da derivação

A comparação deve combinar métodos adequados à linguagem, à transformação esperada e ao tipo de material disponível. Entre as técnicas possíveis estão:

• igualdade de blobs e arquivos por hash;
• comparação textual normalizada;
• sequências de tokens e n-grams;
• árvores sintáticas abstratas;
• grafos de chamada, fluxo de controle ou dependência;
• estruturas de classes, APIs, modelos de dados e schemas;
• casos de teste, vetores, massas de dados e resultados específicos;
• comentários, mensagens, nomes incomuns e erros de digitação;
• constantes, recursos e defeitos distintivos;
• análise de binários e comparação comportamental.

Cada método possui sensibilidade e limitações. Remover comentários, espaços e nomes de variáveis pode revelar similaridade estrutural, mas também eliminar elementos discriminantes. Métricas baseadas em tokens podem detectar cópia com renomeação, porém gerar coincidências em código idiomático. Grafos podem resistir melhor a mudanças cosméticas, mas são afetados por compilação, otimização e padrões arquiteturais comuns.

O relatório deve explicar o corpus comparado, as versões, os filtros, os limiares, as exclusões e as medidas de controle. Uma porcentagem sem esse contexto é pouco interpretável.

Exclusão de fontes comuns e explicações alternativas

Coincidências ganham valor quando sua origem alternativa é examinada. É necessário identificar:

• bibliotecas de código aberto e respectivas versões;
• templates, SDKs e exemplos de fornecedores;
• código gerado por compiladores, ORMs, ferramentas low-code ou modelos de IA;
• dependências incorporadas ou vendorizadas;
• implementações exigidas por protocolos e padrões;
• algoritmos clássicos e expressões inevitáveis da linguagem;
• bases compartilhadas legitimamente antes da separação entre as partes;
• trabalhos anteriores do colaborador;
• código produzido por terceiros sob licença.

Características raras e combinadas — por exemplo, estrutura peculiar, constante não documentada, caso de teste idêntico e o mesmo defeito observável — podem ter maior poder discriminante do que milhares de linhas convencionais. Mesmo assim, seu peso deve ser avaliado em relação ao universo de comparação e à possibilidade de origem comum.

Correlação de identidades e tempos

O tempo registrado no desenvolvimento de software não é uma única linha cronológica. O mesmo evento aparente pode carregar:

• data de autor do commit;
• data do committer;
• horário do envio ao servidor;
• abertura, aprovação e merge da revisão;
• início e término do pipeline;
• criação e publicação do pacote;
• implantação no ambiente;
• mtime, ctime ou outros metadados do sistema de arquivos;
• horários de logs de autenticação e EDR.

Datas do commit são declaradas no cliente e podem refletir fuso, relógio incorreto, importação ou reescrita. O evento de servidor é geralmente melhor para demonstrar quando aquela plataforma observou a operação, mas não prova quando o conteúdo foi originalmente criado. Metadados do sistema de arquivos também podem ser preservados, redefinidos ou alterados conforme cópia, extração e sistema operacional.

A normalização temporal deve preservar o valor original, o fuso ou offset, a fonte e a conversão empregada. As conclusões mais robustas derivam de sequências apoiadas por múltiplos relógios independentes, não da seleção do timestamp mais conveniente.

Metodologia pericial integrada

1. Delimitação das hipóteses e do universo de comparação

Identificam-se os módulos, versões, produtos, períodos, pessoas, repositórios, licenças e eventos relevantes. Define-se também o conjunto de fontes públicas e compartilhadas que será usado para testar explicações alternativas.

2. Preservação das fontes distribuídas

Coletam-se, de forma coordenada, plataforma, endpoints, pipelines, registries e sistemas de identidade. A ordem considera volatilidade e retenção: logs de auditoria e artefatos efêmeros podem desaparecer antes de backups corporativos estáveis.

3. Inventário e verificação de integridade

Cada item recebe identificador, origem, método de aquisição, período, tamanho e hashes. São documentadas lacunas, falhas de exportação, filtros e diferenças entre o que a interface exibe e o que a API fornece.

4. Reconstrução do grafo de desenvolvimento

Mapeiam-se branches, tags, merges, commits órfãos, reflogs, stashes, forks, reescritas e relações entre repositórios. Objetos idênticos são correlacionados sem presumir que a direção de transferência já esteja demonstrada.

5. Resolução de identidades e normalização temporal

Relacionam-se metadados declarados, contas, credenciais, dispositivos e eventos de autenticação. Todos os tempos são convertidos em uma base comum, mantendo-se o registro original e a incerteza aplicável.

6. Comparação de fonte, build e produto

Executam-se técnicas de comparação previamente definidas. Quando viável, o build é reproduzido em ambiente controlado. Artefatos, símbolos, dependências, SBOMs e atestações são confrontados com os registros do pipeline.

7. Teste das hipóteses alternativas

Buscam-se fontes públicas, componentes licenciados, geração automática, bases preexistentes e evolução independente. Resultados favoráveis e desfavoráveis à hipótese investigada devem receber o mesmo tratamento documental.

8. Avaliação e relato

As conclusões são graduadas conforme a força e a independência dos vestígios. O relatório distingue observação, inferência e limitação, além de fornecer material suficiente para reprodução por outro examinador qualificado.

Exemplo técnico de correlação

Considere a suspeita de que uma biblioteca proprietária de cálculo, desenvolvida por uma empresa, foi incorporada a um produto lançado posteriormente por uma organização formada por antigo prestador de serviços.

No repositório corporativo, a perícia localiza um commit contendo uma combinação incomum de regra de arredondamento, tabela de constantes e caso de teste. Os objetos Git demonstram que aquela árvore integra o histórico preservado. O log do servidor registra o envio do commit à organização em data compatível, por uma conta federada, e um pull request mostra revisão por outros integrantes. Esses elementos apoiam a existência corporativa da versão naquele momento, mas o nome de autor do commit, isoladamente, não atribui a criação à pessoa.

No endpoint atribuído ao prestador, uma aquisição anterior à exploração encontra clone completo do repositório, entrada de reflog para branch posteriormente removida, um stash com adaptação da biblioteca e histórico da IDE compatível com a edição. Registros de autenticação e EDR vinculam uso interativo da estação ao período. Esse conjunto oferece suporte mais forte ao acesso e à manipulação do que a mera presença de um arquivo em pasta compartilhada.

No produto externo, o pacote possui hash diferente do build corporativo. A análise estrutural, contudo, identifica a mesma regra, as constantes e o comportamento anômalo do caso de borda. Símbolos e mapa de fonte residual apontam para organização semelhante de módulos. O pipeline externo, se legitimamente obtido, relaciona o pacote a um commit posterior e registra o compilador e as dependências que explicam parte das diferenças binárias.

Por fim, são pesquisados repositórios públicos, versões anteriores compartilhadas e documentação técnica. A tabela de constantes aparece em uma norma pública, mas a combinação entre tratamento de borda, organização interna e defeito específico não é localizada no corpus de controle. A conclusão adequada descreve o grau de suporte à hipótese de derivação e as fontes correlacionadas; não declara, por linguagem pericial, que ocorreu juridicamente uma violação de propriedade intelectual.

Inferências que exigem cautela

Algumas associações intuitivas excedem o que o vestígio demonstra:

• o autor declarado no commit não é, necessariamente, a pessoa que escreveu ou enviou o código;
• a existência de clone no endpoint demonstra disponibilidade local, não a finalidade do acesso;
• igualdade de hash comprova identidade do objeto, não titularidade jurídica;
• o timestamp mais antigo não estabelece sozinho a primeira criação;
• ausência no repositório remoto não exclui conteúdo em clones, forks, reflogs ou objetos inalcançáveis;
• assinatura válida não elimina a necessidade de verificar controle e confiança da chave;
• índice elevado de similaridade não determina direção de cópia ou origem comum;
• build não reprodutível não afasta, por si, o uso do mesmo código-fonte;
• exclusão de branch não significa remoção imediata dos objetos;
• SBOM ou atestação não deve ser aceita sem confronto com o artefato e a cadeia de confiança.

Essas reservas não enfraquecem a investigação. Ao contrário, tornam explícita a fronteira entre o que foi observado e o que pode ser inferido.

Prontidão forense no desenvolvimento de software

Organizações que produzem ativos de software podem melhorar a qualidade futura da prova sem transformar o ambiente de engenharia em sistema de vigilância excessiva. Medidas proporcionais incluem:

• identidade corporativa federada e contas técnicas individualizadas;
• proteção de branches, revisão obrigatória e restrição de force-push;
• assinatura de commits, tags, pacotes e atestações com política de confiança definida;
• retenção e exportação segura de logs de auditoria;
• inventário de repositórios, forks, registries, runners e serviços de build;
• artefatos imutáveis identificados por digest;
• lockfiles, SBOMs e registros de dependências;
• isolamento e renovação de runners;
• sincronização de tempo e documentação de fusos;
• proteção de endpoints de desenvolvimento e telemetria compatível com as políticas internas;
• procedimentos de admissão, mudança de função e desligamento;
• preservação tempestiva quando surge dever de retenção ou incidente.

O NIST SSDF organiza práticas de desenvolvimento seguro aplicáveis ao ciclo de vida e inclui a preparação da organização, a proteção do software e a resposta a vulnerabilidades (NIST SP 800-218). Embora seu objetivo principal seja segurança de software, controles bem implementados também produzem registros mais consistentes para investigações de proveniência.

Estrutura do relatório técnico

Um relatório de proveniência de código-fonte deve apresentar, de maneira auditável:

1. objeto, questões técnicas e limites do exame;
2. fontes recebidas e cadeia de custódia;
3. métodos de aquisição e hashes;
4. ferramentas, versões, parâmetros e ambiente de análise;
5. modelo dos repositórios e cronologia normalizada;
6. resolução de contas, credenciais e dispositivos;
7. metodologia de comparação e corpus de controle;
8. resultados sobre fonte, pipeline e artefatos;
9. hipóteses alternativas e testes realizados;
10. limitações decorrentes de retenção, lacunas ou mutabilidade;
11. conclusões técnicas graduadas;
12. anexos com tabelas de objetos, eventos e resultados reproduzíveis.

Quando scripts próprios são empregados, seu código, dependências, entradas e saídas devem ser preservados. Resultados estatísticos ou índices de similaridade precisam vir acompanhados de definição e validação. O objetivo é permitir que outro profissional compreenda como cada conclusão deriva dos vestígios, inclusive quando não tenha acesso à interface original da plataforma.

Conclusão

Investigações sobre possível uso indevido de código-fonte exigem muito mais do que confrontar diretórios. O Git registra conteúdos e relações históricas, mas admite identidades declaradas e reescrita de grafo. A plataforma acrescenta eventos de servidor e controles colaborativos. O CI/CD conecta revisões a processos de construção. Artefatos revelam o que foi efetivamente empacotado ou distribuído. Endpoints preservam trabalho local e vestígios que podem nunca ter chegado ao repositório remoto.

A proveniência tecnicamente defensável resulta da correlação dessas camadas. Ela depende de preservação precoce, distinção entre papéis e relógios, validação criptográfica contextual, comparação adequada à transformação sofrida pelo código e exame explícito das origens alternativas. Quando esse método é seguido, a perícia pode explicar com precisão o percurso provável do software, o suporte oferecido por cada evidência e os limites que permanecem — base técnica necessária para decisões corporativas e jurídicas subsequentes.