Does your release confirmation that binaries are digitally signed?
ID |
esf_s3c_dev/binaries_signed |
Severity |
critical |
Category |
|
Levels |
|
Optional |
false |
Tags |
cicd-sec-09, cicd-security, releases, security, supply-chain |
Description
Does your release confirmation that binaries are digitally signed?
Final packages including the correct metadata should be signed by a cryptographically-secure signature algorithm before being uploaded to the repository.
Rationale
Final packages may be compromised while going through the distribution system from the supplier to the customer. An adversary may attempt a man-in-the-middle attack or compromise the source code repository. As a result, malware or vulnerabilities can be introduced to the package, or an older version of the package containing an exploitable vulnerability can be delivered to the customer. Installing the compromised packages will impose risk to the customer organization and its system.
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.