Skip to content

Improve OpenSSF Scorecard: Implement Signed Releases #2369

@pgonin

Description

@pgonin

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-artifacts job outputs SHA-256 hashes of the release tarballs
  • A new slsa-provenance job calls the SLSA generic generator, which produces a multiple.intoto.jsonl file 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
  1. 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.

  1. 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?

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions