Um artefato pode sair de um repositório legítimo e ainda assim ser alterado durante a compilação, no armazenamento ou na distribuição. O risco afeta equipes que entregam aplicações, imagens de contêiner e pacotes internos; a ação prioritária é exigir proveniência verificável antes de promover qualquer artefato para produção.
Esse controle muda a pergunta operacional. Em vez de perguntar apenas se o código passou pelos testes, a equipe passa a verificar qual revisão foi usada, qual processo construiu o pacote, em qual plataforma a execução ocorreu e se o resultado corresponde às expectativas definidas para aquele projeto.
O que a proveniência resolve
Proveniência é o registro dos elementos que explicam a construção de um artefato. Ela pode associar o pacote ao código-fonte, aos parâmetros de compilação, às dependências e ao ambiente de execução do processo de build. O objetivo não é provar que o software é perfeito. É permitir que o consumidor detecte uma divergência entre o artefato recebido e o processo que deveria tê-lo produzido.
O NIST Secure Software Development Framework recomenda práticas integráveis ao ciclo de desenvolvimento para reduzir vulnerabilidades, limitar o impacto de falhas não detectadas e tratar as causas que levam a recorrências. Na prática, a proveniência é uma peça de evidência que conecta desenvolvimento, segurança e operação.
Sem esse registro, uma equipe pode saber que um pacote foi publicado, mas não consegue responder com precisão se ele veio do commit aprovado, se uma dependência foi trocada, se o pipeline executou uma etapa inesperada ou se uma credencial comprometida influenciou o resultado.
Não confunda inventário com garantia
Um inventário de dependências continua sendo necessário, mas ele responde a uma pergunta diferente: quais componentes estão presentes? Ferramentas de análise de composição de software ajudam a identificar bibliotecas e vulnerabilidades conhecidas. Elas não demonstram, sozinhas, que o binário instalado foi construído a partir do código autorizado.
Essa distinção evita um erro comum: bloquear versões vulneráveis no manifesto e considerar a cadeia protegida. Um invasor pode atacar a conta de publicação, o executor do pipeline, o armazenamento de artefatos ou a etapa de empacotamento sem alterar a lista de dependências. O controle precisa acompanhar a transformação do código em software distribuível.
A documentação do OWASP Dependency-Check descreve uma ferramenta que examina dependências e relaciona componentes a identificadores de plataformas e registros de vulnerabilidades. É uma defesa útil para o conteúdo do pacote, mas deve ser combinada com controles de integridade e origem.
Escolha uma barreira progressiva
A especificação SLSA organiza garantias crescentes para a cadeia de build. O primeiro degrau exige que exista informação sobre como o pacote foi construído. A etapa seguinte acrescenta proveniência assinada e gerada por uma plataforma de build hospedada. O nível mais elevado descrito nessa versão exige uma plataforma endurecida, com isolamento entre execuções e proteção do material secreto usado para assinar a evidência.
A equipe não precisa esperar uma arquitetura perfeita para começar. O primeiro objetivo deve ser produzir um documento de proveniência para cada artefato de release e armazená-lo junto ao pacote, com retenção compatível com a vida útil do software. Depois, o verificador deve validar assinatura, identidade do workflow, revisão do código e entradas esperadas antes da promoção.
O critério de falha também precisa ser explícito. Proveniência ausente, assinatura inválida, origem não reconhecida, mudança inesperada no workflow ou divergência entre o digest registrado e o artefato baixado devem interromper a promoção. A exceção manual, se existir, precisa gerar registro, responsável, justificativa e prazo de revisão.
Procedimento para a equipe
| Momento | Verificação | Decisão |
|---|---|---|
| Pull request | Workflow protegido, revisão independente e dependências inventariadas | Impedir alterações de pipeline sem revisão de segurança |
| Build | Revisão, entradas, executor e parâmetros registrados | Gerar proveniência automaticamente |
| Assinatura | Identidade do sistema de build e chave fora das etapas controladas pelo usuário | Rejeitar evidência sem autenticação confiável |
| Registro | Artefato, digest e proveniência preservados juntos | Manter trilha para investigação e rollback |
| Deploy | Proveniência compatível com a política do serviço | Promover apenas após verificação |
Comece pelos artefatos que alcançam ambientes externos ou processam dados sensíveis. Para cada um, defina a origem esperada: repositório, branch ou tag autorizada, identidade do workflow, plataforma de build e registro de pacotes. Evite regras vagas como “build confiável”. Uma política útil precisa dizer quais campos são obrigatórios e qual divergência bloqueia a entrega.
P1: feche os atalhos
Na prioridade P1, proteja as identidades que podem alterar o código, o pipeline, o registro de pacotes ou a política de implantação. Separe as permissões de escrever código das permissões de publicar releases. Remova tokens persistentes quando a plataforma oferecer credenciais temporárias e impeça que um workflow de solicitação externa acesse segredos de produção.
Também preserve o arquivo de definição do pipeline como código protegido. Uma revisão da aplicação não compensa uma alteração maliciosa na configuração que executa a compilação. O artigo sobre controles contínuos em infraestrutura como código ajuda a aplicar a mesma lógica de revisão, identidade e comparação de estado ao ambiente que sustenta a entrega.
Por fim, exija digest imutável na promoção. Tags podem ser reutilizadas ou apontar para conteúdos diferentes; o digest permite verificar o conteúdo exato que foi testado. O registro de implantação deve guardar esse identificador, a proveniência correspondente e a decisão que autorizou a mudança.
P2: detecte desvios
Na prioridade P2, monitore alterações no workflow, criação de novos executores, mudanças na chave de assinatura, publicação fora do horário ou do processo habitual e artefatos que não possuem evidência correspondente. O alerta deve chegar ao proprietário do serviço e à equipe de segurança com contexto suficiente para decidir entre bloquear, investigar ou aceitar o risco.
Logs de execução precisam ser tratados como evidência, não como decoração do pipeline. Registre quem iniciou a execução, qual identidade foi usada, quais entradas foram consumidas, onde o resultado foi armazenado e quando a promoção ocorreu. O guia de logs de segurança para detecção mostra como relacionar eventos de aplicação, infraestrutura e identidade para investigar uma cadeia de ações.
Faça um exercício controlado: altere uma entrada esperada em um ambiente não produtivo e confirme que o verificador detecta a divergência. Depois, simule a ausência da proveniência e uma assinatura inválida. O resultado que importa é o bloqueio automático, a geração do alerta e a capacidade de reconstruir a decisão sem depender da memória do operador.
Decisão de implantação
Equipes pequenas podem iniciar com um único repositório crítico, uma plataforma de build confiável, armazenamento protegido e uma política simples de promoção. Equipes maiores devem padronizar o formato da evidência e oferecer um verificador reutilizável, para que cada produto não implemente uma interpretação diferente.
A proveniência não substitui revisão de código, testes, análise de dependências, proteção de segredos ou monitoramento. Ela costura esses controles em uma pergunta que o ambiente de produção consegue responder: este artefato foi produzido pelo processo que aprovamos? Se a resposta não puder ser demonstrada, a decisão defensiva correta é mantê-lo fora da produção até que a evidência seja recuperada ou o risco seja formalmente aceito.