Summary

  • A cryptographically valid GitHub attestation binds an artifact digest to recorded build provenance; it does not certify that the artifact is secure.
  • The effective control sits with the consumer: deployment must be denied when the repository, immutable workflow identity, commit or release condition, environment, or runner boundary differs from policy.
  • Private-repository attestations have a different observability model because GitHub’s Sigstore instance does not use the public transparency log applied to public repositories.

The signature can pass while the deployment fails

Consider a deployment gate receiving a container with a cryptographically valid attestation. The signature verifies, the digest matches and the provenance statement is intact. Yet the gate still rejects the image. It was built from an unexpected repository, through a reusable workflow referenced by a movable tag, on a commit outside the approved release line, in the wrong environment, or on a runner whose trust boundary the consumer does not accept.

That rejection is not a failure of attestation. It is the control working correctly.

GitHub describes artifact attestations as signed claims establishing build provenance. They can identify the workflow associated with the artifact as well as its repository, organization, environment, commit SHA and triggering event. Other information can be derived from the OpenID Connect identity used to establish provenance. For a binary, the workflow adds the attestation step after the build and grants the required identity-token and attestation permissions. For a container, the subject name and digest bind the recorded statement to a particular image content rather than merely to a mutable tag.

This creates an important property: the consumer can ask whether the artifact in hand is the artifact produced along the declared route. It does not answer whether the source was benign, the dependencies were sound, the workflow instructions were wise, or the execution environment remained trustworthy. Provenance narrows the question. It does not settle it.

GitHub makes that boundary explicit. Generating an attestation alone provides no security benefit; the attestation must be verified. Its documentation also says an attestation is not a guarantee that an artifact is secure. The consumer must define criteria, evaluate the attestation against them and make a risk decision. The distinction matters because a verification command that checks only cryptographic validity can be mistaken for a complete security verdict.

Policy gives provenance operational meaning

A useful admission policy begins with the expected repository and organization, but it should not end there. Workflow identity matters because two valid workflows within the same organization can embody very different controls. A centrally reviewed release workflow is not interchangeable with any workflow able to obtain signing permissions.

References also matter. GitHub says a full commit SHA is the safest reference when calling an external reusable workflow because the SHA is immutable. A branch can advance, and a tag can move. An attestation may faithfully record a workflow route that was acceptable yesterday but no longer corresponds to the reviewed instructions today. A consumer that accepts only a workflow name, without an immutable identity, leaves part of the build definition outside the admission decision.

The recorded commit and triggering event add further conditions. A production policy might require the artifact to correspond to an approved release commit rather than merely any commit in the repository. The environment claim can distinguish a governed release path from a less controlled build context. None of those rules is supplied automatically by the existence of the signature. They are choices made by the consuming organization.

Runner trust is another independent axis. GitHub warns that self-hosted runners are not guaranteed to be ephemeral, clean machines and can be persistently compromised by untrusted workflow code. A valid attestation therefore cannot prove that a runner was uncompromised. It can provide evidence about the recorded build identity, while the admission policy separately decides which runner conditions or build environments are acceptable. Treating runner trust as implied by provenance would erase one of the most consequential boundaries in the evidence.

Enforcement turns a record into a gate

GitHub documents a Kubernetes admission-controller pattern built around the Sigstore Policy Controller, a GitHub trust root and cluster image policy. Enforcement is enabled for selected namespaces. Once active, the controller can verify attestations before images are admitted and reject artifacts that fall outside the configured trust policy.

The configuration details expose the real security model. Installing the controller alone does not enforce anything. The relevant policy must be installed and enabled in the namespace. Image matching and exemptions also shape the effective boundary: an image outside the configured match set can be rejected, while an exemption deliberately removes an attestation requirement. The security outcome therefore depends on where the policy applies and exactly what it accepts, not simply on whether an organization “uses attestations.”

Public and private repositories also differ in observability. Public-repository attestations use the Sigstore public-good instance and are written to a publicly readable transparency log. Private-repository attestations use GitHub’s Sigstore instance, which shares the same codebase but has no public transparency log and federates only with GitHub Actions. That is a difference in who can observe and independently inspect the record. It is not, by itself, proof that the private mechanism is weak.

The available first-party material does not establish how broadly consumers enforce these policies, how often valid attestations are rejected, or what false-acceptance rate deployments experience. It also does not establish that a particular runner remained clean. Those unknowns should stay unknown. Attestation supplies verifiable provenance evidence, not adoption statistics or a universal safety judgment.

The practical conclusion is precise: treat attestation verification as admission control. Before deployment, require the expected repository, an immutable workflow identity, the approved commit or release condition, the intended environment and an acceptable runner trust boundary. When any condition differs, reject the artifact and preserve a rejection receipt showing which claim failed policy. That receipt turns a denied deployment into durable evidence rather than an unexplained interruption.

Sources