Signed Releases
ID |
openssf_scorecard/signed_releases |
Severity |
high |
Category |
|
Levels |
|
Optional |
false |
Tags |
cicd-sec-09, cicd-security, releases, security, supply-chain |
Description
Does the project cryptographically sign releases?
This check tries to determine if the project cryptographically signs release artifacts.
A Release Signature is a cryptographic digital signature of a digest of the release contents, that could be verified by consumers of the release (e.g. a tarball) by using the publicly available public key of the signer.
OpenPGP and variants like GnuPG (GPG) are common public key frameworks used for this purpose. Other tools, like minisign, offer popular alternatives for signing the tarball of a release, either in source or in binary form.
There are other tools for digital signatures, like openssl, or code signing certificates (where public keys are signed by a trusted Certificate Authority).
Reference: OpenSSF Scorecard - Signed Releases.
Verification
This check looks for the following filenames in the project’s last (five) releases: *.minisig, *.asc (pgp), *.sig, *.sign.
Remediation
-
Generate and publish a signing key, if not done already.
When using raw public keys, i.e. not signed by a trusted Certificate Authority like the X.509 certificate model of 'signing certificates', the problem is: how to ensure that the public key is linked to the owner of the released software?
With PGP public keys, the public key should be downloaded by verifiers either from a trusted site (like organization’s website), or from a keyserver (the signature issues should published the public key on a keyserver and then go to a known keysigning party to become part of the Web of Trust.
-
Publish the release.
-
Download the release as an archive locally.
-
Sign the release archive with this key (should output a signature file).
-
Attach the signature file next to the release archive.
-
If the source is hosted on GitHub, check out the steps here.