Auditabilidade de software contratado: como exigir o que você não sabe pedir

Um sistema contratado pode ser excelente tecnicamente e impossível de auditar contratualmente. Acontece com frequência: a entrega funciona, mas quando o jurídico, o controle interno ou o tribunal de contas pedem evidências, descobre-se que o contrato não obriga ninguém a produzi-las.

O resultado: o órgão ou a empresa têm o software, têm o problema e não têm prova.

O que "auditável" realmente significa

Auditável não é "alguém pode olhar o código se quiser". É a propriedade de produzir, em qualquer momento, evidência verificável sobre quatro coisas:

1. O que o sistema faz (especificação executável, testes, fluxos documentados).
2. Como ele faz (arquitetura, dependências, decisões de design).
3. Quem mexeu nele (autoria, revisões, aprovações, deploys).
4. Quando as coisas aconteceram (logs imutáveis, trilhas de mudança, snapshots de versão).

Se qualquer um desses quatro está incompleto, há cegueira institucional. E cegueira é onde fraude e erro grosseiro nascem.

Cláusulas mínimas em qualquer contrato de software

Estas são as exigências que recomendamos como ponto de partida — em pregões, dispensas ou contratos privados de relevância:

Repositório e código-fonte

• Código-fonte hospedado em repositório acessível ao contratante (não apenas entregue em zip ao final).
• Histórico de commits íntegro — sem rebases destrutivos no branch principal.
• Direito de auditoria a qualquer momento da vigência, não só no encerramento.

Documentação operacional

• Runbook descrevendo procedimentos para incidentes comuns.
• Diagrama de arquitetura atualizado a cada release maior.
• Lista de dependências externas (bibliotecas, APIs, serviços) com versão e finalidade.

Trilhas e logs

• Logs de aplicação estruturados (JSON), retenção mínima documentada, exportáveis em formato aberto.
• Trilha de acessos privilegiados ao banco e a dados sensíveis, imutável.
• Trilha de deploys — quem subiu, qual versão, qual mudança, quando.

Saída e portabilidade

• Exportação completa de dados em formato aberto a qualquer momento, sem custo adicional.
• Documentação de schema atualizada — para que a próxima contratada (ou equipe interna) não comece do zero.
• Período de transição assistida ao fim do contrato — não menos de 90 dias.

Os padrões que dão lastro

Quando a outra parte resiste, citar padrões internacionais reduz a discussão:

• NIST SSDF (Secure Software Development Framework, SP 800-218) — define práticas mínimas de desenvolvimento seguro que podem virar exigência contratual.
• ISO/IEC 27001 + 27017 — gestão de segurança da informação, com extensão específica para serviços em nuvem.
• CycloneDX ou SPDX — formatos abertos de SBOM (Bill of Materials) para inventariar dependências.
• OpenSSF Scorecard — métricas objetivas sobre maturidade de práticas em projetos de software.

Pedir aderência a esses padrões em contrato é mais defensável do que escrever uma lista própria — porque vincula a uma referência externa reconhecida, não ao gosto do contratante.

O teste da véspera de auditoria

Use este exercício mental: se amanhã o controle interno (ou o TCU, ou o conselho fiscal) pedir tudo abaixo, em quanto tempo a contratada entrega?

• Lista completa de bibliotecas de terceiros usadas, com versões e licenças
• Histórico de quem teve acesso a dados pessoais nos últimos 90 dias
• Diff de tudo que mudou em produção no último trimestre
• Cópia executável da versão exata que estava no ar em uma data específica
• Resultados dos últimos scans de vulnerabilidade

Se a resposta para qualquer item é "vamos ver", o contrato falhou em sua função fiscalizatória — independentemente de o software funcionar bem.

Como evitar que isso seja problema da próxima gestão

Auditabilidade não se resolve no fim, em ata de encerramento. Resolve-se nas três primeiras semanas de qualquer contrato — definindo padrões, criando os repositórios, exigindo o primeiro relatório. Depois disso, vira hábito; antes disso, é vontade.

Trabalhamos com órgãos e empresas que precisam reescrever cláusulas de contratos vigentes (renegociação) ou desenhar o próximo edital com auditabilidade embutida desde a especificação. Em ambos os casos, é uma conversa pragmática: o que cabe pedir, o que não cabe, o que custa quanto.

Fale com a gente em /contato com o tipo de contrato que está em pauta — devolvemos uma minuta de cláusulas mínimas adaptada ao seu caso e o plano de transição, se for aplicável.

Para quem está planejando o orçamento de TI da próxima gestão: vale ler também Open source no setor público, porque muitas dessas cláusulas só fazem sentido quando o código pode efetivamente ser inspecionado.