What are code signing best practices?
Code signing verifies the identity of the software developer or publisher and confirms that the integrity of the code is intact from the time the code was signed to the time the code was downloaded. This proves the code can be trusted. Unfortunately, bad actors are constantly attempting to penetrate code signing practices to embed malware into the trusted code.
Here are some best practices to mitigate the risks of successful attacks:
- Secure key storage: If the private key for signing is compromised or stolen from an organization, it can be used to sign software embedded with malware, so the released software registers as legitimate software originating from that organization. Private keys should be secured in a Hardware Secure Module (HSM) or encrypted at rest. According to CA/Browser (CA/B) Forum requirements, keys for public trust usage must be stored in an HSM.
- Enforce key and signing access controls: Set up policies and enforce key access controls to ensure only developers and users who are authorized can sign with specific keys, when needed. Generate keys in the cloud so that they do not get shared, lost, or stolen. Enforce separation of duties, i.e. separate the responsibilities of those who generate keys from those who sign. Implement Multi-factor Authentication (MFA) to ensure the person accessing signings is indeed who they say they are. Revoke access from personnel who have left or no longer require access to signings or key generation.
- Monitor and audit key signing workflows: Track who signed what when, so you can respond quickly to unauthorized signings and take appropriate remediation action. Regularly audit all activities associated with key pairs, including generation, certificate operations, and assignment of key and signing access.
- Stay current and enforce company-wide policies on cryptographic standards: Industry requirements can change to help organizations stay ahead of the threat landscape. New CA/Browser Forum requirements prescribe 3072-bit RSA as the minimum key requirements for publicly trusted code signing and time-stamping certificates, effective June 1, 2021. Developers and users within an organization may or may not be aware of the changes as they generate keys or sign code. Organizations must enforce industry requirements to prevent users from generating keys or requesting certificates with weak or non-compliant algorithms, key size or curves.
- Enable automated code signing in SDLC processes: Integrate and automate signings in SDLC process such as CI/CD pipelines so you can reduce the risks of unsigned code or non-compliant signings. You can set up security controls along with automation to build secure and compliant software at the continuous and rapid pace of software development.
- Compare signings from different build servers: Recent software supply chain attacks have caused major operational and financial disruptions in high-impact organizations around the world. Bad actors infiltrate the development operations at a target organization and embed malware into code during SDLC, and this tampered code was later released and deployed in customer systems. Sign and compare the hash of the software from different build servers before release to find out if there are any discrepancies between the server builds. A quorum of two or more identical builds can provide assurance that the builds are secure and that no unknown code has been included in the build.
- Revoke compromised certificates: If you discover compromised keys or signed malware, report the event to your Certificate Authority (CA). The code signing certificate will need to be revoked which will render the software invalid and stop the further propagation of malware.
- Timestamp your signed code: Avoid the risks of software expiring unexpectedly when the code signing certificate expires. Code signing certificates are valid for 1-3 years. When a code signing certificate expires, the validity of the software that was signed will also expire unless the software was timestamped when it was signed. The system will record the timestamp and the software will continue to be valid as long as it is in production. Another reason to timestamp your code is to minimize the impact of a certificate revocation. If malware was discovered and the associated certificate must be revoked, timestamping will minimize the impact, as the revocation will only affect software released after the date of compromise.