What does actions/attest-build-provenance produce, and what does gh attestation verify prove?

## The question provenance answers A build produces bytes. Later, someone deploys bytes. Provenance is the cryptographic answer to "did these bytes actually come out of the pipeline we think they did, from the source we think they did?" It is a different question from "are these bytes safe", and conflating the two is the most common error in this area. ## What the action does `actions/attest-build-provenance` runs as a step in the workflow that built the artifact — that placement is the whole point, because it is what lets the signed claim be about *this* build. **Inputs.** `subject-path` pointing at the built file (globs allowed), or a `subject-digest` plus `subject-name` when the artifact lives elsewhere, such as a pushed container image identified by its digest. **Permissions.** Three, and candidates should be able to say why each: - `id-token: write` — mints the workflow's OIDC token, the identity everything else rests on. - `attestations: write` — stores the resulting attestation against the repository. - `contents: read` — the ordinary checkout. **Output.** An in-toto statement whose *subject* is the artifact's name and SHA-256 digest and whose *predicate* is SLSA provenance: the repository, the workflow file and ref, the commit SHA, the trigger, and the builder identity. It is signed through Sigstore using a short-lived certificate issued against the workflow's OIDC identity — "keyless" signing, meaning there is no private key in a secret for anyone to steal, and the certificate's subject encodes which workflow in which repository at which ref did the signing. ## What verification actually checks `gh attestation verify ./app.tar.gz --repo my-org/my-service` performs, in order: 1. Compute the SHA-256 digest of the local file. 2. Retrieve attestations recorded for that digest (from GitHub, or from a bundle for offline verification). 3. Validate the signature and its certificate chain. 4. Check that the certificate's identity matches the expectation you passed — `--repo` for a specific repository, `--owner` for any repository under an organisation. Step 4 is load-bearing and is where real deployments go wrong. Verification without a pinned expected identity degenerates into "somebody, somewhere, attested something" — an attacker with any GitHub repository can produce a validly signed attestation for their own artifact. **A verification that does not assert who you expected the signer to be is not a security control.** Pin the repository, and where it matters, pin the workflow too. ## SLSA levels, honestly SLSA (Supply-chain Levels for Software Artifacts) grades build integrity. Roughly: Build L1 means provenance exists; L2 means the provenance is signed and generated by a hosted build platform rather than asserted by the developer; L3 requires stronger isolation so the provenance cannot be forged by the build itself. GitHub positions artifact attestations produced this way on hosted runners at Build Level 2, with higher levels demanding additional isolation of the build and signing process. Say the level with that hedge; do not claim a level a plain workflow does not earn, and note that a self-hosted runner someone can log into changes the trust story materially. ## What it does not prove Be explicit, because interviewers push here: - **Not safety.** Provenance says who built it, not whether the code is vulnerable, whether dependencies are clean, or whether tests passed. - **Not source integrity.** If a malicious commit reached the branch, the build faithfully attests a malicious artifact. Provenance composes with branch protection and review; it does not replace them. - **Nothing, if unverified.** An attestation nobody checks at the deployment gate is decoration. - **Nothing about a different artifact.** The binding is to a digest. Rebuild and you get different bytes and a different attestation; "the same version" is not the same thing as the same digest. ## Where verification belongs At the point of consumption, not the point of production. The deployment step, the admission controller, or the installer verifies before the artifact runs. Verifying in the same pipeline that produced the artifact proves very little — the interesting adversary is one who substitutes bytes *between* build and deploy, which is precisely the window a digest-bound, identity-pinned check closes. ## The senior signal Anyone can quote the action name. The signal is in the second half: what the check pins, where it runs, and what it still does not tell you. A candidate who says "verify with `--repo` at the deploy gate, because otherwise any signed artifact passes" has thought about the adversary. A candidate who says "we generate attestations" has thought about the checkbox.