Como ancorar as evidências de build do CI/CD a um carimbo de tempo público?

Sim — um pipeline de CI/CD pode publicar a prova do que construiu e quando. O padrão é calcular o hash das saídas que importam (artefatos, SBOMs, logs, manifestos de lançamento), dobrar esses hashes em uma única raiz Merkle e publicar um só registro Label 309 para o build, o lançamento ou a janela de tempo. Depois, qualquer pessoa pode provar que um artefato ou manifesto específico fez parte daquele lote comprometido, e que o lote existia em um tempo de bloco público ou antes dele.

Isso não substitui SLSA, Sigstore, GitHub Artifact Attestations ou in-toto. Ele os complementa com algo que nenhum deles oferece diretamente: uma âncora de tempo independente, pública e agnóstica quanto ao emissor, que nenhum fornecedor controla.

O que um pipeline de CI/CD deve realmente provar?

Comece pelas evidências que você talvez precise apresentar daqui a um ano.

Uma prova de CI/CD pode se comprometer com:

• artefatos de lançamento;
• digests de imagens de contêiner;
• arquivos de SBOM (software bill of materials);
• atestados de proveniência SLSA;
• metadados de link in-toto;
• logs de build;
• relatórios de teste;
• manifestos de implantação;
• instantâneos de changelog;
• referências de commit de origem;
• lockfiles de dependências;
• checksums assinados;
• notas de lançamento.

Não calcule o hash de tudo só porque existe. Calcule o hash dos artefatos que importam para segurança, auditoria, resposta a incidentes, confiança do cliente ou integridade do lançamento.

Uma boa prova responde a uma pergunta futura concreta: "Este artefato ou manifesto exato fez parte das evidências de lançamento que comprometemos naquele momento?"

Como funciona o padrão de agrupamento Merkle?

Para um único artefato, uma prova de hash basta.

Para um lançamento, você costuma ter muitos artefatos, e publicar cada um como sua própria transação é um desperdício. Uma raiz Merkle resolve isso. Você calcula o hash de cada item de evidência em uma folha, dobra as folhas ordenadas em uma única raiz de 32 bytes e publica apenas a raiz — um registro na cadeia cobrindo o lançamento inteiro.

O pipeline:

1. Constrói os artefatos.
2. Gera ou coleta SBOMs, atestados, logs e manifestos.
3. Calcula o hash de cada item de evidência em uma folha.
4. Monta uma lista de folhas ordenada.
5. Constrói a árvore Merkle e calcula a raiz.
6. Publica um registro Label 309 carregando a raiz.
7. Armazena a lista de folhas e as provas de inclusão junto às evidências do lançamento.

Depois, um verificador pega um arquivo ou digest, confere sua prova de inclusão e confirma que o item pertence à raiz no registro Label 309. A prova de inclusão cresce apenas com o logaritmo do tamanho do lote, então uma raiz sobre milhares de folhas ainda se verifica em milissegundos — totalmente offline, sem gateway e sem rede. Para a mecânica completa, veja um registro para milhares de arquivos.

Por que não depender apenas dos atestados existentes?

Use os atestados existentes — e depois os ancore.

A proveniência SLSA descreve onde, quando e como um artefato de software foi produzido. As GitHub Artifact Attestations estabelecem a proveniência de build para artefatos como binários e imagens de contêiner. O Sigstore registra metadados assinados da cadeia de suprimentos em um log de transparência público e somente de acréscimo chamado Rekor. O in-toto é um framework para verificar que cada etapa de uma cadeia de suprimentos foi executada conforme o planejado, pela parte certa, sobre as entradas certas.

Cada um deles resolve um problema real. O Label 309 resolve um problema diferente: publicar uma prova ancorada em Cardano, verificável de forma independente, de que um conjunto específico de evidências existia até um tempo público específico. Um pipeline robusto não escolhe entre "atestados ou Proof of Existence". Ele usa ambos:

• atestados SLSA ou do GitHub para a proveniência de build;
• Sigstore para fluxos de assinatura e log de transparência;
• in-toto para verificação de etapas da cadeia de suprimentos;
• Label 309 como âncora de tempo pública sobre todo o conjunto de evidências.

O que o Label 309 acrescenta?

Ele acrescenta um compromisso público e durável na Cardano.

Esse compromisso pode cobrir um único manifesto de lançamento ou uma raiz Merkle sobre muitos itens de evidência. Pode ser assinado pela identidade de um projeto ou empresa. E pode ser verificado usando apenas os metadados da transação e um explorador público de Cardano — sem conta, sem login e sem depender de que o painel do provedor de CI original continue online.

Essa independência importa mais quando uma equipe precisa provar que as evidências existiam antes de algum evento posterior:

• a divulgação de uma vulnerabilidade;
• um incidente de segurança;
• uma revisão de segurança feita por um cliente;
• uma auditoria de aquisição;
• um prazo de conformidade;
• uma disputa de lançamento;
• uma investigação da cadeia de suprimentos.

A prova dá à linha do tempo uma âncora que ninguém envolvido pode mover sem que se note.

O que um auditor verificaria?

Um auditor deve conseguir seguir a cadeia de um único artefato de volta até o registro na cadeia:

1. Pegar o artefato ou SBOM em análise.
2. Calcular seu hash.
3. Conferir a prova de inclusão contra a raiz Merkle do lançamento.
4. Confirmar que a raiz aparece em um registro Label 309.
5. Localizar a transação Cardano e ler seu tempo de bloco.
6. Verificar qualquer assinatura do registro.
7. Conferir a proveniência ou o atestado circundante segundo suas próprias regras.

Isso separa de forma limpa duas perguntas. A prova Label 309 responde: esta evidência foi comprometida até este tempo público? A camada SLSA, Sigstore, GitHub ou in-toto responde: o que esta evidência diz sobre como o artefato foi construído, assinado ou distribuído? Nenhuma das duas tenta fazer o trabalho da outra.

O que deve constar no manifesto de lançamento?

Um manifesto de lançamento deve ser previsível e completo, sem surpresas. Ele pode incluir:

• nome e versão do lançamento;
• URL do repositório;
• commit de origem;
• identificador do workflow de build;
• ID da invocação de build;
• nomes e digests dos artefatos;
• digests de imagens de contêiner;
• digests dos arquivos de SBOM;
• digests dos arquivos de atestado;
• digests dos relatórios de teste;
• digest do log de build;
• o carimbo de tempo relatado pelo sistema de CI;
• a referência da transação Label 309, adicionada após a publicação.

O próprio manifesto pode ter seu hash calculado e ser incluído como folha. Ele também funciona como o índice legível por humanos que explica cada outra folha do lote. Mantenha o formato estável: uma prova é mais fácil de verificar quando a estrutura das evidências é previsível de um lançamento para o seguinte.

O pipeline deve assinar o registro?

Em geral, sim.

Uma raiz Merkle prova que uma lista foi comprometida. Uma assinatura mostra, além disso, que um projeto, uma empresa, um sistema de lançamento ou uma identidade aprovada atestou esse compromisso. No Label 309, essa é uma assinatura opcional no nível do registro — a autoria nunca é necessária para que a afirmação de existência se verifique, mas está disponível quando você quer responsabilização.

Gerencie a chave de assinatura de forma deliberada. Não espalhe sementes de identidade de longa duração por runners de CI arbitrários. Dependendo do seu modelo de ameaça, use uma identidade de lançamento dedicada, um serviço de assinatura controlado, um fluxo apoiado em hardware ou um runner auto-hospedado com controles de acesso rígidos. A CLI cardanowall de código aberto foi feita exatamente para isso — agnóstica quanto ao gateway e centrada em sementes brutas, de modo que se encaixa na automação sem um site no caminho. Veja usando a CLI na automação para o fluxo de ponta a ponta.

Uma assinatura acrescenta responsabilização. Ela não torna seguro, por si só, um pipeline de build frágil.

Onde a lista de folhas deve ficar?

Guarde-a com as evidências do lançamento.

A lista de folhas e as provas de inclusão são o que permite provar itens individuais depois. Se você publicar apenas a raiz e em seguida perder a lista de folhas, ainda poderá provar que alguma lista existiu — mas talvez não consiga mais provar que um artefato específico estava nela.

As boas opções de armazenamento dependem do fluxo de trabalho:

• anexe-a ao arquivo do lançamento;
• guarde-a em um repositório de artefatos;
• mantenha-a em um bucket interno de evidências;
• sele-a como conteúdo cifrado para evidências confidenciais;
• publique-a por meio de armazenamento endereçado por conteúdo quando for seguro torná-la pública.

A raiz é a âncora. A lista de folhas é o mapa.

Com que frequência um pipeline deve publicar?

Combine a cadência das provas com a cadência dos lançamentos. Escolhas comuns:

• uma prova por lançamento;
• uma prova por build;
• uma prova por implantação;
• uma prova por dia para logs contínuos;
• uma prova por evento relevante para segurança.

Publicar com pouca frequência enfraquece a linha do tempo; publicar com frequência demais aumenta o custo e o ruído operacional. O agrupamento Merkle deixa você escolher uma cadência que corresponda à pergunta de negócio. Se um cliente perguntar "o que exatamente foi entregue na versão 2.3.1?", uma prova por lançamento é mais que suficiente. Se um regulador ou auditor perguntar se o monitoramento foi contínuo, compromissos diários ou de hora em hora servem melhor.

Publicar custa dinheiro, porque o gateway paga taxas reais de transação Cardano mais armazenamento — então a cadência é um verdadeiro trade-off entre custo e evidência, não um botão gratuito.

O que uma prova de CI/CD não prova?

Ela não prova que o build foi seguro.

Uma Proof of Existence pode mostrar que um artefato, SBOM, log ou manifesto existia até um tempo público; que o item foi incluído em um lote comprometido; e que uma chave assinou o registro. É só isso que ela certifica.

Ela não prova que o código-fonte era seguro. Não prova que o runner não foi comprometido. Não prova que as dependências estavam livres de vulnerabilidades. Não prova que o SBOM está completo. E não prova que um atestado é confiável, a menos que as próprias regras de verificação desse atestado passem. É exatamente por isso que o Label 309 fica ao lado das ferramentas de segurança da cadeia de suprimentos, em vez de substituí-las — veja o que uma prova não prova para os limites gerais.

Qual é uma boa primeira implementação?

Comece com uma prova de lançamento. Para cada lançamento:

1. Gere seus artefatos normais.
2. Gere ou colete SBOMs e atestados.
3. Crie um manifesto de lançamento.
4. Calcule o hash de cada arquivo de evidência em uma folha.
5. Construa a raiz Merkle.
6. Publique um registro Label 309 assinado.
7. Salve a referência da transação nas notas de lançamento.
8. Armazene o manifesto, a lista de folhas e as provas de inclusão com o lançamento.

Isso lhe dá uma trilha de evidências prática sem reprojetar seu sistema de build logo no primeiro dia. A partir daí, expanda para logs diários, manifestos de implantação ou automação de maior volume.

A versão curta

Uma prova de CI/CD é um compromisso com carimbo de tempo sobre as evidências de lançamento.

Calcule o hash dos artefatos, SBOMs, logs, atestados e manifestos que importam. Agrupe-os em uma única raiz Merkle. Publique essa raiz em um registro Label 309. Assine o registro se quiser que a identidade de um projeto ou empresa ateste por ele.

Mantenha SLSA, Sigstore, GitHub Artifact Attestations e in-toto para a proveniência e os metadados da cadeia de suprimentos. Acrescente o Label 309 como a âncora de tempo pública e independente que amarra todo o conjunto de evidências a um momento que nenhum fornecedor pode mover.

Leitura adicional

• Um registro para milhares de arquivos — como o agrupamento Merkle ancora um conjunto inteiro sob uma única raiz.
• Use a CLI na automação — conduzindo a publicação e a verificação a partir de um pipeline.
• Proof of Existence vs Sigstore — como as duas camadas diferem e onde se encaixam juntas.
• Proveniência de build SLSA — a especificação de proveniência do SLSA.
• Sigstore e o log de transparência Rekor — assinatura sem chaves com um log público e somente de acréscimo.
• GitHub Artifact Attestations — proveniência de build para artefatos construídos no GitHub.
• in-toto — o framework de integridade da cadeia de suprimentos de software.