-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Improve OpenSSF Scorecard: Implement Signed Releases #2369
Description
Context
Our OpenSSF Scorecard currently scores 0/10 on the Signed-Releases check. This check verifies that release artifacts are cryptographically signed, allowing users to verify the provenance and integrity of what they download.
The check scans the 5 most recent releases for the presence of signature files (.sig, .asc, .sigstore, .intoto.jsonl, etc.) attached as release assets.
Scoring tiers
| Score | Requirement |
|---|---|
| 8/10 | A signature file attached to every release |
| 10/10 | A SLSA provenance file (.intoto.jsonl) attached to every release |
Current state
The release workflow (release.yml) builds and uploads binaries and Docker images but does not sign them. No signature artifacts are present in recent releases.
Note: the build-and-push-images-github-registry job already uses actions/attest-build-provenance for GHCR images, which is a good foundation, but does not satisfy the Scorecard check (which only looks at release assets).
Proposed plan
1. SLSA provenance for binary release artifacts (→ 10/10)
Use the official slsa-framework/slsa-github-generator reusable workflow.
- The
build-and-push-artifactsjob outputs SHA-256 hashes of the release tarballs - A new
slsa-provenancejob calls the SLSA generic generator, which produces amultiple.intoto.jsonlfile and uploads it to the GitHub Release automatically - Keyless — uses GitHub Actions OIDC, no GPG keys or secrets to manage
- Users can verify with
slsa-verifier
Rough change to release.yml:
- name: Compute artifact hashes
id: hash
run: |
echo "hashes=$(cd dist && sha256sum flannel-* | base64 -w0)" >> $GITHUB_OUTPUT
slsa-provenance:
needs: build-and-push-artifacts
permissions:
actions: read
id-token: write
contents: write
uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0
with:
base64-subjects: "${{ needs.build-and-push-artifacts.outputs.hashes }}"
upload-assets: true- Cosign keyless signing for container images
After each image push (Docker Hub + GHCR), add a cosign sign step using sigstore/cosign-installer. Also keyless via OIDC.
Users can verify with cosign verify.
- User-facing verification documentation
Add a section to the docs (e.g. docs/verifying-releases.md) explaining how to verify:
- Binary provenance: slsa-verifier verify-artifact
- Container images: cosign verify
Questions for discussion: Should we also sign the Docker Hub images, or focus on GHCR only?