SLSA build provenance for the teecryptor image, verified by partners at pin time

[haimbj1]

What

A production build now emits a keyless SLSA build provenance attestation for the
amd64 platform digest, using the workflow's OIDC token and Fulcio. No signing key.
Public Rekor, plus GitHub's public attestation API.

The job summary prints {image_digest, source_sha} and the ready-to-run
gh attestation verify command.

Same shape as the keygen PR, adapted to this repo's multi-arch build.

Why SLSA only, and no cosign

An earlier revision signed with cosign too. Review found a blocker that this change
removes outright rather than works around:

actions/attest@v3.0.0 resolves registry credentials only from the auths object in
~/.docker/config.json. I confirmed this in the published bundle — zero occurrences of
credHelpers, credsStore or docker-credential in 3.5 MB:

const credKey = Object.keys(dockerConfig.auths || {}).find(...) || registry;
const creds = dockerConfig.auths?.[credKey];
if (!creds) throw new Error(`No credentials found for registry ${registry}`);

This job authenticates with gcloud auth configure-docker, which writes only a
credHelpers entry. With push-to-registry: true the attest step would have thrown on
every production build — and because it dies there, the summary step never runs, so every
build would lose the digest handoff this feature exists to produce.

push-to-registry: false makes the whole problem vanish. The partner reads the bundle
from GitHub's public API, which needs no account.

The amd64 detail

This build is multi-arch. It attests steps.manifest.outputs.amd64_digest — the platform
digest the TDX VM runs and the one partners pin. An attestation on the manifest-list
digest would never match a pin.

Main changes

• actions/attest-build-provenance (SHA-pinned) after the Trivy gate, with
  push-to-registry: false.
• Guarded by if: inputs.testing != true && github.ref == 'refs/heads/main'. A testing
  build never attests: it can run from any branch, so the certificate would carry a ref
  no partner accepts.
• attestations: write moved from workflow level to the merge job. At workflow
  level it also landed on test, which runs cargo test — third-party build scripts.
• The summary prints constants, not values derived from the run, and is guarded by
  if: always() so a failure never costs the operator the digest.
• SECURITY-OVERVIEW.md records why the CEL cannot carry the origin proof.
• keys/variables.tf: the deferred image_signatures CEL note now says plainly that
  keyless provenance can never satisfy that attribute — it matches a public-key
  fingerprint, which a keyless build does not have. Without this, a reader would try to
  wire a fingerprint that does not exist.

Honest note on SHA pinning

actions/attest-build-provenance is SHA-pinned; most other actions in this job are not,
including aquasecurity/trivy-action@master, which runs immediately before it with the
same id-token: write. The comment now says so rather than implying the pin closes the
row.

Checked before pushing

actionlint clean. Summary rendered for both paths — production prints the partner block,
testing prints none. Job-level permission scoping verified by parsing the YAML. The verify
flag set exercised against a real attested public image: correct values exit 0; wrong
commit, wrong ref and wrong workflow each exit 1.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.