Investigate: OpenSSF Best Practices Badges - Check if dockerhub and Git cryptographically signs our releases

In order to fully validate the silver level of OpenSSF Best Practices Badges for our project and for security reasons, we have to check if dockerhub and Git cryptographically signs our releases.

Here are the requirement to meet:
The project MUST cryptographically sign releases of the project results intended for widespread use, and there MUST be a documented process explaining to users how they can obtain the public signing keys and verify the signature(s). The private key for these signature(s) MUST NOT be on site(s) used to directly distribute the software to the public. If releases are not intended for widespread use, select "not applicable" (N/A). [signed_releases]
The project results include both source code and any generated deliverables where applicable (e.g., executables, packages, and containers). Generated deliverables MAY be signed separately from source code. These MAY be implemented as signed git tags (using cryptographic digital signatures). Projects MAY provide generated results separately from tools like git, but in those cases, the separate results MUST be separately signed.

It is SUGGESTED that in the version control system, each important version tag (a tag that is part of a major release, minor release, or fixes publicly noted vulnerabilities) be cryptographically signed and verifiable as described in signed_releases. [version_tags_signed]

Here is the questionnaire :
https://bestpractices.coreinfrastructure.org/en/projects/5925?criteria_level=1

If it is a small issue; fix directly, if this is more work; create new Github issues.

[Sander3003]

Todo: build infrastructure make it work

[Sander3003]

@pascalwilbrink : We can generate checksums / sha's automatically via a GH action:

https://github.com/marketplace/actions/generate-checksum

[noraeb]

Proposal for signed_releases

As part of achieving the OpenSSF Silver Best Practices Badge, we need to cryptographically sign our release artifacts. After investigation, I'm concluding that:

• Our Docker images are our primary deliverables and therefore fall under the signed_releases requirement.
• Our existing signed commits are a good security practice but do not satisfy the requirement on their own.
• The version_tags_signed requirement is marked as SUGGESTED, not MUST, and is not easily achievable with our automated release-please setup. We will not pursue this for now.

Proposed solution

I propose to add keyless Cosign signing (part of the Sigstore project) to all pipelines that publish Docker images to DockerHub. Sigstore is free and open source, and is backed by the Open Source Security Foundation (OpenSSF) under the Linux Foundation — the same foundation behind the Best Practices Badge we are working towards.

Cosign keyless signing works by using the GitHub Actions OIDC token to prove that an image was produced by a specific workflow in our repository — no private key needs to be stored anywhere. Signatures are recorded in the public Rekor transparency log, which anyone can query to verify an image.

Required changed

1. Pipeline permissions: all pipelines need id-token: write added to their permissions block (required for Github Actions to request an OIDC token for keyless signing).
2. Cosign signing step: add the signstore/cosign-installer Github Action. More info: https://github.com/sigstore/cosign#quick-start

Required documentation

To satisfy the requirement that a documented verification process exists for users, we propose adding the following section to SECURITY.md in the relevant repositories:

Verifying Docker images

All Docker images published to DockerHub are signed using
Cosign with keyless signing
via GitHub Actions OIDC. No private key is stored anywhere — signatures are
verified against the Rekor transparency log.

To verify an image, first install Cosign,
then run:

cosign verify \
  --certificate-identity "https://github.com/com-pas/<repo>/.github/workflows/<workflow-file>.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://github.com/login/oauth" \
  lfenergy/<image-name>:<tag>

[Sander3003]

Proposal looks good to me! What is the status? Can we move to the next step?