Auditar proveniência e gates de entrega

Começar pelo objeto da decisão

Uma release é uma decisão sobre um objeto e um contexto concretos. No exemplo fictício, o requisito pede org/ledger no commit C9, testes obrigatórios concluídos com sucesso e evidência de origem que os passos do job não possam alterar. A tabela de trabalho começa com digest do artefacto recebido, origem e commit aprovados, build identificado e critérios de aceitação.

Em seguida, liga cada evidência ao mesmo objeto. Um teste de C8 não passa a ser teste de C9 porque o comando é igual; uma assinatura do ficheiro errado não responde à pergunta. Se faltar uma ligação, indica evidência insuficiente para o critério, sem inventar que o artefacto está vulnerável ou que alguém falsificou o registo.

Assinatura, identidade autorizada e expectativas

Um verificador pode confirmar a assinatura e o digest e continuar a aceitar um produtor não aprovado. Para payroll-core, o exercício permite apenas org/payroll. Uma declaração válida de org/demo identifica outra origem; pertencer à mesma organização administrativa não resolve o critério.

Separa os resultados de autenticidade, correspondência ao artefacto e comparação com expectativas controladas. Identifica também quem pode alterar essas expectativas e com que aprovação. Caso contrário, quem produz um artefacto pode mudar simultaneamente a regra que o aceita.

O relatório deve mostrar o requisito e o valor observado, em vez de resumir todas estas condições num único estado «assinatura OK». A confiança atribuída à plataforma continua a precisar de fundamento.

Inventário não equivale a análise de vulnerabilidades

Uma SBOM assinada da aplicação pode identificar as bibliotecas do arquivo e deixar de fora a imagem base usada na release. A assinatura não acrescenta componentes ausentes. Antes de aceitar a conclusão sobre a imagem executável, confirma o objeto inventariado e inclui os componentes relevantes da base.

Depois liga a análise de vulnerabilidades a esse inventário, às versões e ao momento da análise. Mesmo um inventário adequado não é por si só o resultado de um scanner. Numa revisão de projeto, pede uma demonstração com uma imagem sintética que contenha aplicação e base distintas.

O aluno deve conseguir explicar que evidência identifica componentes, que evidência avalia exposição conhecida e que limites impedem uma garantia de ausência absoluta de vulnerabilidades.

Fixar uma dependência sem esquecer as seguintes

O workflow referencia uma action por commit completo, mas o código dessa action descarrega helper/latest.sh. A referência exterior está fixa; os bytes recebidos pela dependência seguinte podem mudar. Desenha a cadeia de resolução até aos componentes executados e procura a identidade imutável que corresponde à versão revista.

Um certificado TLS válido autentica um canal, mas não demonstra que a resposta desse dia é a ferramenta aprovada. Num exercício seguro, usa dois ficheiros locais com o mesmo nome lógico e conteúdos diferentes. Calcula os digests e mostra que repetir o identificador do chamador não deteta a alteração do ficheiro chamado.

Define onde a implementação deve verificar a ligação antes de executar a ferramenta.

Escolher uma dependência dentro da janela

A identidade revista de uma ferramenta é apenas um dos critérios. Num plano de migração, relaciona a versão com o formato consumido, os testes do artefacto concreto e a janela disponível. Se H1 produz F1 ainda necessário e H2 produz F2 só aceite mais tarde, fixar H2 não resolve compatibilidade.

Soma as etapas sequenciais: 35 minutos de construção e 20 de testes cabem em 90; juntar 80 minutos de adaptação já não cabe. Reutilizar o resultado de outro commit não é o mesmo que reutilizar uma ferramenta cujo digest foi verificado. Estes tempos e formatos são premissas de treino.

Origem dos campos e parâmetros externos

Proteger a chave de assinatura não impede um job de fornecer declarações falsas se o serviço assinar JSON recebido sem validar os campos. O requisito fictício exige que origem e comando sejam observados pelo control plane; testa quem realmente determina esses valores.

Em separado, um verificador que compara mode=release mas ignora disable_checks=true deixa uma influência externa sem decisão de aceitação. Enumerar parâmetros e avaliar os seus valores são operações distintas. Define valores admitidos e tratamento explícito de parâmetros desconhecidos.

Ao usar SLSA 1.2, lê as exceções de campos e o âmbito de cada nível: não transfiras automaticamente requisitos de externalParameters para resolvedDependencies nem interpretes uma assinatura como garantia de todos os factos declarados.

Migrar expectativas sem abrir uma lacuna

A mesma etiqueta release pode ter semânticas diferentes em versões de buildType. Define as expectativas por versão antes de emitir artefactos da versão nova. Preservar uma versão anterior autorizada não obriga a ignorar parâmetros novos; rejeitar todo campo adicional também pode quebrar entradas já analisadas como seguras.

Distingue tipo de valor, comportamento que o valor ativa e tratamento de parâmetros desconhecidos. Testa os dois percursos legítimos, a opção que omite controlos e o campo não reconhecido. Um parâmetro de escalonamento só pode receber tratamento menos restritivo depois de se analisar o seu efeito; a assinatura, por si só, não faz essa análise.

Caches e discos podem ligar jobs separados

No pipeline fictício, um job de pull request externo escreve numa cache que a release consome. Assinar a saída depois não remove a influência dessa entrada. Com autorização, substitui apenas dados inofensivos numa fixture isolada e observa se a saída da release muda; compara com uma cache independente.

Também distingue o registo de um runner da vida útil do disco montado. Remover um registo após um job não apaga ficheiros reutilizados pelo seguinte. A conclusão de isolamento deve acompanhar os recursos persistentes.

Um resultado reproduzível com a mesma cache pode apenas reproduzir a mesma influência. O laboratório desta aula usa bytes e regras locais: não constitui um ensaio de isolamento de GitHub, contentores ou uma plataforma cloud.

Encontrar caminhos que contornam a revisão

O workflow habitual usa o ambiente prod, que exige revisão antes de disponibilizar os seus secrets. Um workflow de manutenção não referencia esse ambiente e usa uma credencial guardada ao nível do repositório. Para avaliar «todas as entregas têm revisão», segue a segunda credencial até à operação permitida e procura um gate obrigatório equivalente.

Mais amostras do workflow habitual não cobrem automaticamente manutenção. Se a operação alternativa for necessária, o responsável pode desenhar uma aprovação apropriada para esse caminho; a auditoria avalia a correspondência ao requisito e a eficácia demonstrada.

Regista também caminhos de emergência e decisões autorizadas sobre exceções. O nome idêntico de dois secrets não prova que tenham o mesmo âmbito ou proteção.

Manter uma via autorizada de recuperação

Uma credencial guardada fora de um gate pode manter uma via alternativa mesmo depois de um workflow passar a referenciar prod. Quando a migração total não cabe numa janela de recuperação, avalia uma via limitada que aplique a aprovação já emitida ao digest e destino realmente usados.

Custódia fora do job, expiração e consumo único tratam propriedades diferentes. O plano de testes inclui operações legítimas e pedidos com digest, destino, validade ou reutilização incorretos. A auditoria comunica o alcance e os limites; a autoridade responsável continua a decidir.

O broker e a janela são construções do exercício, não funcionalidades universais de GitHub ou IAM. No exercício, a credencial partilhada mantém validade até ser revogada; apagar o segredo do repositório não invalida cópias obtidas antes. Os 13 minutos incluem revogação, nova credencial no broker e testes.

Confirma a recusa da credencial antiga e a continuidade do fluxo normal, que tem uma credencial própria.

Manter os dados fora da interpretação de código

Um webhook de um ticket de alteração fornece maintenance_window, uma etiqueta editável pelo operador que o job insere no texto de uma shell para selecionar a janela de manutenção. Existem duas condições: o valor deve permanecer como dado e identificar uma janela aprovada.

Passá-lo como argumento ou variável para um parser, sem eval, trata a primeira; compará-lo com a lista controlada de janelas trata a segunda. Aspas e o uso posterior do valor continuam a importar. Prepara uma etiqueta permitida, uma desconhecida e entradas inofensivas com espaços e aspas.

Confirma a interpretação como dados e a decisão de autorização. Um input seguro pode ainda representar uma janela não autorizada. O teste usa dados sintéticos e não efetua deployments.

Ausência de execução e erro não são sucesso

O scanner fictício produz CLEAN, FINDINGS ou ERROR. A regra interna exige CLEAN; uma implementação que bloqueia apenas FINDINGS deixa ERROR passar, embora a análise não tenha terminado. O teste discriminante inclui os três estados e mantém motivos distintos para bloqueio.

Outro gate calcula SUCCESS a partir dos jobs executados e ignora SKIPPED. Se um teste obrigatório ficou SKIPPED por condição de branch, o estado agregado não demonstra o seu cumprimento. Exige presença, execução concluída e resultado aceitável do teste obrigatório para o artefacto em decisão.

Um ficheiro de teste no repositório mostra que existe um procedimento; não mostra que foi aplicado à release. Estes estados pertencem ao orquestrador fictício e não são uma descrição universal de todos os produtos CI.

Reavaliar resultados quando muda o critério

Neste segundo exercício, a política decide pela severidade dos findings num relatório completo, segundo um limiar definido. Uma mudança de regra de decisão não torna automaticamente inúteis todas as observações anteriores. Se dados completos continuam ligados ao mesmo artefacto, o detector e a escala não mudaram e a política permite a sua reutilização, pode aplicar-se um novo limiar com registo explícito.

Um finding 8 que passava num limiar 9 deixa de passar num limiar 7; máximo 6 pode continuar a passar. Se o detector adicionou verificações, um CLEAN anterior não cobre essa nova população, e ERROR não a preenche. Separa constatação confirmada, análise incompleta e decisão de promoção.

Planeia os ensaios escassos para obter a evidência em falta, incluindo o tempo da decisão posterior. As escalas, validade e regras de reutilização são premissas locais, não critérios prescritos por SLSA.

Caso guiado: reunir condições numa nova build

B1 usa C9 e tem testes PASS, mas o assinador aceita os campos de origem escritos pelo job sem os comparar com a execução, e a cache é partilhada com pull requests externos. B2 observa origem fora do job e tem testes PASS, mas produziu C8. Nenhum conjunto demonstra todos os critérios para C9.

Como existe tempo e capacidade para uma nova execução B2 com C9 e cache isolada, recomenda essa execução e a recolha de novos resultados ligados ao novo artefacto. Não transportes os testes de C8 nem combines a proveniência B2 com os testes B1.

Depois apresenta à autoridade de release quais critérios foram observados e quais limitações permanecem. A decisão final continua com essa autoridade. A recomendação de auditoria propõe obter evidência adequada; não aprova antecipadamente o resultado futuro.

Usar um nível de assurance dentro do seu âmbito

Um contrato do exercício exige inventário completo de tudo o que foi obtido durante a build. O fornecedor apresenta SLSA Build L3. A especificação consultada mantém a completude de resolvedDependencies como best effort, mesmo nesse nível; a exigência contratual precisa de evidência adicional.

Isso não torna inúteis as propriedades efetivamente demonstradas. Cria uma matriz com requisito do contrato, propriedade suportada pelo referencial, evidência examinada e trabalho restante. Distingue ainda isolamento de hermeticidade: o nível não deve ser convertido numa afirmação automática de ausência de rede.

No relatório, usa linguagem proporcional, por exemplo «a evidência analisada suporta a origem declarada neste âmbito; a completude do inventário contratual ainda não foi estabelecida».

Prática local: seguir bytes, inputs e execuções

Depois de extrair o ZIP, lê README.md e executa os comandos abaixo na pasta extraída. Cada execução cria uma pasta nova e conserva a anterior. Prevê primeiro quais dos 15 cenários cumprem o contrato fictício.

Inspeciona observed-build.json, actual-jobs.json, submitted-jobs.json e gate-result.json de cada cenário. C8 passa os dois exemplos funcionais mas falha a revisão autorizada; em stale-C8-tests não há novos testes; em wrong-input-same-total obtém-se 1000 usando dados diferentes dos exigidos.

Na cache partilhada, uma ferramenta inofensiva altera realmente o marcador do artefacto, embora os totais continuem corretos. Explica cada retenção pelo critério e pelos bytes observados. SHA-256 compara ficheiros locais; os JSON não são assinados e os processos usam o mesmo utilizador.

O exercício não demonstra isolamento de um fornecedor, identidade protegida ou prontidão de produção.

Armadilhas comuns

Assinatura válida como produtor autorizado; SBOM como scanner; commit fixo como todas as dependências fixas; secrets do ambiente como proteção de todos os workflows; SUCCESS como prova de execução obrigatória; nível SLSA como cumprimento automático do contrato.