You signed the build. Does deployment actually verify it?
Turn artifact provenance into a deployment decision by verifying the exact output, constraining its origin, and testing both acceptance and rejection paths.
A signature helps only when someone checks it
A build workflow produces a release archive and an attestation describing its origin. The dashboard is green, the release has a badge, and deployment downloads a file with the right name. If the deployment never verifies that file against an approved origin, the attestation has not yet become a release control.
This guide follows a hypothetical API archive built in GitHub Actions and deployed through a separate job. It focuses on the handoff between build output and deployment. Our existing OIDC guide addresses how a workflow obtains cloud credentials. Here the question is different: which exact bytes may those credentials deploy?
GitHub documents artifact attestations and the CLI's verification options. SLSA describes verification as checking provenance against a policy. The rollout plan and acceptance tests below are worqcloud editorial recommendations. Example repository names and artifact paths are placeholders, and the command fragment is a starting inspection, not a complete production policy.
Name the artifact and the trust decision
Choose one output that people will actually run or deploy. It might be a packaged executable, an archive, or a container image. Identify its owner, build workflow, intended release context, and the consumer that will enforce verification.
A filename is useful to humans but is not a stable identity for content. Two archives named api.tar.gz can contain different bytes. Define the digest or other supported immutable reference that connects the produced artifact, the attestation, and the deployment operation.
Write a trust sentence before selecting flags. For example, production may deploy only an artifact produced by the approved release workflow from the expected repository and permitted source context. Then identify which parts the verification tool checks and which require additional release-policy evaluation. Passing one command should not be mistaken for enforcing every part of that sentence.
Distinguish provenance from a security verdict
An attestation can provide evidence about where and how an artifact was built. It does not establish that the software contains no vulnerabilities, has no malicious dependency, or behaves correctly for your users. GitHub explicitly warns against treating attestations as a guarantee of software security.
Keep other release checks visible. Tests, dependency review, vulnerability handling, access control, and approval solve different problems. Provenance can strengthen the relationship between those checks and a specific output, but it does not replace their quality.
For the API archive, the useful question is whether the artifact now entering deployment is the one associated with the approved build evidence. If that relationship is missing, even a strong test process may apply to a different output from the file ultimately deployed.
Generate evidence for the output you intend to distribute
Configure attestation generation using GitHub's supported action or tooling and the permissions documented for your repository arrangement. Review the build and signing workflow as privileged code. A valid identity attached to an unreviewed build process is still a weak release boundary.
Choose the subject after the intended packaging step. If the pipeline signs an intermediate directory and later creates or modifies the deployed archive, the evidence may not identify the final object. Record the output path and digest that consumers should verify.
Keep the build output immutable through subsequent steps. If a later job injects configuration, repackages files, or mutates an image, decide whether that creates a different artifact requiring its own evidence. Avoid assuming that a familiar release name preserves identity through transformations.
Download first, verify those bytes, then deploy them
The consumer should verify the artifact it will actually use. A workflow that verifies one download and later fetches the same mutable URL again leaves a gap. The second response may differ from the first even though both downloads use the same name.
For an archive, retain the verified local file and pass that exact object into the deployment operation. For a container, use the supported immutable image reference through verification and deployment. Check your registry and tooling behavior rather than assuming that a mutable tag cannot change.
Make the relationship observable in release records. Include the artifact digest, verification result, build reference, and deployment identifier. An operator should be able to connect the running release with its approved output without reconstructing a terminal history.
Verify the expected origin precisely
The GitHub CLI requires an expected repository or owner when verifying an artifact. It also offers options to constrain signer identity and evaluate the returned evidence more precisely. Review the current CLI reference and the workflow arrangement before deciding which checks represent your policy.
A broad owner check and a specific repository check are different trust boundaries. A repository can also contain several workflows with different authority. If the approved build uses a reusable workflow, GitHub's CLI documentation describes the signer identity that must be considered.
Treat verification output as evidence to interpret, not a collection of fields to skim after a green exit. Confirm the expected predicate and relevant identity constraints. If source branch, event, or revision restrictions matter, ensure the chosen policy actually checks them through supported flags or explicit evaluation of the verified result.
gh attestation verify ./dist/api.tar.gz \
--repo YOUR_ORG/orders \
--signer-workflow YOUR_ORG/orders/.github/workflows/release.ymlVerification example for an existing archive. Replace the placeholders and confirm CLI support. Additional source-context restrictions may require further policy checks; this command alone does not implement every release rule.
Put a gate before production authority is exercised
Place verification before extracting, executing, or deploying an untrusted artifact where the workflow permits. A release tool can run hooks or scripts from a package, so consider when those bytes first become executable in your process. The trust check should protect the boundary that matters.
Fail the deployment if required evidence is missing, invalid, or inconsistent with the policy. A warning-only pilot can help understand compatibility, but document its purpose and the transition to enforcement. A permanent log message that operators routinely ignore is not an effective gate.
Separate evidence lookup failures from policy failures in reporting. A temporary service outage and an artifact from an unexpected workflow may both block release, but they require different investigation. Clear feedback helps operators avoid disabling the gate simply because every failure looks the same.
Test rejection as deliberately as acceptance
Begin with a known artifact from the approved build and confirm that it verifies under the intended policy. Retain the version of the verifier, policy configuration, and sanitized output so the test can be repeated.
Then change a copy of the artifact and confirm rejection. Test a correctly attested artifact from an unapproved repository or workflow in a sandbox arrangement. Also test missing evidence. Each case should establish a specific boundary, with no production deployment attempted.
Review the entire job after a rejection. It should not fall through to a deployment step, silently retry with a broader owner check, or fetch a replacement from an unrelated location. The desired outcome is an understandable blocked release with a supported investigation path.
Keep rollback artifacts within the policy
A rollback is still a deployment. Decide how the previous approved artifact and its verification material remain available for the recovery window. Do not assume that a tag, temporary workflow artifact, or online evidence source will exist forever.
Use the supported retention and retrieval options for your repository and registry. If offline verification is part of recovery, read the CLI's documented limitations and trust-root requirements. An offline bundle is an operating choice with its own maintenance needs, not a universal shortcut around evidence availability.
Rehearse verification of the previous release in the environment used during recovery. The operator should know the immutable target, where evidence is retrieved, which policy applies, and what happens if it cannot be established. An emergency release needs a reviewed exception process rather than an improvised removal of verification.
Protect the workflow that creates the claim
An attestation's value depends on the build identity and process that issue it. Review who can change the workflow, which source revision it checks out, which actions or dependencies it executes, and which events can trigger it.
Keep untrusted contribution code away from privileged release behavior according to GitHub's security guidance. An attestation that accurately describes a build from an unauthorized context is still unacceptable for production. Cryptographic validity and your release authorization are related but separate checks.
Record the approved workflow identity and update it through review when the pipeline changes. A move to a shared workflow, repository rename, or new packaging stage can affect the evidence consumers see. Test the new relationship before enforcing it across all releases.
Roll out the consumer gate on one release path
Choose one artifact and deployment target for the first enforcement. Inventory the ordinary release, rollback, and emergency paths so the team understands what must continue to work. Avoid enabling a broad gate without knowing which legitimate artifacts lack the required evidence.
Use a bounded observation period if necessary, with a named owner and an enforcement decision date. Review genuine failures rather than increasing the accepted scope until every historical release passes. The policy should describe approved behavior, not all behavior that has ever occurred.
After enforcement, investigate exceptions through the same release record. If a workflow needs another signer or artifact type, review that as a trust change and add positive and negative tests. This keeps the gate understandable as the system evolves.
Make the final handoff auditable
For the API archive, a completed release record should connect the approved build, the immutable artifact, its verified provenance, and the deployment that consumed it. The exact fields depend on your tooling, but the relationship should be visible to another authorized engineer.
Check that the process verifies the final bytes, applies the intended origin policy, and stops before production changes when verification fails. Rehearse the rollback path and give operators clear diagnostic evidence for failed lookups and rejected origins.
Start with that one complete handoff. Generating an attestation is useful preparation. The operational benefit appears when the consuming system checks it and enforces a deliberate decision about what may run.