Cannot prove where a release came from? A checklist from commit to deployment

The release works, but the evidence is missing

The release works, but the team cannot answer a few simple questions. Who approved the change? Where was the artifact built? Was the artifact deployed to users built from the exact commit that passed review?

During an incident, people search chats and compare records, yet the route may remain unclear. That delays finding the cause and restoring service safely.

Release processes gradually gain jobs, permissions, and automation. To find the gaps, trace one recent release from commit to deployment. This route is part of the software supply chain.

Start by drawing five points

Choose one recent release and mark its route:

commit → dependencies → CI build → artifact registry → deployment

At every point, answer four short questions:

• which code, record, or artifact are you protecting;
• what could go wrong;
• what is the simplest check that would reveal the problem;
• who owns the check and the response.

Begin with change history, logs, and current configuration. If only a colleague’s memory can explain a step, record it as a gap rather than confirmed evidence.

Minimum checks for every link

1. Commit. Check whether you can identify the author, exact code revision, and approval record. For the main branch, review the required code-review rules, write restrictions, and history of administrative actions. Changes to branch protection rules should also leave a record.

2. Dependencies. If the ecosystem uses a lockfile—a file that records resolved dependency versions—keep it with the code and review its changes. Vulnerability scans help, but cannot explain a package’s source or purpose.

3. CI build. Connect every run to a specific commit. Do not run code from untrusted changes in an environment with elevated permissions or access to important secrets. The build log and related records should let you identify the initiator, configuration, environment, and output digest.

4. Artifact registry. Record who published each artifact and configure protection against silent overwriting. Tie deployments to a digest or another immutable identifier supported by the platform. Credentials used for routine operations should not permit arbitrary overwriting or deletion of releases.

   A digest confirms that the artifact’s bytes match the expected bytes. By itself, it does not prove who built or approved the artifact. That requires connected commit, build, and deployment records.

5. Deployment. Record the environment name, time, responsible person, and artifact identifier. Promote the same artifact between environments instead of rebuilding it. Before deployment, compare its identifier with the version approved for release.

Not every signal should stop a release

Define three response levels in advance. The events below are examples, not a universal policy:

• Warning: a lower-risk deviation with an assigned owner and correction deadline.
• Investigation trigger: a run started by an unexpected user, an unfamiliar build environment, or unexpected access to a secret.
• Reason to block a release: required approval is missing, a mandatory check failed, artifact identifiers differ, or provenance cannot be established.

Which events belong at each level depends on the product and its risks. Write the rules in advance instead of deciding while a release is already waiting for deployment.

A first audit limited to one day

1. At the start of the day, draw the five points and select one recent release.
2. Collect the available evidence: the commit and approval, a lockfile if one exists, the CI run number, build log, registry identifier, and deployment record.
3. Ask the people responsible for each stage to show independently how they reconstruct the route. Record verbal assumptions as gaps.
4. For every gap, define the risk, owner, correction deadline, and effect on the release decision.

If you cannot reconstruct the entire route in one day, the audit should produce a list of missing evidence. Do not replace that evidence with assumptions.

Verify log retention first, then flag access rights with no confirmed need. Revoke them only with the system owner and a recovery path.

After that, plan deeper changes: branch protection, build isolation, protection against artifact overwriting, and automated identifier checks. Do not rebuild the entire platform on the first audit day.

Four risky shortcuts

• Treating a green CI status as proof of trustworthy artifact provenance.
• Selecting an artifact for deployment only through the mutable latest tag without recording its digest.
• Sharing one broadly privileged account.
• Creating an alert without an owner and a defined action.

Where AI can help

If organizational policy allows it, give AI anonymized stage names, types of access rules, log field names, and only the necessary configuration excerpts. Remove private data first. Do not provide secrets, tokens, private code, or internal addresses.

AI can organize a draft map, identify missing questions, and suggest an evidence format. It cannot see actual permissions, steps omitted from the inputs, or whether the available logs are complete.

Verify every suggestion against the real CI configuration, registry records, deployment logs, and the people responsible for those systems.

You need evidence, not a perfect diagram

The Docker article about Omdia’s 2026 report provides context on software supply chain risks. The practical steps in this note are an editorial checklist designed to remain neutral across Git services, CI systems, registries, and deployment platforms.

The outcome of a first audit is straightforward: the team can name the exact commit, show its approval record, find the build, compare the artifact identifier, and explain who authorized deployment. Stronger protection starts with this sequence of verifiable evidence.

Sources

• https://www.docker.com/blog/software-supply-chain-security-omdia-2026-report/