Record the information needed to reproduce the deployment
The review should connect the build, deployment and runtime. A missing record at one stage makes it harder to explain whether the running workload is the one that was approved.
- Build: source revision, builder, image digest and dependencies.
- Deployment: approver, configuration and change history.
- Identity: credential or federation, permitted resources and token lifetime.
- Runtime: process privileges, writable paths, network access and secrets.
- Operations: logs, health checks, updates and rollback owner.
Test the restrictions without disrupting production
Use a representative, controlled nonproduction environment to check required access and prohibited access. For credential rotation, confirm that the application receives the replacement and that the obsolete credential fails. Keep secrets out of logs, screenshots and the resulting evidence.
To check an admission gate, submit a deliberately nonconforming specification in a controlled assessment environment. Confirm rejection for the intended reason. If an emergency path is authorized, its use needs to be attributable and reviewed; it should not become an undocumented way around the gate.
Record the differences that still need checking
The test namespace or cluster may use different identity, network or policy settings from production. Record those differences and identify what must be checked before applying the result to production. Even an image with no known vulnerabilities can contain a faulty authorization rule or run with excessive privilege. Scanning is useful evidence about the image, but it does not settle the workload review.
Sources and reference editions
- NIST Secure Software Development Framework1.1, SP 800-218