Code Signing Best Practices

Feb 21, 2024

Code Signing Best Practices

Introduction

GlobalSign recommends that developers follow best practices for the Code Signing process and for securely generating and storing private keys.

Please review the 7 best practices below which are highlighted in the Code Signing Whitepaper by the CA Security Council.

7 Best Practices for Code Signing:

1. Minimize access to private keys

   • Allow minimal connections to computers with keys
   • Minimize the number of users who have key access
   • Use physical security controls to reduce access to keys

2. Protect private keys with cryptographic hardware products

   • Cryptographic hardware does not allow export of the private key to software where it could be attacked
   • Use a FIPS 140 Level 2-certified product (or better)
   • Use an EV code signing certificate which requires the private key to be generated and stored in hardware

3. Time-stamp code

   • Time-stamping allows code to be verified after the certificate has expired or been revoked

4. Understand the difference between test-signing and release-signing

   • Test-signing private keys and certificates requires less security access controls than production code signing private keys and certificates
   • Test-signing certificates can be self-signed or come from an internal test CA
   • Test certificates must chain to a completely different root certificate than the root certificate that is used to sign publicly released products; this precaution helps ensure that test certificates are trusted only within the intended test environment
   • Establish a separate test code signing infrastructure to test-sign pre-release builds of software

5. Authenticate code to be signed

   • Any code that is submitted for signing should be strongly authenticated before it is signed and released
   • Implement a code signing submission and approval process to prevent the signing of unapproved or malicious code
   • Log all code signing activities for auditing and/or incident-response purposes

6. Virus scan code before signing

   • Code signing does not confirm the safety or quality of the code; it confirms the publisher and whether or not the code has been changed
   • Take care when incorporating code from other sources
   • Implement virus-scanning to help improve the quality of the released code

7. Do not over-use any one key (distribute risk with multiple certificates)

   • If code is found with a security flaw, then publishers may want to prompt a User Account Control dialogue box to appear when the code is installed in the future; this can be done by revoking the code signing certificate so a revoked prompt will occur
   • If the code with the security flaw was issued before more good code was issued, then revoking the certificate will impact the good code as well
   • Changing keys and certificates often will help to avoid this conflict