APRENDER. PRATICAR. EVOLUIR.Converter intenções em condições testáveis
O requisito download seguro não define sozinho os controlos. Explicita ativos, identidades, operações e condições de proteção, incluindo quem não pode obter um relatório. Se só testares um aprovador autorizado, não demonstras que outro papel é impedido de aprovar. Esconder um botão também não prova negação no endpoint. Relaciona o requisito com desenho, teste positivo e teste negativo. A escolha de uma biblioteca conhecida pode ajudar a implementar uma propriedade, mas não substitui a definição dessa propriedade. Na passagem para operação, conserva os critérios para que uma alteração posterior possa ser avaliada contra o mesmo resultado.
Aprovar uma identidade de artefacto
Uma etiqueta de release pode mudar de destino. Se a aprovação refere digest A e a etiqueta passa a B, verifica a divergência antes de instalar. Não atualizes o registo de aprovação apenas para o fazer coincidir com o ficheiro encontrado. No exercício, a publicação exige digest aprovado, builder permitido e resultado de segurança aceite. Duas condições satisfeitas não compensam a terceira pendente. Este gate é uma regra fictícia, não uma reprodução de todos os requisitos SLSA. O objetivo pedagógico é tornar explícita a ligação entre decisão, evidência e objeto efetivamente publicado.
Verificar origem sem prometer ausência de falhas
A provenance pode ligar um artefacto ao processo que o produziu, desde que seja verificada segundo expectativas do consumidor. Uma assinatura válida de B2 não torna B2 confiável quando a política só permite B1. O digest deve corresponder ao artefacto, e os restantes atributos exigidos pelo processo têm de ser avaliados. Mesmo uma construção reproduzível não prova ausência de vulnerabilidades: código defeituoso também pode produzir sempre os mesmos bytes. Mantém separadas integridade, origem, confiança no processo e segurança funcional do código. O modelo local desta aula compara campos sintéticos; não valida assinaturas reais nem certifica um nível SLSA.
Proteger o ambiente e as cópias de informação
Um runner partilhado pode conservar ficheiros alterados por um job anterior. Se esse job tem menor confiança, o build de release não deve herdar as suas alterações como entradas autorizadas. Avalia isolamento, estado persistente, permissões e proveniência das entradas. Nos diagnósticos, mascarar tokens na interface não garante que os artefactos exportados estejam limpos. Investiga todas as cópias pertinentes e a validade dos segredos expostos. Também revê estados iniciais: uma conta administrativa partilhada ativa por defeito pode introduzir acesso desnecessário. O processo de arranque deve permitir operação autorizada sem manter essa exposição por conveniência.
Conhecer dependências e corrigir a origem
Uma SBOM é útil para localizar componentes, mas não demonstra que todos estão livres de falhas. Liga nome, versão, módulo e aplicação instalada. Se três aplicações têm a versão afetada, duas têm uma versão fora do aviso e três são desconhecidas, apresenta os três grupos. Inventário incompleto não significa ausência de exposição. Quando várias aplicações repetem uma falha copiada de um template, corrigir só cada aplicação deixa a origem pronta para novos projetos. Corrige o template e adiciona um teste que detete a regressão. No rollback, confirma se a versão anterior reintroduz a falha que motivou a atualização.
Prática guiada: decidir o gate e explicar os limites
Aplica as condições abaixo a cada candidato. A passa o gate fictício; B falha a identidade do artefacto, C falha a origem permitida e D ainda não tem resultado aceite. Explica a falha específica sem declarar os outros controlos inválidos. Depois prepara a mensagem de release com artefacto, fonte de evidência e decisão em falta. Para o referencial, a página NIST consultada distingue SSDF 1.1 final de 1.2 em draft; mantém esse estado nas afirmações. Esta aula resume três hábitos: verificar o objeto realmente instalado, conservar a incerteza no inventário e corrigir a origem dos defeitos repetidos.
Synthetic release gate; not cryptographic signature verification
Required: digest D7; builder B1; security result accepted
A: D7 / B1 / accepted -> pass this gate
B: D8 / B1 / accepted -> digest mismatch
C: D7 / B2 / accepted -> builder not allowed
D: D7 / B1 / pending -> result missing
Passing this gate does not prove vulnerability-free software.Uma release de reporting tem digest correto mas foi produzida por um builder não aprovado. A equipa trata a confiança na origem antes de publicar, apesar dos testes funcionais verdes.
Armadilhas comuns
Confundir assinatura com confiança universal, SBOM com ausência de falhas, etiqueta com digest, logs mascarados com cópias limpas e draft com versão final.
Tópicos relacionados: Arquitetura, criptografia e falhas comuns · Redes, canais e fronteiras de acesso · Software seguro e cadeia de fornecimento
A cadeia de fornecimento exige identidade, origem e contexto verificáveis, além de testes que avaliem as propriedades exigidas ao software.
Referência: Secure Software Development Framework Version 1.1 · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29