Resumo

  • A RFC 9943 permite provar que um serviço de transparência registrou uma declaração assinada sob determinada política e emitiu um recibo com provas verificáveis. Isso é uma evidência de registro, não uma autorização para pôr o artefato em produção.
  • A escolha de emissores confiáveis, regras locais, responsável pela aprovação e caminho de reversão permanece com a organização que pode interromper o dano e prestar contas por ele.

O registro não é uma autorização disfarçada

É fácil tratar a frase “há um recibo de transparência” como se encerrasse a análise de uma dependência. A RFC 9943, publicada pela IETF em junho de 2026 como documento Standards Track, propõe algo mais limitado: uma arquitetura para tornar transparentes declarações assinadas sobre artefatos de cadeias de suprimentos digitais. Ela não cria uma autoridade que aprova releases.

Um emissor pode assinar uma declaração sobre um pacote, imagem ou firmware. A declaração pode ser uma SBOM, uma recomendação, uma informação de fim de vida, um aviso de segurança ou outro conteúdo serializável. Um Transparency Service, o TS, pode registrá-la. O registro aplica a Registration Policy daquele serviço, acrescenta a declaração a uma Verifiable Data Structure e produz um Receipt. O recibo pode permitir que terceiros confirmem propriedades da estrutura, entre elas a inclusão da declaração.

Esse resultado é relevante. Um histórico verificável e append-only torna mais difícil apagar ou alterar uma afirmação sem deixar vestígios. Pode dar ao auditor uma maneira de confrontar declarações de um mesmo emissor ou verificar a consistência de uma sequência. Mas a prova de inclusão não testa a segurança completa do produto, não decide a compatibilidade de um ambiente, não aceita uma obrigação contratual, não substitui um proprietário de risco e não aciona um rollback. O TS torna uma afirmação examinável; não assume o prejuízo de quem a utiliza mal.

Quatro eventos, sem transferência automática de mandato

O primeiro evento é a assinatura do emissor. Uma assinatura válida vincula conteúdo e metadados a uma chave. Não demonstra por si só que esse emissor é a fonte que a organização pretendia aceitar, que ele tinha mandato para fazer aquela afirmação ou que a afirmação é verdadeira.

O segundo é o registro pelo TS. Na RFC 9943, Registration é a submissão da declaração, a aplicação da política de registro, a inclusão na estrutura verificável e a produção do recibo. A política é uma pré-condição baseada no cabeçalho não opaco e nos metadados do envelope. Ela pode ser rigorosa, restrita ou orientada a um setor. Assim, o registro informa quais verificações aquele serviço fez sob aquela política; não anuncia que todo controle de segurança, aquisição ou operação de cada parte interessada foi satisfeito.

O terceiro evento é a verificação pela relying party. A RFC exige que ela confie na chave ou certificado e na identidade associada de ao menos um emissor do recibo. Ela pode aceitar um único recibo e, depois da verificação, aplicar políticas de validação arbitrárias. Portanto, nenhum recibo contém uma regra universal de aceitação. Alguém precisa escolher quais chaves, serviços, emissores, formatos de prova e limites de atualidade contam no caso concreto.

O quarto evento é a decisão operacional. A pessoa responsável por entrega pode permitir uma versão; a área de segurança pode segurá-la; compras pode aceitá-la para um contrato delimitado; operações pode manter uma versão em produção e rejeitar a próxima. São decisões com autoridade, impacto e remédios diferentes. Uma estrutura criptograficamente válida não as toma em nome dessas pessoas.

Separar esses fatos evita uma falsa cadeia de causalidade. Uma declaração pode estar registrada e o cliente pode não confiar naquele emissor. O recibo pode verificar corretamente e uma regra local ainda bloquear o deploy por causa de exposição nova, licença, compatibilidade ou exceção prestes a expirar. Uma emergência pode usar uma exceção temporária. Isso não diminui a necessidade de evidência; torna indispensável registrar quem concedeu a exceção, até quando ela vale e como será revisada.

Política e registro têm relógios próprios

A RFC 9943 admite que o operador de um TS atualize sua Registration Policy ou suas âncoras de confiança. Ela também exige que o TS disponibilize material suficiente para que auditores reproduzam as verificações definidas pela política no instante do registro. A pergunta madura, então, não é somente “a assinatura do recibo é válida?”. É: qual serviço, qual política, qual chave, qual declaração e qual data produziram este resultado?

Isso não congela a política. Chaves precisam ser trocadas, critérios podem amadurecer, perfis podem mudar. A fronteira é outra: a regra atual não pode reescrever silenciosamente o sentido de um registro anterior, e um recibo antigo não pode ser apresentado como se fosse a política atual de liberação da organização.

A ordem do log também não preenche todas as lacunas temporais. Uma VDS pode preservar a sequência de declarações registradas, mas a RFC adverte que a relying party não pode supor que essa ordem é a ordem de emissão, salvo se a política a anunciar. A posição no registro não demonstra que um aviso veio antes de uma correção, que um gestor leu uma evidência antes de decidir, ou que decisão e registro ocorreram no mesmo intervalo. Esses vínculos precisam de seus próprios horários e responsáveis.

Também não há garantia de exatidão. A RFC prevê que emissores podem fazer declarações falsas, deliberadamente ou por engano; uma declaração pode ser substituída, e emissores distintos podem publicar declarações conflitantes sobre o mesmo artefato. A transparência torna o histórico observável e dá elementos para escolher em quem confiar. Ela não nomeia um árbitro universal da verdade.

O item ausente costuma ser a decisão

Muitas equipes já guardam o hash do artefato, uma atestação, o recibo e o nome de uma política. O ponto decisivo — por que esta versão foi liberada — acaba em mensagem, botão de console ou exceção emergencial sem trilha. Depois de uma falha, é possível provar que algo entrou no registro, mas não explicar quem deixou o software ultrapassar o controle.

Um recibo de decisão de liberação, separado do SCITT, pode fechar essa lacuna. Para cada autorização, retenção, recusa ou exceção material, ele deveria ligar a versão imutável do artefato; declaração e emissor; TS; versão e horário da política de registro; resultado da verificação do recibo e da última rechecagem; política local ou exceção aplicada; autoridade decisora; resultado; gatilho de expiração ou revisão; e rota de correção, reversão ou contestação.

Não é uma obrigação criada pela RFC 9943. Justamente por isso, não finge que o padrão da IETF seja uma comissão de releases corporativos. Detalhes de teste, dados de clientes e informação explorável podem permanecer protegidos. Um revisor autorizado, porém, deve conseguir reconstruir a ponte entre a evidência e a decisão que ela influenciou.

Automação não elimina essa ponte. Uma pipeline pode verificar um recibo e aplicar uma regra escolhida antes. O registro precisa indicar qual versão da regra rodou, quem a aprovou, quais entradas avaliou e que resultado obteve. “O log permitiu” encobre a decisão anterior de alguém ou de alguma instituição de transformar aquela regra em automação.

Padrão de prova não é governo do risco

A RFC deixa fora de seu escopo a gestão e o armazenamento de declarações, bem como a descoberta e a notificação de mudanças entre participantes. Essa reserva é saudável. Um fabricante, um hospital, uma entidade pública e um mantenedor voluntário podem verificar a mesma prova sem alegar que têm o mesmo mandato de risco.

O problema aparece quando uma propriedade técnica é usada para lavar uma decisão institucional. Compras diz que a diligência acabou porque uma declaração foi registrada. A equipe de entrega diz que inclusão equivale à aprovação de risco. Operações diz que a assinatura do emissor mantém um componente aceitável depois de uma descoberta nova. Em todos esses casos, uma verdade limitada recebe o peso de uma escolha que ninguém documentou.

O caminho mais confiável é verificar a prova pelo que ela demonstra, preservar a política e o tempo que dão sentido a ela, e registrar quem decidiu usá-la. Assim, uma falha criptográfica e uma falha de governança continuam investigáveis como falhas diferentes.

Fontes

  1. RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains
  2. IETF Datatracker: RFC 9943
  3. RFC 9942: CBOR Object Signing and Encryption (COSE) Receipts
  4. RFC 9162: Certificate Transparency Version 2.0
  5. RFC 9052: CBOR Object Signing and Encryption (COSE): Structures and Process