Proof of Existence vs. Sigstore: você precisa dos dois?

Sigstore e Proof of Existence (prova de existência) não são, na verdade, concorrentes. O Sigstore responde quem assinou este artefato de software, e o evento de assinatura está em um registro público? O Label 309 responde estes bytes exatos existiam até um determinado momento público, de forma comprovável sem confiar em nenhum serviço específico? Para a maioria das equipes de software, a configuração mais forte usa os dois: assine e registre os lançamentos com o Sigstore e depois ancore as evidências do lançamento com o Label 309.

O Sigstore é um ecossistema de assinatura e transparência de software. O Label 309 ancora hashes de conteúdo, manifestos, arquivos selados ou uma raiz Merkle na Cardano, para que qualquer pessoa possa verificar depois que aqueles dados exatos existiam até um horário de bloco específico — usando apenas a transação e um explorador público, sem nenhum servidor do emissor envolvido.

O que é o Sigstore?

O Sigstore é um ecossistema de código aberto para assinar artefatos da cadeia de suprimento de software e registrar os eventos de assinatura em um log público.

Seu fluxo de trabalho comum sem chaves usa uma identidade OpenID Connect (OIDC), um certificado de curta duração emitido pelo Fulcio, uma assinatura criada no cliente e uma entrada no log de transparência Rekor. O objetivo é facilitar a assinatura de artefatos mantendo um registro público auditável de quem assinou o quê.

O Sigstore é uma boa escolha para:

• imagens de contêiner;
• binários e pacotes;
• listas de materiais de software (SBOMs);
• atestados de proveniência;
• fluxos de CI/CD e de assinatura de lançamentos;
• verificar que um artefato foi assinado por uma identidade esperada.

Foi construído para a confiança na cadeia de suprimento de software.

O que é o Label 309?

O Label 309 é um padrão aberto e neutro quanto ao fornecedor para registros de Proof of Existence na Cardano. A proposta foi submetida ao processo de CIP da Cardano e está em análise pelos editores de CIP; o identificador na cadeia é o rótulo de metadados 309.

Um registro Label 309 pode comprometer um ou mais hashes de conteúdo, uma raiz Merkle sobre vários arquivos, assinaturas opcionais no nível do registro, cargas seladas endereçadas a chaves de destinatários e URIs de armazenamento endereçado por conteúdo. A prova central é verificável de forma independente a partir da transação Cardano e dos bytes que estão sendo conferidos — sem conta, sem login e sem depender de nenhum provedor único.

Para equipes de software, isso o torna útil para ancorar as evidências de um lançamento:

• digests de artefatos;
• pacotes do Sigstore;
• proveniência SLSA e declarações in-toto;
• SBOMs;
• manifestos de lançamento;
• logs de build e resultados de testes;
• evidências de incidentes.

É uma camada de comprometimento pública e com carimbo de tempo.

Qual é a diferença, na prática?

O Sigstore responde a perguntas de identidade e assinatura para software. O Label 309 responde a perguntas de existência e tempo para quaisquer bytes.

O Sigstore pode ajudar a responder:

• Esta imagem de contêiner foi assinada?
• Qual identidade OIDC estava vinculada ao certificado de assinatura?
• O evento de assinatura foi registrado no log de transparência?
• A assinatura do artefato pode ser verificada?
• Isto corresponde à minha política de assinantes confiáveis?

O Label 309 pode ajudar a responder:

• Este digest de artefato existia até este horário de bloco da Cardano?
• Este SBOM fazia parte das evidências comprometidas do lançamento?
• Este manifesto de lançamento existia antes de um incidente?
• Uma identidade conhecida do projeto assinou o registro (opcionalmente)?
• Um destinatário consegue decifrar um pacote de evidências selado depois?

Esses dois conjuntos de perguntas se encaixam, em vez de se sobrepor.

O Rekor já não faz isso?

Se você usa o Sigstore, use o Rekor — é a ferramenta certa para o que ele faz.

O Rekor é um log de transparência para assinaturas e metadados de software, projetado para tornar os eventos de assinatura descobríveis e auditáveis. A documentação do Sigstore o descreve como um ledger somente de acréscimo e resistente a adulteração, que auditores podem monitorar em busca de consistência — sendo o objetivo de design que qualquer tentativa de alterar ou remover uma entrada seja detectável, em vez de silenciosa.

O Label 309 não substitui o Rekor. Ele fornece um tipo diferente de âncora:

• um carimbo de tempo enraizado no consenso da Cardano, em vez de um log operado por um serviço;
• um esquema de registro definido sob o rótulo de metadados 309;
• preservação selada opcional de evidências sensíveis;
• entrega a destinatários específicos;
• agrupamento Merkle para grandes conjuntos de evidências;
• verificação que não depende de nenhum provedor específico continuar online.

Se um lançamento já tem evidências do Sigstore, ancore essas evidências. Não as descarte.

Como seria um fluxo de trabalho combinado?

Uma pipeline de CI/CD pode montar uma pasta com as evidências do lançamento e então comprometê-la.

Essa pasta pode conter o manifesto de lançamento, digests de artefatos, assinaturas ou pacotes do Cosign, referências de entradas do Rekor, proveniência SLSA, atestados in-toto, SBOMs, logs de build, relatórios de testes e manifestos de implantação.

A pipeline calcula o hash de cada arquivo, constrói uma árvore Merkle e publica um único registro Label 309 carregando a raiz Merkle. Como a raiz é um único valor de 32 bytes, uma transação pode representar um conjunto de evidências arbitrariamente grande; uma prova de inclusão mostra depois que qualquer arquivo específico fazia parte daquela raiz. O registro também pode carregar uma assinatura opcional de uma identidade de projeto ou empresa. Para a mecânica de dobrar muitos arquivos em uma única raiz, veja um registro para milhares de arquivos; para o padrão de pipeline de ponta a ponta, veja ancorando evidências de build de CI/CD.

Depois, um auditor verifica duas coisas independentes:

• Sigstore — quem assinou o quê, sob qual identidade e contexto do log de transparência;
• Label 309 — qual conjunto de evidências existia até um momento público da Cardano.

O Label 309 verifica a assinatura do software?

Não. O Label 309 não sabe se uma assinatura Cosign é válida, se uma identidade OIDC é confiável, se uma política é satisfeita ou se um build atende às expectativas SLSA.

O que ele pode provar é que o arquivo de assinatura, o pacote, o atestado, o SBOM ou o manifesto de lançamento existia até um momento público. As ferramentas da cadeia de suprimento de software continuam verificando seus próprios formatos sob suas próprias regras.

Essa separação é saudável. Uma Proof of Existence não deve fingir ser um motor de políticas de assinatura de software.

O Sigstore preserva todo o seu conjunto de evidências?

Não por si só. O Sigstore foca em assinatura e transparência para artefatos de software. Um processo de lançamento real muitas vezes também precisa preservar logs de build, SBOMs, relatórios de testes, manifestos de implantação, linhas do tempo de incidentes e pacotes de evidências privados.

O Label 309 pode comprometer esses materiais como um único conjunto. Se alguns materiais forem sensíveis, eles podem permanecer privados e ser comprometidos por meio de uma raiz Merkle sem publicar o conteúdo — ou ser selados, de modo que o texto cifrado fique em armazenamento endereçado por conteúdo e apenas um detentor da chave possa decifrá-lo. Um registro selado mantém o texto claro legível apenas para os destinatários pretendidos; ele não garante, por si só, o anonimato, e um destinatário ainda pode vazar o texto claro depois de decifrar.

Isso torna o Label 309 útil para auditoria, resposta a incidentes, compras, revisões de segurança de clientes e evidências de lançamento de longo prazo.

Quando você deve usar o Sigstore?

Use o Sigstore quando precisar de assinatura de artefatos de software e verificação respaldada por identidade. É a escolha certa para assinar imagens de contêiner, binários e pacotes; fluxos públicos de lançamento de código aberto; assinatura sem chaves com identidades OIDC; transparência na cadeia de suprimento; políticas de verificação baseadas em assinantes esperados; e integração com ferramentas de distribuição existentes.

O Sigstore é um padrão forte para a assinatura de software moderna.

Quando você deve usar o Label 309?

Use o Label 309 quando precisar de um comprometimento público e com carimbo de tempo em torno das evidências — ancorando manifestos de lançamento, provando que um SBOM existia antes da divulgação de uma vulnerabilidade, comprometendo uma raiz Merkle sobre um conjunto de evidências de lançamento, preservando materiais de incidente selados, provando um conjunto de artefatos entregue a um cliente ou mantendo uma prova que não depende de um provedor de CI ou de um painel de registro de artefatos continuar online.

O Label 309 não substitui a assinatura. Ele é uma âncora de tempo e um formato de comprometimento de evidências. A CLI cardanowall de código aberto foi construída exatamente para esse tipo de automação: agnóstica quanto ao gateway e centrada em sementes brutas, de modo que se encaixa em uma pipeline sem um site no meio. Veja usando a CLI em automação para o fluxo completo.

O que nenhum dos dois sistemas prova?

Nenhum dos dois sistemas prova que o software é seguro.

Um artefato assinado ainda pode conter uma vulnerabilidade. Um SBOM com carimbo de tempo pode estar incompleto. Um log de build pode documentar uma pipeline que estava mal configurada. Um lançamento pode ser bem documentado e ainda assim inseguro.

O Sigstore e o Label 309 ajudam a provar integridade, identidade, transparência, tempo e continuidade das evidências. A segurança em si ainda depende de revisão do código-fonte, isolamento do build, gestão de dependências, testes, resposta a vulnerabilidades e controles operacionais. Para os limites gerais do que uma prova pode e não pode estabelecer, veja o que uma prova não prova.

A versão curta

Use o Sigstore para assinar software e tornar os eventos de assinatura transparentes. Use o Label 309 para ancorar as evidências do lançamento — manifestos, logs e atestados — a um momento público da Cardano que nenhum fornecedor pode mover discretamente. Juntos, eles tornam a história do software muito mais fácil de verificar depois.

Leitura adicional

• Ancorando evidências de build de CI/CD — o padrão de pipeline completo para calcular hashes, agrupar e publicar evidências de build.
• Um registro para milhares de arquivos — como uma única raiz Merkle se compromete com um conjunto de evidências arbitrariamente grande.
• Use a CLI em automação — conduzindo publicação e verificação a partir de uma pipeline com a CLI cardanowall.
• O que uma prova não prova — os limites honestos de uma Proof of Existence.
• Sigstore e sua documentação — assinatura sem chaves, certificados Fulcio e o log de transparência Rekor.