Understanding Code Signing best practices

Code signing is used to authenticate the identity of the developer of a program and where it came from, while also confirming that the software has not been altered since it was signed.

By code-signing a program, application, executable, or script, a developer is attaching a digital certificate that confirms their identity and the integrity of the software. Code signing certificates use public-key cryptography, which is the same technology that is used with other types of digital certificates. This approach is supported across operating systems and platforms, from mobile to desktop environments to embedded systems. Code signing is widely used in Windows by Microsoft, Mac OS X by Apple, Linux distributions, as well as on iOS and Android.

As cyber threats increasingly target gaps in software trust, code signing has become a frontline defense against tampering, malware distribution, and supply chain attacks.

Implementing strong code signing practices is therefore critical for software publishers and development organizations seeking to protect users, maintain platform trust, and ensure software can be delivered safely and reliably. The following best practices help to address the most common risks associated with code signing security:

• Secure your code with code signing certificates: The most important recommendation of all is to use code signing certificates whenever possible. These verify the source and authenticity of code to end-users and increase customer confidence in their personal security. By properly signing your code, you can imbue your application or program with trust managed by a trusted public certificate authority like Sectigo. For additional security, you can use an Extended Validation (EV) Code Signing Certificate which offers stronger identity verification compared to standard code signing.
• Minimize access to private keys: Any good IT expert will institute access control measures whenever possible; that includes restricting access to private keys and base root certificates. You should only allow a small number of individuals to have access to your organization's private keys, and those individuals should have a specific reason for needing access. Instituting a role-based access (RBAC) policy within your organization will help limit possible exposure.
• Protect private keys with cryptographic hardware: Using cryptographic hardware allows you to protect your private keys with the most up-to-date encryption algorithms. This type of hardware should be at least a FIPS 140 Level 2-certified product. Products like hardware security modules (HSMs) will protect your private keys from falling into the hands of malicious actors.
• Time stamp code: Time stamping your code ensures that software remains trusted even after the signing certificate expires, because it proves the code was signed while the certificate was valid.
• Test-signing and release-signing differences: As described above, it is important to separate and understand the difference between test-signing and release-signing keys/certificates. Test signing certificates and keys require less security and can be self-signed by a private internal CA. They must also chain to a different root certificate from the released signed product. Best practices include setting up completely different code signing infrastructure for release and pre-release signing. This will allow you to set up proper access controls for your test environment and production code.
• Authenticate code: Code signing does not specifically identify code as safe; it just states who wrote it. As such, the code still needs to be fully authenticated before it can be released to the public. Doing so allows you to make sure that you are not accidentally spreading incorrect or malicious code that could harm customers and damage your reputation. All authentication of code signing activities should be recorded for posterity in case some type of investigation or incident response is required.
• Scan code for malware or viruses before signing: In addition to authenticating that no modifications have been made to your code, it is important to scan it for viruses or other malicious code. Malicious code can often be inserted inadvertently by developers who are reusing or introducing existing code from outside projects. It is much easier to catch and change mistakes before the code is released.
• Limit repeated key use: Reusing private keys to sign code multiple times creates increased risk. If a key is compromised, all code signed with that key marked for that date will be invalid and need to be updated with a new code signing certificate. Keeping a habit of cycling through different keys and certificates will allow you to distribute the risk and will lower the effort and impact when reissuing certificates.
• Revoke compromised certificates: Revocation is one of the most important tasks to ensure the safety of the code. The development organization is responsible for reporting any compromised code, keys, or certificates to their certificate authority so that they can take appropriate actions. In the case of any possible problems, a CA will require the code signing certificate to be revoked. If you time-stamp your code, only code whose revocation date is after the incident will be impacted.

• Monitor and audit signing activity: Without visibility, misuse may go unnoticed until damage occurs. Maintain detailed logs of code signing events, access, approvals, and timestamps. Regular reviews help detect anomalies and support investigations.

• Maintain up-to-date policies and training: Inconsistent practices across teams will weaken security. Formal policies should be used to define key management, workflows, approvals, automation standards, and incident handling. Ongoing training ensures teams stay aligned as threats evolve.

How do you implement code signing?

To implement code signing, a unique cryptographic key pair is required. This consists of a private key, which is kept secret, and a public key, which can be shared. Together, they form the foundation of public key cryptography and allow software to be signed without exposing the private key.

After generating the new key pair using public key infrastructure (PKI), the public key is sent to a certificate authority (CA) as part of a certificate signing request (CSR). The CA verifies the identity of the developer or organization and issues the code signing certificate.

Now that the developer is in possession of the certificate, they must hash the software’s code. Hashing is a procedure in which a hash function is used to convert code into an arbitrary fixed value. The output of hashing, called a digest, is then encrypted using the private key. Next, the developer combines this digest with the code signing certificate and the hash function to create something called a signature block, which is essentially all of the above items combined into a piece of code that can be conveniently inserted into the software.

Importance of protection

The biggest issue with code signing is the protection of the private code signing key associated with the certificate. If a key is compromised, the certificate loses trust and value, jeopardizing the software that you have signed.

Many organizations protect themselves using secure vaults and Hardware Security Modules (HSMs) to increase the degree of security their private keys get. Others use certificate management platforms made to automate and secure the lifecycle management of all code signing certificates. An example of one is the Sectigo Certificate Manager. The use of a certificate manager goes a long way towards promoting the integrity of private keys and other encryption assets.

What does code signing prevent?

Simply, code signing helps prevent malware and other malicious code from being introduced to an end-user's system under the disguise of a benign file or event such as a Windows update. It accomplishes this by allowing users to authenticate that the file being downloaded does come from the originator rather than a malicious actor. This reinforces the concept of trust within the system, allowing developers to assure the end-users downloading the software that the source can be trusted and is safe.

EV Code Signing Certificates offer additional assurances of security. They require that the key be stored in a high assurance, FIPS 140-2 or above standard-compliant hardware. There are USB tokens that meet this requirement and add another layer of protection with a PIN. Alternatively, you could store the key(s) in your organization’s HSM on-premises.

Research from Georgia Tech’s Cyber Forensics Innovation Lab shows that issuance and use of Extended Validation (EV) SSL/TLS certificates results in 99.99% likelihood to be free of phishing attacks and abuse. The white paper, which was sponsored by Sectigo, can be downloaded here.

Secure your software with trusted code signing solutions from Sectigo

Following these code signing best practices greatly reduces the risk of unauthorized software distribution, security warnings during installation, and loss of user trust. It can also lead to higher installation rates and smoother adoption of your software. 

Certificates issued by trusted authorities are widely recognized by operating systems and security platforms. Sectigo is a leading Certificate Authority offering fast, flexible code signing solutions. Our code signing certificates help publishers establish trust, protect users from tampered code, and ship software faster. Learn about the different types of code signing certificates that Sectigo offers, or reach out to our expert team for further information.