Sign each release and attach the signature to the GitHub Release - #14347

Description

Adds a Sign Release workflow that signs each released image and attaches the signature to the GitHub Release. The OpenSSF Scorecard Signed-Releases check only looks at release assets (*.sigstore.json and similar), and each release has only the SBOM today, so we score 0 on it.

How it works, modeled on sbom_generator.yaml:

• Runs on release: published, or by hand with workflow_dispatch and a tag, to sign releases published before this existed.
• Resolves the digest of docker.io/civiform/civiform:<tag> from the release tag and writes docker.io/civiform/civiform@sha256:... to civiform-civiform_vX_Y_Z.digest.txt.
• Signs that file with Sigstore keyless signing (cosign sign-blob), so there are no keys to store or rotate. The signing identity is this workflow.
• Verifies the signature in the same job, then uploads the digest file and its .sigstore.json bundle to the release.

It has to run after the release is published because bin/create-release retags the SNAPSHOT image with docker pull, tag and push, which gives the release tag a different digest (v3.38.0: sha256:17315920... vs sha256:4d9869cc... on its snapshot; same config and layers). A signature made at build time would not apply to the release tag.

Signing the digest file, not the image in the registry, keeps this to one workflow with no Docker Hub push credentials. Signing the image itself in the registry could follow if we want cosign verify <image> to work directly.

Pinning: cosign-installer is pinned by SHA (v4.1.2) and cosign-release is set to v3.1.3, like the other actions here. I chose Sigstore keyless (Scorecard score 8) over SLSA provenance (score 10) because the SLSA generator is, as far as I know, referenced by tag rather than SHA, and I didn't want a Pinned-Dependencies exception. Not verified.

What I checked locally: the workflow file parses, the digest command returns the right digest for v3.38.0 from Docker Hub, and the tag and digest checks and file name logic behave as expected in bash. What I did not check: the cosign steps and the upload, which need a real run with an OIDC token. Plan: after merge, run it once with workflow_dispatch on the newest release, then on the last four, and confirm the next weekly Scorecard run moves Signed-Releases.

Docs: how to verify a release is in the workflow header comment. The dev wiki Releasing page still needs a short section, which I'll do separately because the wiki is a different repo.

Checklist

General

Read the full guidelines for PRs here

• Added the correct label: infrastructure
• Assigned to a specific person, civiform/developers, or a more specific round-robin list
• Added an additional reviewer from civiform/eng-admin as FYI (if this PR includes functionality changes and neither you nor the primary reviewer is an admin)
• Added an additional reviewer as required if changes potentially affect the security of the application.
• Removed the release notes section if the title is sufficient for the release notes description, or put more details in that section.
• Created unit and/or browser tests which fail without the change (if possible)
• Performed manual testing (Chrome and Firefox if it includes front-end changes)
• Extended the README / documentation, if necessary.
• Ensured PII wasn't added to any new logs, unless it was guarded by isDevOrStaging
• Noted in the PR description which, if any, code in this PR was generated by AI.

Instructions for manual testing

After merge, run the Sign Release workflow from the Actions tab with the newest release tag (for example v3.39.0). The release should gain civiform-civiform_v3_39_0.digest.txt and civiform-civiform_v3_39_0.digest.txt.sigstore.json. The command in the workflow header should verify them.

The workflow and this description were drafted with AI assistance (Claude).

Issue(s) this completes

Fixes #14343