What Immutable Release Evidence Proves—and What It Cannot

What immutable release evidence proves—and what it cannot

A deployment can succeed and still leave a difficult question behind: what, exactly, is running? A branch name is not enough. A container tag can move. A green pipeline says that a job passed, but not necessarily which bytes received traffic.

Release evidence closes that gap by connecting several identities that are often discussed as if they were one:

1. the source revision that was selected;
2. the controlled build that transformed it;
3. the immutable artifacts the build produced;
4. the authorization to deploy those artifacts;
5. the environment that received them; and
6. the health and routing decision observed afterwards.

That chain is powerful precisely because its claims are narrow.

Four claims that should stay separate

Provenance describes where an artifact came from and how it was built. SLSA provenance models this as verifiable information about software artifacts and their build process.

Integrity checks that the bytes being inspected are the bytes that were identified earlier. A cryptographic digest can reveal a changed artifact. A signature can bind an approved identity to that digest.

Authorization answers whether the actor and workflow were allowed to promote the artifact into a particular environment. A perfectly signed artifact can still be deployed by the wrong principal or through the wrong path.

Runtime evidence says what happened after deployment: which release a node reports, whether readiness passed and whether traffic was actually routed to it.

Collapsing these into one “verified” badge makes incident response harder. Keep the fields and decisions distinct.

What belongs in a useful record

A compact release record normally identifies:

• repository and commit;
• build workflow and invocation;
• builder identity and build time;
• artifact names and immutable digests;
• signatures or attestations and their verification policy;
• target environment and deployment identifier;
• reviewer or automated approval decision;
• runtime release identity and health result; and
• the previous known-good release.

Store identifiers and results, not secrets, source archives or production payloads. The record should help an authorised reviewer reproduce a decision without becoming a second sensitive data store.

What it does not prove

Provenance does not prove that source code is correct. A signature does not prove that a dependency is safe. A passing health endpoint does not prove every business workflow works. Evidence can show that a reviewed process produced and deployed particular bytes; it cannot replace code review, dependency analysis, testing, access control or runtime monitoring.

The distinction matters when communicating with customers. “This release is traceable to commit X and artifact digest Y” is defensible. “This release is secure because it is signed” is not.

Promotion should reuse artifacts

Build once, then promote the identified artifact. Rebuilding for production creates a new object with new dependencies, timestamps or toolchain state—even when it starts from the same commit. The release intended for production should be the release tested and approved.

BlinkHost follows this principle in its managed delivery path: source, build and deployment remain separately identified, production consumes immutable release artifacts, and runtime health reports the active release identity. The public contract is more important than any private implementation detail: customers need to know which evidence exists and which conclusion it supports.

Use evidence during failure, not only audits

When an incident begins, the record should answer three questions quickly:

1. Did the failing request reach the newly promoted release?
2. Can traffic return to the previous artifact without rebuilding it?
3. Did configuration, data compatibility or an external dependency change independently of the artifact?

Evidence that cannot support those decisions is ceremony. Start with the incident questions, then retain the smallest record that answers them.

Primary references

• SLSA provenance specification
• Sigstore: verifying signatures with Cosign
• GitHub Actions security hardening
• NIST Secure Software Development Framework

Reviewed 2 September 2026. External specifications can evolve; verify the linked version before using this as an assurance requirement.