Match a Release Artifact to Its Source
Tie a deployed release file to the reviewed source commit by checking the artifact digest, provenance, and release record.
A release can be approved and still deploy the wrong image. This task starts after artifacts have entered a registry or deployment system. Reconcile what each environment actually runs with the approved release record and source commit. Do not assume the deployment tag, dashboard label, or release page identifies the bytes in service.
Deployment reconciliation table
| Environment | Running digest | Approved digest | Source commit | Result |
|---|---|---|---|---|
| Staging | Capture from deployment record | Release manifest | Reviewed commit | Compare |
| Production | Capture from deployment record | Release manifest | Reviewed commit | Compare |
| Worker fleet | Capture each image digest | Release manifest | Reviewed commit | Compare |
Use deployment manifests, orchestrator status, or the artifact store for exact digests. If an image tag is mutable, resolve it to a digest at deployment time. Include workers, scheduled jobs, and regional replicas, not only the public API. A rollout can leave old and new versions live at once; record the expected window and identify any replica outside it.
Trace and resolve drift
For each running digest, find the approved release manifest. Confirm that the manifest links to a verified provenance statement whose subject is that digest and whose source revision is the reviewed commit. SLSA provenance can support this trace, but the operational question is whether running bytes match the approved release. If a packaging or signing step creates a new artifact, record that transformation and its input and output digests.
Mark a digest with no approved chain as drift. Stop further promotion, preserve deployment and registry logs, and identify whether the cause was a manual hotfix, rebuild, repackaging step, wrong tag, or stale replica. Do not overwrite the evidence to make the table pass. Decide whether to roll back, approve a new release, or complete a documented emergency change.
Keep the final reconciliation with environment, service, running digest, approved digest, source commit, observation time, and owner. Repeat it after promotion and after rollback. This check detects release drift; it does not judge whether the reviewed source code is free of vulnerabilities.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.
Sources
- SLSA Provenance Specification v1.2Accessed
- OpenSSF Scorecard ChecksAccessed