Code Signing Security
Practices and infrastructure for digitally signing software artifacts to verify authenticity and integrity throughout the software supply chain.
Continue your mission
Practices and infrastructure for digitally signing software artifacts to verify authenticity and integrity throughout the software supply chain.
# Code Signing Security
Code signing security is the discipline of applying cryptographic signatures to software artifacts so that any system or person receiving that software can verify two facts: the code came from a known, trusted publisher, and the code has not been changed since it was signed. Without this mechanism, software distribution becomes a trust problem with no reliable solution. Attackers can intercept, modify, or wholesale replace software packages in transit or at rest, and recipients have no way to detect the substitution. Code signing closes that gap by binding the publisher's verified identity to the artifact's exact binary content through a mathematical relationship that cannot be forged without access to the private signing key.
---
Code signing security encompasses the cryptographic practices, certificate infrastructure, key management policies, and process controls that together govern how software artifacts are signed and how those signatures are verified throughout the software supply chain.
At its technical core, code signing is an application of asymmetric cryptography. A private key held exclusively by the publisher produces a signature over a hash of the artifact. Any party holding the corresponding public key, typically distributed through a trusted certificate, can verify that signature. The artifact cannot be altered without invalidating the signature, and the signature cannot be forged without access to the private key.
Code signing is not the same as encryption. Encryption protects the confidentiality of data in transit or at rest. Code signing makes no data secret. It asserts authenticity and integrity only. It is also distinct from code review or static analysis, which examine code for vulnerabilities or quality issues. A signed binary can still contain vulnerabilities; the signature only confirms it came from who it claims and has not been altered.
Variants and subtypes include:
Code signing does not guarantee the software is free of malicious intent or vulnerabilities. A malicious actor who obtains a valid signing certificate can sign malware, and that malware will appear signed. Signing confirms identity and integrity, not safety.
---
The process begins with hashing. The signing tool computes a cryptographic hash (commonly SHA-256) of the software artifact, whether that is a Windows executable, a macOS application bundle, a Linux package, a container image, or a firmware binary. This hash is a fixed-length fingerprint of the artifact's exact content. Any change to even a single byte of the artifact produces a completely different hash.
The tool then encrypts that hash using the publisher's private RSA or ECDSA key. The result is the digital signature. This encrypted hash, along with the publisher's X.509 certificate containing the corresponding public key, is embedded into the artifact or distributed alongside it.
When a recipient's system verifies the artifact, the process runs in reverse. The verification tool:
If any part of this chain fails (including an untrusted CA, an expired certificate, a revoked certificate, or a hash mismatch), verification fails and the system alerts the user or blocks execution.
Certificate expiration creates a practical problem. If the signing certificate expires, does that invalidate all signatures created while the certificate was valid? Timestamping solves this. During signing, the tool submits a hash of the signature to a trusted timestamping authority (TSA). The TSA returns a signed timestamp assertion. This timestamp, embedded in the signature, provides cryptographic proof that the signature existed at a specific moment in time, before the certificate expired. Operating systems and verification tools honor valid timestamps even after the signing certificate's expiration date has passed.
Extended Validation certificates require the private key to reside on a hardware token (FIPS 140-2 Level 2 or higher). Signing operations occur on the token; the private key never exists in plaintext on a general-purpose computer. This prevents an attacker who compromises a developer's workstation or a build server from simply exfiltrating the private key. The attacker must physically possess the token and know its PIN.
Modern secure build pipelines sign artifacts automatically as part of CI/CD. A common pattern:
Signing keys are never present in source repositories, environment variables, or developer workstations in this model. Access to the signing service is gated by CI/CD service identity (such as an OIDC token from GitHub Actions or GitLab CI) and audited.
A software company builds an installer package for Windows. The build pipeline calls signtool.exe with the artifact path, specifying the EV certificate stored in Azure Key Vault and the DigiCert timestamping URL. The tool computes the SHA-256 hash of the installer, sends a signing request to Key Vault (the private key never leaves the HSM), receives the signature, embeds it in the PE binary along with the certificate chain and timestamp, and publishes the installer to the company's download page.
A user downloads the installer. Windows verifies the Authenticode signature automatically. Because the certificate chains to a trusted root and the hash matches, Windows Defender SmartScreen shows the publisher's verified name rather than a warning. The timestamp ensures this verification will continue to succeed even after the certificate's two-year validity period ends.
In container environments, tools such as Cosign (from the Sigstore project) sign container images and store signatures in the OCI registry alongside the image. Admission controllers in Kubernetes clusters (such as those implementing the Sigstore Policy Controller) can be configured to reject any image that does not carry a valid signature from a trusted key. This prevents unsigned or tampered images from running in production.
Modern package managers increasingly support signature verification. APT repositories on Debian and Ubuntu use GPG signatures on package indexes and individual packages. RPM packages on Red Hat systems include digital signatures verified during installation. NPM packages can be signed through npm provenance. These mechanisms protect users from mirror compromises and man-in-the-middle attacks during software installation.
---
Organizations that do not enforce code signing expose themselves to software supply chain attacks, where an attacker substitutes a malicious artifact for a legitimate one anywhere in the distribution or update path. The consequences range from malware deployment to full organizational compromise.
Without signature verification on software updates, an attacker who can intercept or alter update traffic (through a compromised CDN, a man-in-the-middle position, or a compromised distribution server) can push arbitrary code to any system that trusts those updates. At scale, this means thousands or millions of endpoints silently receive and execute attacker-controlled code.
The 2020 SolarWinds Orion supply chain attack illustrates what happens when code signing infrastructure itself is compromised. Attackers infiltrated SolarWinds' build environment and injected malicious code (the SUNBURST backdoor) into the Orion software build process before signing occurred. The resulting binaries were legitimately signed with SolarWinds' valid Authenticode certificate. Approximately 18,000 organizations downloaded and installed the signed, malicious update, because the signature was valid. The attack succeeded precisely because recipients trusted the signature without any deeper verification of what the build process had produced.
This incident does not mean code signing is ineffective. It means code signing must be paired with build integrity controls: reproducible builds, binary provenance attestation, and signing of build metadata. Code signing is a necessary control, not a sufficient one.
The 2017 NotPetya attack included components that compromised MEDoc, a Ukrainian accounting software company, and used their legitimate signing infrastructure to distribute malware. The 2017 CCleaner compromise saw attackers insert malicious code into the build process before signing, resulting in a legitimately signed but malicious version distributed to over 2 million users. Both incidents demonstrate that signing infrastructure becomes a high-value target once code signing verification is widely deployed.
A persistent misconception is that a signed binary is a safe binary. Signing confirms origin and integrity, not intent or quality. Attackers regularly obtain legitimate certificates through fraudulent applications to certificate authorities, through theft from compromised developer systems, or by establishing front companies. Signed malware is documented across multiple threat actor groups tracked by MITRE ATT&CK (T1553.002: Subvert Trust Controls: Code Signing).
Another misconception is that self-signed certificates provide equivalent assurance to CA-issued certificates for external distribution. They do not. A self-signed certificate carries no third-party attestation of the publisher's identity. Any attacker can generate a self-signed certificate with any name.
Organizations often assume that code signing prevents all forms of software tampering. It does not protect against attacks that occur after signature verification, such as DLL hijacking, process injection, or runtime modification of signed binaries already loaded into memory.
---
The Center for Digital Autonomy approaches code signing through the Planetary Defense Model (PDM) under the Digital Preservation and Sovereignty (DPS) and Verified Software Distribution (VSD) domains. The guiding methodology is the Sovereign Data Protocol (SDP): your data lives where you decide. Period. This extends to the software artifacts, update packages, and tools that organizations depend on. If you cannot verify what code you are running, you cannot claim sovereignty over your own systems.
CDA treats code signing not as a compliance checkbox but as a foundational control within a broader software supply chain integrity program. The specific operational stance differs from conventional guidance in several ways.
First, CDA emphasizes key custody as an organizational sovereignty question. Relying on a SaaS signing service without contractual guarantees about key access, key deletion, and geographic storage means a third party holds operational control over your ability to ship software. CDA recommends organizations maintain their own HSM infrastructure or use cloud KMS with explicit, documented key policies, customer-managed keys, and audited access logs retained under the organization's control, not the vendor's.
Second, CDA promotes signature transparency through append-only logs. Signing events should be recorded in a tamper-evident audit log (such as those compatible with the Sigstore Rekor transparency log format) that allows independent verification that a given signature was produced at a given time. This creates accountability that prevents insider key misuse from going undetected indefinitely.
Third, CDA advocates for enforced verification, not optional verification. Signing artifacts is only half the control. The distribution channel, the update mechanism, the deployment pipeline, and the endpoint must all be configured to reject unsigned or invalidly signed artifacts. Signing without enforced verification provides no actual security benefit.
Fourth, within VSD domain controls, CDA requires that software provenance attestation accompany signatures wherever feasible. SLSA (Supply-chain Levels for Software Artifacts) framework attestations, combined with code signatures, provide a verifiable link between source code, build environment, and final artifact, addressing the exact attack vector that SolarWinds demonstrated.
---
---
---
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Written by CDA Editorial
Found an issue? Help improve this article.