APRENDER. PRATICAR. EVOLUIR.1. Identificar exatamente o artefacto que será usado
Uma equipa fictícia recebe um pacote chamado release-final.zip e um relatório que afirma que foi assinado. O nome não identifica de forma imutável os bytes que a operação vai executar. Calcula o digest do artefacto recebido e compara-o com o objeto referido pela evidência assinada. Se o ficheiro mudar depois da verificação, a decisão anterior não cobre os bytes novos. Uma tag de imagem ou um nome de ficheiro pode apontar para conteúdo diferente ao longo do tempo; associa a decisão ao digest e ao contexto de uso. No laboratório, alterar um único artefacto mantendo a declaração assinada produz rejeição por divergência. Não é necessário que a assinatura esteja inválida: pode ser uma assinatura válida de outro objeto. Regista essa distinção para orientar o diagnóstico.
2. Separar assinatura válida de signatário autorizado
O laboratório gera dois pares Ed25519 independentes. Ambos conseguem produzir assinaturas matematicamente válidas, mas a política aceita apenas a chave configurada como confiável. O identificador apresentado no envelope serve para procurar essa chave; não permite ao emissor substituir a chave pública de confiança pela sua própria. Depois da verificação, confirma também a relação entre signatário e builder permitido. Uma equipa que pode assinar para desenvolvimento não recebe automaticamente autorização para produção. Mantém a configuração de confiança sob controlo de mudança, com owners e critérios para adicionar, retirar ou limitar identidades. Uma lista vazia deve causar rejeição, não confiança implícita em qualquer chave recebida. O exemplo usa chaves locais e não verifica certificados, revogação, identidades federadas ou logs de transparência.
3. Verificar origem e parâmetros esperados
Uma assinatura de confiança pode acompanhar um build produzido a partir do repositório errado, de um commit antigo ou com parâmetros inesperados. Define expectativas independentes da declaração que estás a verificar: builder, origem canónica, revisão selecionada, tipo de build e parâmetros admitidos. No exercício, debug=true e um parâmetro adicional skipScan são rejeitados mesmo quando a assinatura é válida. Ignorar campos desconhecidos pode permitir comportamento que o consumidor nunca avaliou. A orientação SLSA relaciona a verificação de proveniência com raízes de confiança e expectativas; o código local usa um formato didático próprio e não é um verificador SLSA ou DSSE. Não lhe atribuas um nível SLSA, nem assumes que o laboratório demonstrou isolamento do builder ou completude das dependências. Esses aspetos exigem evidência da plataforma real.
4. Integrar rejeição e exceções no processo operacional
Durante uma janela de mudança, o verificador rejeita o artefacto por divergência de repositório. Não resolvas o alerta alterando a política para aceitar o valor acabado de chegar. Confirma o pedido de release, a origem esperada e a cadeia de entrega. Pode existir uma alteração legítima ainda não aprovada, um erro de distribuição ou uma intrusão. Mantém o artefacto fora da execução enquanto se aplica a decisão prevista. Se houver uma via de exceção, exige âmbito, duração, responsável e risco explícitos, sem a transformar numa autorização permanente. Preserva digests, resultados e versões da política, evitando copiar segredos para tickets. Um rollback também precisa de um artefacto identificado e aceitável; “era o que funcionava ontem” não substitui avaliação de comprometimento, vulnerabilidades ou compatibilidade com o estado atual dos dados.
5. Interpretar sucesso sem prometer ausência de risco
Quando assinatura, digest e expectativas passam, o resultado suporta apenas essas verificações. Não demonstra que o programa está livre de vulnerabilidades, que o signatário é incapaz de agir mal ou que o artefacto satisfaz todos os requisitos funcionais. A resposta a uma chave comprometida pode exigir retirar confiança para novas decisões, identificar artefactos e consumidores afetados, preservar evidência e reconstruir a partir de uma origem avaliada. Rodar a chave de assinatura não apaga assinaturas antigas nem limpa artefactos já distribuídos. No exercício, os testes negativos mostram por que motivos diferentes um pacote pode ser rejeitado, sem executar o pacote. Usa esses resultados para preparar critérios, observabilidade e ensaios no pipeline real. Documenta o que continua fora do âmbito: build confiável, análise de conteúdo, distribuição e decisão de release.
Uma chave não autorizada produz uma assinatura válida, mas a política rejeita-a; outro pacote falha por digest mesmo com assinatura válida.
Armadilhas comuns
Assinatura como prova de software seguro; chave recebida como raiz de confiança; política adaptada ao pacote rejeitado; rotação como limpeza retroativa.
Tópicos relacionados: Dados autenticados e ciclo de chaves
Verifica bytes, signatário e expectativas; trata segurança do conteúdo e autorização de release como decisões adicionais.
Referência: SLSA artifact and provenance verification · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17