APRENDER. PRATICAR. EVOLUIR.O objeto aprovado tem de ser identificável
Uma aprovação de release deve poder ser relacionada com aquilo que foi colocado em produção. Um nome de versão pode ser reutilizado; um identificador imutável ajuda a distinguir artefactos, desde que a origem do registo seja fiável. No conjunto sintético, C2 aprova digest-old e D2 executa digest-B. Isto demonstra uma divergência entre os campos fornecidos. Ainda é necessário investigar se houve aprovação posterior válida, erro de extração ou alteração não autorizada. O auditor não transforma automaticamente a divergência em prova de código malicioso. Preserva os registos e pede a ligação entre build, teste, aprovação e deployment.
A ordem temporal faz parte do controlo
Para as mudanças normais deste exercício, a política fictícia exige aprovação independente antes de deployment e correspondência do digest. C3 foi aprovada no minuto 625, mas D3 entrou no minuto 620. O ticket está atualmente aprovado, porém não demonstra cumprimento da condição temporal. Mantém o registo histórico de estados, não apenas a fotografia atual. Todos os minutos desta prática usam a mesma referência UTC; num sistema real seria necessário validar relógios, fusos e granularidade. Uma diferença de cinco minutos não deve ser interpretada com certeza maior do que a qualidade dos timestamps permite.
Independência e identidade efetiva
D5 foi operado e aprovado por ops-e. A política do exercício exige pessoas distintas, pelo que a evidência fornecida não satisfaz essa condição. Em ambiente real, nomes de contas diferentes também não provam pessoas independentes: duas contas podem pertencer à mesma pessoa ou uma conta pode ser partilhada. Liga identidades técnicas a responsáveis e avalia delegações. Inversamente, um nome de função comum não prova que foi a mesma pessoa sem dados de atribuição. A conclusão deve identificar o que está demonstrado e o que precisa de corroboração, sem inventar identidade individual a partir de um rótulo.
Emergência é outro conjunto de critérios
D4 está classificado como emergência e não tem aprovação prévia no conjunto. A consulta deve separá-lo para avaliação pela política de emergência. Não o marques automaticamente como conforme nem como falha da via normal. Pede motivo, autoridade que permitiu a ação, medidas de redução de impacto, registo da execução e revisão posterior exigida. A classificação escrita depois do facto também precisa de suporte. Uma via de emergência útil permite agir sob pressão com responsabilização; não funciona como palavra que elimina todos os requisitos. O auditor aplica os critérios realmente aprovados pela organização, sem inventar um prazo universal de revisão.
Exercício de rastreabilidade e resumo
Depois de carregar os dados da primeira aula, executa a consulta desta aula. Só D1 satisfaz conjuntamente os três critérios sintéticos da via normal. D2 tem digest diferente, D3 só tem aprovação posterior, D5 não apresenta aprovação independente e D6 não tem mudança correspondente. D4 fica numa avaliação separada. Escreve uma observação para D2 e um pedido de evidência para D4. Evita uma taxa global que misture falhas demonstradas, dados em falta e uma via ainda não avaliada. Resume o objetivo: relacionar objeto, momento e autoridade, preservando as exceções que exigem julgamento profissional.
SELECT d.id
FROM deployments d JOIN changes c ON c.id=d.change_id
WHERE c.class='standard' AND d.digest=c.approved_digest
AND EXISTS (SELECT 1 FROM approvals a
WHERE a.change_id=d.change_id
AND a.approved_minute<=d.deployed_minute
AND a.approver<>d.operator)
ORDER BY d.id;D1 passa os critérios didáticos; D4 requer análise de emergência. Um único resultado booleano para ambos esconderia critérios diferentes.
Armadilhas comuns
Ticket aprovado hoje como aprovação prévia; tag mutável como identidade suficiente; contas distintas como pessoas distintas; emergência como dispensa geral.
Tópicos relacionados: CI/CD e evidência · Mudanças de emergência
Uma release auditável mantém a ligação entre o que foi autorizado e o que correu, com critérios próprios para cada via de mudança.
Referência: Secure Software Development Framework Version 1.1 · CISA outline effective August 1, 2024