Sign the digest with a workflow identity

Anyone can create an image and attach an arbitrary claim to it. The verifier needs to distinguish a statement from the accepted workflow from a statement made by an unrelated identity. Keyless signing supplies cryptographic evidence tied to the signing job’s GitHub identity, rather than a stored signing key supplied by the repository.

Security decision · trust

Which workflow endorsed these exact bytes?

Required property

Verify digest signature against exact workflow subject and issuer

Responsible control

Cosign, Fulcio and Rekor

Scope

sign-attest.yml at refs/heads/main

Failure behavior

Missing or wrong signature fails configured verification

Limit

A compromised trusted workflow can sign malicious content · Cloud service account is not the Sigstore signer

Which identity is accepted

Sign and Attest authenticates to the registry, installs Cosign, and calls cosign sign --yes on repository@digest. The setup action defaults to Cosign v2.4.1. The expected certificate issuer is:

https://token.actions.githubusercontent.com

The expected subject is:

https://github.com/devSatym/gcp-supply-chain-security/.github/workflows/sign-attest.yml@refs/heads/main

The reusable signing workflow is the identity. deploy.yml orchestrates the run, while verify.yml consumes statements. Neither substitutes for the signing identity. CI verification and Kyverno both require the actual signing workflow subject and issuer.

Artifact and metadata storage

The application repository is configured with immutable tags. Cosign v2’s legacy signature and attestation indexes use metadata tags that must be updated as statements are appended. The workflow therefore supplies COSIGN_REPOSITORY for a separate mutable metadata repository, and admission specifies that same repository location.

Mutable metadata storage does not make a valid signature applicable to arbitrary image content. The cryptographic statements remain bound to the image digest. It does create an availability dependency: metadata can become missing or inaccessible independently of the image. A registry pull succeeding is therefore insufficient evidence that admission can read every required claim.

What a signature establishes

Successful verification establishes that the relevant statement matches the digest and accepted certificate identity/issuer under the verifier’s Sigstore trust expectations. The policy names Rekor at https://rekor.sigstore.dev; transparency supports inspection of signed claims. It does not independently audit the source, scanner decisions, or builder environment.

This workflow subject includes the mutable ref main, not a commit-pinned workflow implementation. If an authorized or compromised actor changes that trusted workflow, the resulting job can retain the accepted identity. A valid signature from that identity does not establish that the workflow ran benign code. See shared trust dependencies.

Failure and evidence

Wrong identity strings cause otherwise valid statements to fail the contract. The identity consistency test checks consumers for the canonical workflow suffix and the admission entrypoint. It is a useful local drift guard, not proof that Sigstore or registry services are available.

Historical verification and unsigned-denial records corroborate particular executions. They are not fresh verification of today’s registry state. Continue with the distinct SBOM and provenance claims: origin evidence alone does not make an inventory complete or a release approved.