Skip to main content
Application Security Standards
Category: Software Supply Chain

Code Signing

Simply put

Code signing is the process of applying a digital signature to software, scripts, or executable files to confirm who created them and to verify that the code has not been tampered with since it was signed. It helps users and operating systems trust that downloaded software is authentic and unmodified. Without code signing, systems may display security warnings or block the software from running.

Formal definition

Code signing is a cryptographic process in which a developer or publisher uses a private key, associated with a digital certificate issued by a certificate authority, to generate a digital signature over software binaries, scripts, executables, or firmware. The signature enables recipients to verify both the identity of the signer and the integrity of the signed artifact, confirming that the code has not been altered after signing. Code signing typically relies on public key infrastructure (PKI) and may incorporate trusted timestamps, which record the time of signing so that signatures can remain valid even after a signing certificate expires. In cases where a certificate is revoked (for example, due to key compromise), the handling of previously signed artifacts varies by ecosystem: some platforms, such as Windows Authenticode, may continue to trust signatures that include a trusted timestamp applied before the revocation date, while others may treat all signatures from that certificate as untrustworthy. Code signing does not attest to the safety or quality of the signed code itself; it only validates authorship and integrity.

Why it matters

Code signing serves as a foundational trust mechanism in the software supply chain. When users download software, operating systems and security tools rely on digital signatures to verify that the code was published by a known entity and has not been modified in transit or at rest. Without code signing, platforms typically display security warnings or outright block execution, eroding user confidence and complicating software distribution. For organizations distributing software at scale, unsigned code can be flagged as potentially malicious by endpoint protection systems, creating friction for legitimate deployments.

The importance of code signing becomes especially clear when signing keys or certificates are compromised. If an attacker gains access to a legitimate publisher's private signing key, they can sign malicious code that appears authentic to end users and operating systems. This makes private key protection, including the use of hardware security modules and strict access controls, critical to maintaining the integrity of the signing process. It is worth noting that code signing does not make any claims about whether the signed code is safe or free of vulnerabilities; it only validates the identity of the signer and confirms that the artifact has not been tampered with since signing.

For software supply chain security, code signing provides a verifiable chain of custody from publisher to consumer. It allows downstream consumers, whether individual users, automated build pipelines, or enterprise IT teams, to enforce policies that accept only signed and verified artifacts. This capability is increasingly important as software composition grows more complex, with dependencies sourced from numerous external publishers and package registries.

Who it's relevant to

Software Developers and Publishers
Developers who distribute applications, libraries, scripts, or firmware need to sign their artifacts to ensure that end users and operating systems recognize the software as authentic. Code signing is typically required for distribution through platform-specific app stores and is necessary to avoid security warnings on major operating systems.
Application Security Engineers
Security engineers are responsible for designing and enforcing code signing policies within their organizations. This includes managing signing certificates, securing private keys (often via hardware security modules), integrating signing into CI/CD pipelines, and defining verification requirements for incoming third-party software.
DevOps and Release Engineering Teams
Teams responsible for build and release pipelines must integrate code signing into automated workflows to ensure every published artifact is signed before distribution. They also need to manage certificate lifecycles, handle key rotation, and ensure that trusted timestamps are applied during the signing process.
Enterprise IT and Procurement Teams
Organizations that deploy third-party software need to verify code signatures as part of their intake and deployment processes. Signature verification helps ensure that software has not been tampered with and that it originates from its claimed publisher, reducing the risk of deploying compromised artifacts.
Open Source Maintainers and Package Registry Operators
Maintainers of open source projects and operators of package registries increasingly adopt code signing to provide downstream consumers with a verifiable guarantee of artifact authenticity and integrity. Signing packages helps users distinguish legitimate releases from potentially malicious ones.

Inside Code Signing

Digital Signature
A cryptographic hash of the code artifact that is encrypted with the signer's private key, allowing recipients to verify both the identity of the signer and the integrity of the code since it was signed.
Code Signing Certificate
An X.509 certificate issued by a Certificate Authority (CA) that binds a public key to the identity of the software publisher, enabling verifiers to establish trust in the signer's identity.
Private Key
The secret cryptographic key used to generate signatures. Its security is foundational to the trustworthiness of all signatures produced with it, and it is typically protected in a Hardware Security Module (HSM) or equivalent secure storage.
Timestamp
A countersignature from a trusted Timestamp Authority (TSA) that records the time at which the code was signed. This allows the signature to remain valid after the signing certificate expires, and in many ecosystems, preserves validity for signatures made before a certificate was revoked.
Certificate Chain
The chain of trust from the code signing certificate through intermediate certificates up to a trusted root CA. Verifiers walk this chain to confirm that the signing certificate was issued by a trusted authority.
Revocation Information
Mechanisms such as Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP) that allow verifiers to check whether a signing certificate has been revoked due to compromise or other reasons.

Common questions

Answers to the questions practitioners most commonly ask about Code Signing.

Does code signing guarantee that software is safe or free of malware?
No. Code signing verifies the identity of the signer and confirms that the code has not been altered since signing. It provides authenticity and integrity assurance but makes no claim about the safety, quality, or intent of the signed code. Malware authors who obtain or compromise valid signing certificates can produce validly signed malicious software. Code signing should be treated as one layer in a defense-in-depth strategy, not as a sole indicator of trustworthiness.
If a code signing certificate is revoked, are all signatures ever made with that certificate automatically invalid?
Not necessarily. The effect of revocation depends on the ecosystem and whether a trusted timestamp was applied at the time of signing. In many ecosystems, such as Windows Authenticode, signatures that include a trusted timestamp made before the revocation date typically continue to be treated as valid, because the timestamp proves the signature was created while the certificate was still in good standing. However, any signature made after the revocation, or any signature lacking a trusted timestamp, should generally be treated as untrustworthy. Organizations should understand the specific revocation and timestamping policies of the platforms they target.
How should private signing keys be stored and protected in a code signing workflow?
Private signing keys should be stored in hardware security modules (HSMs) or equivalent tamper-resistant key storage, rather than on general-purpose developer workstations or build servers. Access to signing operations should be restricted through role-based access controls, requiring multi-party authorization where practical. Audit logging of all signing events is recommended so that unauthorized or anomalous signing activity can be detected. Cloud-based key management services offered by certificate authorities or cloud providers can provide HSM-backed storage with centralized access policies.
Why is timestamping important when signing code, and what happens without it?
A trusted timestamp, applied during the signing process by a third-party timestamp authority, records the exact time the signature was created. Without a timestamp, the signature's validity is typically tied to the certificate's validity period, meaning the signature may be treated as invalid once the certificate expires or is revoked, regardless of when the signing actually occurred. With a trusted timestamp, verifiers can confirm that the signature was made while the certificate was valid, allowing the signature to remain trusted beyond the certificate's expiration or, in many ecosystems, even after revocation, as long as the signing occurred before the revocation date.
How should code signing be integrated into a CI/CD pipeline?
Signing should typically occur as a discrete, controlled step within the build pipeline, after the build artifacts are produced and ideally after automated tests and security checks have passed. The pipeline should authenticate to a centralized signing service rather than having direct access to private keys. Signing credentials should not be embedded in source repositories or build scripts. Access to the signing step should be gated so that only authorized pipeline configurations or approved personnel can trigger it. All signing operations should be logged for auditability, and the resulting signatures should be verified as a post-signing validation step before distribution.
What should an organization do if it suspects its code signing key has been compromised?
The organization should immediately request revocation of the associated certificate from the issuing certificate authority. It should then audit signing logs to identify any signatures that may have been made by the unauthorized party after the compromise. Affected software artifacts should be re-signed with a new certificate and redistributed where possible, and downstream consumers should be notified. Because pre-compromise signatures with trusted timestamps may still be treated as valid in some ecosystems, the organization should assess whether any pre-compromise artifacts also need to be re-signed based on the timeline of the suspected breach. A root cause analysis should be conducted to determine how the compromise occurred, and key management practices should be strengthened accordingly.

Common misconceptions

Code signing guarantees that the signed software is free of vulnerabilities or malware.
Code signing verifies the identity of the publisher and the integrity of the code since it was signed. It does not analyze the code for security flaws, malicious logic, or vulnerabilities. Malware authors can and do obtain legitimate code signing certificates.
Once a code signing certificate is revoked, all signatures ever made with that certificate become untrustworthy.
The effect of revocation depends on the ecosystem and whether a trusted timestamp was applied. In many ecosystems (for example, Windows Authenticode), signatures that include a trusted timestamp dated before the revocation remain valid, because the timestamp proves the signature was created while the certificate was still in good standing. Signatures made after the revocation date, or those lacking a trusted timestamp, are typically treated as untrustworthy.
Storing the private key in a software keystore on a build server is sufficient protection.
Software-based keystores are vulnerable to extraction through host compromise, insider threats, or misconfigured access controls. Best practice is to store code signing private keys in Hardware Security Modules (HSMs) or equivalent tamper-resistant hardware, combined with strict access controls and audit logging, to reduce the risk of key theft.

Best practices

Store code signing private keys in Hardware Security Modules (HSMs) or cloud-based HSM services rather than in software keystores, and enforce multi-party or quorum-based access controls for signing operations.
Always apply a trusted timestamp from a reputable Timestamp Authority (TSA) to every signature, ensuring that signatures remain verifiable after certificate expiration and preserving validity for pre-revocation signatures in ecosystems that support this.
Integrate code signing into the CI/CD pipeline as an automated step with strict access controls, audit logging, and separation of duties so that developers cannot sign arbitrary artifacts outside the approved workflow.
Rotate code signing certificates on a defined schedule and have a documented incident response plan for certificate revocation in case of suspected private key compromise, including procedures for re-signing affected artifacts.
Enforce signature verification at every consumption point, including package managers, deployment pipelines, and end-user installation, rather than relying solely on the signing step to provide security.
Scope signing certificates narrowly by using distinct certificates for different products, environments (such as test versus production), or teams, so that a compromise of one certificate limits the blast radius.