Resumo

  • Uma atestação do GitHub criptograficamente válida vincula o digest do artefato à proveniência registrada da build; ela não certifica que o artefato é seguro.
  • O controle decisivo pertence ao consumidor, que deve negar o deploy quando repositório, identidade imutável do workflow, commit ou condição de release, ambiente ou limite de confiança do runner estiverem fora da política.
  • A ausência do log público de transparência nas atestações de repositórios privados representa uma diferença de observabilidade, não uma prova de fraqueza.

A assinatura pode passar e o artefato continuar barrado

Uma imagem de contêiner chega à porta de produção. Sua assinatura é válida, o digest confere e a declaração de proveniência está íntegra. Mesmo assim, o controle de admissão recusa a imagem. O repositório registrado pode não ser o esperado; o workflow reutilizável pode estar referenciado por uma tag móvel; o commit pode ficar fora da release aprovada; o ambiente pode ser outro; ou o runner pode ultrapassar o limite de confiança definido pelo consumidor.

A recusa não contradiz a atestação. Ela mostra que a evidência foi submetida a uma regra de admissão.

O GitHub descreve as atestações de artefatos como declarações assinadas que estabelecem a proveniência de uma build. Elas podem identificar o workflow ligado ao artefato, o repositório, a organização, o ambiente, o SHA do commit e o evento disparador. Outros elementos podem vir da identidade OpenID Connect usada para estabelecer a proveniência.

A declaração é produzida depois da etapa de build, com permissões para token de identidade e gravação da atestação. No caso de um binário, o sujeito pode ser o próprio arquivo gerado. Para um contêiner, o nome completo e o digest vinculam a evidência a um conteúdo específico, em vez de depender apenas de uma tag mutável. Com isso, o consumidor consegue confirmar que o conteúdo apresentado corresponde ao conteúdo produzido pela rota declarada.

Essa capacidade tem um limite importante. A atestação não avalia se o código-fonte é benigno, se as dependências são confiáveis ou se as instruções de build eram adequadas. Tampouco prova que o ambiente de execução permaneceu íntegro. Ela transforma a origem em evidência verificável, mas não converte todas as propriedades da cadeia de software em um veredito de segurança.

O próprio GitHub ressalta que gerar uma atestação, sem verificá-la, não traz benefício de segurança. Também afirma que a declaração não garante a segurança do artefato. Cabe ao consumidor definir critérios, examinar o conteúdo e tomar uma decisão de risco. Conferir somente a validade criptográfica deixa de fora a questão mais relevante: a rota assinada era uma rota autorizada?

É a política que dá consequência à prova

O repositório e a organização esperados são filtros iniciais, não uma política completa. Uma mesma organização pode manter um workflow de release centralizado e revisado, além de automações com controles bem diferentes. O fato de ambos conseguirem gerar uma assinatura válida não torna seus resultados igualmente admissíveis.

A identidade imutável do workflow reduz essa ambiguidade. Segundo o GitHub, o SHA completo de um commit é a referência mais segura para um workflow reutilizável externo. Branches avançam e tags podem ser movidas. Uma atestação pode registrar corretamente uma referência cujo conteúdo já não corresponde à versão revisada. Aceitar apenas o nome do workflow deixa parte da definição da build fora do controle.

O commit, o evento, o estado da release e o ambiente estreitam ainda mais o caminho. Uma política de produção pode exigir um commit expressamente aprovado, e não qualquer commit do repositório correto. Pode também aceitar somente artefatos de um ambiente de publicação governado. Essas condições não surgem automaticamente da assinatura; são escolhas do consumidor.

O runner estabelece outra fronteira. O GitHub alerta que runners auto-hospedados não têm garantia de execução em máquinas efêmeras e limpas, podendo sofrer comprometimento persistente por código não confiável. Uma atestação válida, portanto, não prova que determinado runner estava íntegro. A política precisa decidir separadamente quais grupos, condições de isolamento e ambientes de execução merecem confiança.

Quando a evidência vira controle de entrada

A documentação do GitHub apresenta um modelo para Kubernetes com Sigstore Policy Controller, uma raiz de confiança do GitHub e uma política de imagens do cluster. Depois que a aplicação é habilitada nos namespaces escolhidos, o controlador pode verificar as atestações antes de admitir imagens e recusar as que não atendem à política.

A configuração expõe onde o controle realmente está. Instalar o controlador sem configurar a política não impõe nenhuma verificação. A política também precisa ser habilitada nos namespaces relevantes. Padrões de correspondência de imagens e exceções alteram a cobertura. Assim, afirmar que uma organização “usa atestações” não informa quais workloads são efetivamente controlados nem o que eles aceitam.

Há ainda uma diferença de observabilidade entre repositórios públicos e privados. As atestações públicas usam a instância pública do Sigstore e entram em um log de transparência imutável e publicamente legível. Repositórios privados usam a instância Sigstore do GitHub, baseada no mesmo código, mas sem log público e federada apenas com o GitHub Actions. Isso modifica o alcance da inspeção independente; não demonstra, por si só, uma falha de segurança.

As fontes primárias não informam a adoção geral, a frequência de recusas nem taxas de falsa aceitação. Elas também não provam que todos os consumidores aplicam políticas ou que um runner específico não foi comprometido. Esses limites não devem ser preenchidos com suposições.

A conclusão operacional é tratar a verificação como controle de admissão. Antes do deploy, exigir o repositório esperado, a identidade imutável do workflow, o commit ou a condição de release aprovada, o ambiente previsto e um limite aceitável de confiança do runner. Se qualquer item divergir, recusar o artefato e preservar um recibo que identifique a condição incompatível.

Fontes