The approved object must be identifiable
Release approval should be traceable to what entered production. A version name can be reused; an immutable identifier helps distinguish artifacts, provided record provenance is reliable. In the synthetic dataset, C2 approves digest-old and D2 executes digest-B. This establishes a mismatch between supplied fields. Investigation must still determine whether there was valid subsequent approval, extraction error or an unauthorized change. The auditor does not automatically turn the mismatch into proof of malicious code. Preserve records and request the chain linking build, testing, approval and deployment.
Time ordering is part of the control
For normal changes in this exercise, fictional policy requires independent approval before deployment and a matching digest. C3 was approved at minute 625, but D3 entered production at minute 620. The ticket is now approved but does not demonstrate compliance with the timing condition. Retain state history rather than only the current snapshot. Every minute in this practice uses the same UTC reference; a real system would require clock, timezone and granularity validation. A five-minute difference should not be interpreted with greater certainty than timestamp quality allows.
Independence and effective identity
D5 was operated and approved by ops-e. Exercise policy requires different people, so supplied evidence does not satisfy that condition. In a real environment, different account names do not prove independent people either: both accounts may belong to one person or an account may be shared. Map technical identities to owners and evaluate delegation. Conversely, a common role name does not establish that the same person acted without attribution data. The conclusion should identify what is demonstrated and what needs corroboration without inventing individual identity from a label.
Emergency uses a different set of criteria
D4 is classified as emergency and has no prior approval in the dataset. The query should separate it for assessment under emergency policy. Do not automatically mark it compliant or a failure of the normal path. Request the reason, authority permitting the action, impact-reduction measures, execution record and required subsequent review. Classification added after the event also needs support. A useful emergency path permits action under pressure with accountability; it is not a word that removes every requirement. The auditor applies the organization’s actual approved criteria without inventing a universal review deadline.
Traceability exercise and summary
After loading the first lesson’s data, execute this lesson’s query. Only D1 jointly satisfies the three synthetic normal-path criteria. D2 has a different digest, D3 only has later approval, D5 lacks independent approval and D6 has no matching change. D4 remains a separate assessment. Write an observation for D2 and an evidence request for D4. Avoid an overall rate mixing demonstrated failures, missing data and a path not yet assessed. Summarize the objective: connect object, time and authority while retaining exceptions requiring professional judgment.
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.idD1 passes the teaching criteria; D4 needs emergency-path analysis. A single Boolean result for both would hide different criteria.
Common pitfalls
A ticket approved today as prior approval; mutable tags as sufficient identity; separate accounts as separate people; emergency as a blanket exemption.
Related topics: CI/CD and evidence · Emergency changes
An auditable release preserves the connection between what was authorized and what ran, with criteria appropriate to each change path.
Reference: Secure Software Development Framework Version 1.1 · CISA outline effective August 1, 2024