Issue
OpenSSF Scorecard identified that releases are not cryptographically signed and lack provenance, scoring 0/10.
Risk Level
Medium - Unsigned releases allow potential man-in-the-middle attacks and make it difficult to verify artifact authenticity.
Current State
- Releases published without cryptographic signatures
- No SLSA provenance attestations
- Users cannot verify release artifact integrity
- Missing supply chain transparency
Recommendation
Implement release signing and SLSA provenance for all published artifacts.
Option 1: Sigstore/Cosign (Recommended)
Use keyless signing with Sigstore for simplicity and transparency:
GitHub Actions Integration:
- name: Sign release artifacts
uses: sigstore/cosign-installer@v3
- name: Sign artifacts with cosign
run: |
cosign sign-blob --yes \
--bundle cosign.bundle \
tar-diff-linux-amd64
Benefits:
- No key management required (uses OIDC)
- Signatures stored in public Rekor transparency log
- Widely adopted in cloud-native ecosystem
Option 2: SLSA Provenance Generator
Add build provenance using GitHub's SLSA generator:
- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
with:
base64-subjects: "${{ needs.build.outputs.hashes }}"
Benefits:
- Documents build process and dependencies
- Achieves SLSA Level 3 compliance
- Verifiable build reproducibility
Option 3: GPG Signing (Traditional)
Use GPG keys to sign releases:
- Requires secure key storage and management
- More operational overhead
- Well-established in many ecosystems
Recommended Implementation
Combine both approaches:
- Use Cosign for artifact signing
- Use SLSA Generator for build provenance
- Publish signatures alongside release artifacts
- Document verification process in README
Steps to Implement
- Add Cosign signing to
.github/workflows/release.yml
- Integrate SLSA provenance generator
- Update release process to include signature verification instructions
- Test with a pre-release to validate workflow
- Document how users can verify signatures
Verification Instructions (for users)
Once implemented, users can verify releases:
# Install cosign
go install github.com/sigstore/cosign/v2/cmd/cosign@latest
# Verify signature
cosign verify-blob \
--bundle cosign.bundle \
--certificate-identity-regexp="^https://github.com/containers/tar-diff" \
--certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
tar-diff-linux-amd64
References
Related
Part of OpenSSF Scorecard evaluation THEEDGE-4717 (overall score: 6.8/10)
Issue
OpenSSF Scorecard identified that releases are not cryptographically signed and lack provenance, scoring 0/10.
Risk Level
Medium - Unsigned releases allow potential man-in-the-middle attacks and make it difficult to verify artifact authenticity.
Current State
Recommendation
Implement release signing and SLSA provenance for all published artifacts.
Option 1: Sigstore/Cosign (Recommended)
Use keyless signing with Sigstore for simplicity and transparency:
GitHub Actions Integration:
Benefits:
Option 2: SLSA Provenance Generator
Add build provenance using GitHub's SLSA generator:
Benefits:
Option 3: GPG Signing (Traditional)
Use GPG keys to sign releases:
Recommended Implementation
Combine both approaches:
Steps to Implement
.github/workflows/release.ymlVerification Instructions (for users)
Once implemented, users can verify releases:
References
Related
Part of OpenSSF Scorecard evaluation THEEDGE-4717 (overall score: 6.8/10)