Code Signing 101: Locking Down Your Software Supply Chain

Every time you download a software update, install a browser extension, or run an enterprise application, you’re placing a profound level of trust in that software. But how do you actually know it hasn’t been tampered with— that it came from the vendor it claims to come from, and not an attacker? The answer is code signing. 

As security leaders, organizations have spent years strengthening application security, cloud controls, and identity. But one of the most overlooked trust anchors in the software lifecycle is still code signing. Many still face the same issue: they invest heavily in secure development, yet leave the final release process fragmented, manual, and difficult to govern.  

The increasing prevalence of cyberattacks targeting software vulnerabilities necessitates robust mechanisms to ensure the authenticity and security of software code. By implementing code signing, developers can establish trust with users, assuring them that the software they install is legitimate and malware-free. And as the industry matures, emerging practices — like keyless signing (where short-lived certificates replace long-lived private keys, eliminating the need for key management altogether) and Software Bill of Materials (SBOM) integration (which provides a machine-readable inventory of every component in a software artifact) — are reshaping what a comprehensive signing strategy looks like. To understand its critical role, it is essential to examine the intricate processes involved, including those related to transparency, validity, and security. 

What Is Code Signing, and Why Does It Matter? 

At its core, code signing is the process of applying a digital signature to software — whether that’s an executable, a script, a driver, a firmware image, or a container. This signature serves two essential purposes: 

1. Authentication — It proves who created or published the software. 
2. Integrity — It guarantees that the code hasn’t been altered since it was signed. 

In 2025, according to the same CleanStart report, 35% of supply chain attacks originated through compromised software dependencies, 22% targeted CI/CD pipelines and build environments, and 20% involved poisoned or unverified container images. They also found that software supply chain attacks more than doubled globally during 2025, with global losses reaching $60 billion and over 70% of organizations reporting at least one supply chain-related security incident that year. What makes these numbers particularly alarming is that attackers are no longer targeting the perimeter — they’re entering through the build process itself.  

When you sign code, it’s important to know that the signature is only valid for as long as the signing certificate is valid. But software often outlives its certificate. A trusted timestamp, issued by an RFC 3161-compliant Timestamp Authority (TSA) at the moment of signing, cryptographically binds the signature to a specific point in time. This means that even after the signing certificate expires, the signature remains valid — because the timestamp proves the signing occurred while the certificate was still active. Without timestamping, your entire signed release could become untrusted the moment your certificate expires. 

Another concept to understand is that if a signing key is compromised, the corresponding certificate must be revoked immediately. Certificate Revocation Lists (CRLs) are periodically published lists of revoked certificates. Online Certificate Status Protocol (OCSP) provides real-time, per-certificate revocation checks. Operating systems and security tools query these mechanisms to verify that a certificate hasn’t been revoked before trusting a signature. A robust code signing program must include a tested revocation plan — not just the ability to revoke, but also a documented process for revoking, re-signing, and quickly redistributing affected artifacts. 

Platform enforcement adds another layer of trust validation. On Windows, SmartScreen evaluates the reputation of signed executables — EV-signed software with established reputation bypasses the ‘Unknown Publisher’ warning that can deter users and erode trust. On macOS, Gatekeeper checks that applications are signed with an Apple-issued Developer ID certificate and have passed notarization — Apple’s automated malware scan. On Linux, package managers like apt and dnf verify GPG signatures on packages before installation. Understanding these platform-level controls helps security teams design signing workflows that result in frictionless, trusted software delivery. 

Without code signing, users and systems have no reliable way to distinguish legitimate software from a malicious lookalike. But one should also understand that code signing does not guarantee that software is secure, benign, or free of vulnerabilities. A valid signature proves integrity and origin, not quality or intent. If a signing key is compromised, or if flawed code is signed by a legitimate publisher, the signature may still validate successfully. For decision-makers, this distinction is essential: code signing is a necessary control, but it must operate alongside secure development, pipeline hardening, access control, and monitoring. 

In early 2025, cybercriminals were caught abusing Microsoft’s Trusted Signing service to sign malware with short-lived, three-day certificates — making malicious payloads appear fully trusted and bypassing traditional security controls. The certificates were technically valid and verified correctly; the problem wasn’t the infrastructure; it was that attackers had gained access to it. This is a precise illustration of code signing’s core limitation: a valid signature proves that someone with signing access produced the software — not that the software is safe. Signing infrastructure must be hardened, access tightly controlled, and anomalous signing activity detected in near-real-time, because when the signing pipeline is compromised, the signature becomes the attacker’s most powerful weapon. 

The Cryptographic Foundation 

To truly understand code signing, you need a basic grasp of Public Key Infrastructure (PKI) and asymmetric cryptography. 

Asymmetric Key Pairs 

Every code signing identity is built on a key pair: 

• A private key — kept secret by the software publisher. This is used to create the signature. 
• A public key — shared openly. This is used to verify the signature. 

The mathematical relationship between these two keys is one-way: you can sign with the private key and verify with the public key, but you cannot derive the private key from the public key. The choice of algorithm matters significantly. The three algorithms most widely used in code signing today are: 

RSA (Rivest–Shamir–Adleman) — The most established algorithm, typically used with 2048-bit or 4096-bit keys. RSA is universally supported across operating systems and tools, but its larger key sizes make it slower than modern alternatives at equivalent security levels. 

ECDSA (Elliptic Curve Digital Signature Algorithm) — Uses elliptic curve mathematics to achieve equivalent security to RSA with significantly smaller key sizes. A 256-bit ECDSA key (P-256) provides roughly the same security as a 3072-bit RSA key, with faster signature generation and verification. ECDSA is increasingly preferred in performance-sensitive, resource-constrained environments. 

EdDSA (Edwards-curve Digital Signature Algorithm) — The newest of the three, based on twisted Edwards curves (most commonly Ed25519). EdDSA offers excellent performance, strong security properties, and is resistant to certain side-channel attacks that can affect ECDSA implementations.  

The Signing Process  

1. Hashing: The software publisher runs the code through a cryptographic hash function — SHA-256 at minimum, as SHA-1 is cryptographically broken and deprecated by NIST since 2011 (and banned in code signing by major CAs since 2016). SHA-256 produces a fixed-length “fingerprint” of the code — called a digest. Even a single changed bit in the code produces a completely different hash. 
2. Signing the Hash: The publisher encrypts the hash using their private key. This encrypted hash is the digital signature. 
3. Attaching the Signature: The signature, along with the publisher’s certificate (which contains the public key), is bundled with the software. 

The Verification Process 

When a user downloads and runs the software, the operating system or security tool: 

1. Extracts the signature and certificate from the file. 
2. Validates the certificate chain by checking that the certificate was issued by a trusted CA, that it hasn’t expired, and that it hasn’t been revoked (via CRL or OCSP). 
3. Validates the timestamp, i.e., confirming that the signature was applied while the certificate was active, ensuring the signature remains valid even after certificate expiry. 
4. Uses the public key in the certificate to decrypt the signature, recovering the original hash. 
5. Independently hashes the downloaded software. 
6. Compares the two hashes. If they match, the software is intact and genuinely from the claimed publisher. If they don’t — verification fails! The software has been modified 

The Role of Certificate Authorities (CAs) 

Now it is critical to know and understand what is stopping a malicious actor from simply creating their own key pair and claiming to be Microsoft or Adobe? 

This is where Certificate Authorities (CAs) come in. A CA is a trusted third party (like DigiCert, Sectigo, or GlobalSign) that issues code-signing certificates only after verifying the applicant’s identity. The CA’s signature on the certificate is what gives it legitimacy. But the trust infrastructure goes deeper than a single CA. 

Root CA vs. Intermediate CA Hierarchy 

The PKI trust model is hierarchical. At the top sits the Root CA — a highly secured, often offline entity whose certificate is self-signed and whose public key is embedded directly into operating systems and browsers by vendors like Microsoft, Apple, and Mozilla. Because compromising a Root CA would be catastrophic, root private keys are kept in air-gapped HSMs and rarely used for direct certificate issuance. 

Instead, Root CAs issue certificates to Intermediate CAs (also called Subordinate CAs), which are online and perform the day-to-day work of issuing code signing certificates to publishers. This creates a chain of trust: Root CA → Intermediate CA → Publisher Certificate. When verifying a signature, the system walks this chain, verifying each certificate’s signature against its parent, all the way back to a trusted root. 

Trust Stores 

Your operating system ships with a pre-installed trust store — a curated list of trusted Root CA certificates. Windows maintains the Microsoft Trusted Root Certificate Program, macOS and iOS maintain Apple’s trust store, and Linux distributions rely on the ca-certificates package (often sourced from Mozilla’s program). Browsers like Chrome and Firefox may maintain their own trust stores independently of the OS. When a code signing certificate chains back to a root in the trust store, the signature is considered trusted. If the chain cannot be validated back to a trusted root, the signature is rejected. 

Extended Validation (EV) Code Signing Certificates 

Not all code signing certificates are equal. Standard OV (Organization Validation) certificates require the CA to verify that the applicant’s organization legally exists, but the vetting is relatively lightweight. EV (Extended Validation) certificates require a significantly more rigorous process: 

• Legal existence verification — the organization must be a registered legal entity in good standing with its jurisdiction. 

• Physical address and operational existence — the CA verifies the organization’s physical location and operational presence. 

• Identity of the certificate requester — the individual requesting the certificate must be verified as an authorized representative of the organization. 

• Phone verification — the CA contacts the organization through an independently verified phone number to confirm the request. 

• Anti-money-laundering and sanctions screening — the organization and its principals are checked against government and regulatory watchlists. 

The result is a certificate that carries a much stronger identity assurance. On Windows, EV-signed software immediately builds SmartScreen reputation — bypassing the ‘Unknown Publisher’ warning — because Microsoft has higher confidence in the verified identity behind the certificate. EV certificates also require private keys to be stored in a hardware security module (HSM), which significantly raises the bar for key theft compared to OV certificates, which can be stored in software. 

Self-Signed Certificates — Certificates generated internally, without a CA, are perfectly fine for internal testing environments where you control both ends of the trust equation. But they should never be used for publicly distributed software. There’s no chain of trust; end-user systems won’t recognize them as legitimate, and they offer no guarantee of the publisher’s identity. 

The Software Supply Chain 

So far, we’ve talked about signing a single piece of software. But modern software development is vastly more complex. Your product likely includes: 

• Open-source libraries and packages (npm, PyPI, Maven, NuGet, etc.) 
• Third-party SDKs and components 
• CI/CD pipeline artifacts 
• Container images 
• Infrastructure-as-code scripts 
• Firmware and drivers 
• Software Bill of Materials (SBOM) 
• Container images and Docker artifacts 

Each of these represents a potential entry point for a supply chain attack, and signing strategies must cover all of them, not just final executables. Container images should be signed using tools like cosign and verified at deployment time. Artifact signing for build outputs (JARs, wheels) ensures that what comes out of the build system matches what was built. SBOM signing adds a layer of attestation to the inventory itself, allowing downstream consumers to verify not just the software, but the complete list of its ingredients. 

• Ecosystem Complexity

  The open-source ecosystem is under more intense scrutiny than ever, and for good reason. The sheer scale of dependency on third-party packages creates an enormous attack surface. Most enterprise applications pull in hundreds or thousands of transitive dependencies (packages that depend on other packages), many of which are maintained by individuals with limited security resources.

  Sonatype’s quarterly Open-Source Malware Index tracked a relentless escalation throughout 2025: Q1 saw nearly 18,000 new malicious packages discovered, Q3 logged 34,319, a 140% increase from Q2, and by Q4 2025, Sonatype had identified a staggering 394,877 new open-source malware packages in a single quarter, driven largely by automated, self-replicating campaigns. Sonatype’s cumulative total of malicious packages identified since 2019 has surpassed 877,000.

• Threat Escalation

  More troublingly, 56% of malware discovered in Q1 2025 was built for data exfiltration, primarily targeting developer credentials, CI/CD secrets, and cloud API keys stored in predictable locations on developer machines. That data, once harvested, becomes the key to compromising an entire signing pipeline. An attacker with access to a CI/CD secret or developer credential can potentially inject malicious code into the build process, sign it with a legitimate key, and distribute it through official channels, all without ever touching the target organization’s perimeter.

Hence, a comprehensive code signing strategy must cover the entire chain from the open-source packages you consume to the artifacts you produce and distribute. 

The SLSA Framework 

The Supply Chain Levels for Software Artifacts (SLSA) framework, developed by Google, provides a tiered model for evaluating and improving supply chain integrity. It ranges from Level 1 (basic documentation) to Level 4 (the most rigorous controls). Code signing is a critical component of achieving higher SLSA levels. Here’s what each level means in practice: 

SLSA Level 1: The build process is documented and scripted. Source information and metadata about how the artifacts were built are available but not authenticated. This establishes a baseline of traceability. 

SLSA Level 2: The build runs on a hosted build service (not just a developer’s laptop), and the source is signed by the build service. This means an attacker would need to compromise the build service, not just a developer machine, to forge provenance. 

SLSA Level 3: The build service provides stronger isolation guarantees, and the origin data includes information about the build environment. Source code must come from a version control system, and the build must be secured and protected. 

SLSA Level 4: Requires a two-person review of all changes, with reproducible build, and comprehensive information of the source. At this level, the entire chain from source to artifact is tamper-evident and auditable. 

One of the most important and most challenging aspects of modern code signing is integrating it into automated build pipelines. This is where many organizations stumble. As per a 2025 study, fewer than 50% of enterprises currently monitor more than 50% of their extended software supply chain, meaning attackers routinely operate in blind spots that organizations don’t even know exist. 

Common pitfalls include: 

• Storing private keys in environment variables or config files — This is a critical mistake. Private keys stored in plain text in a CI/CD environment are one misconfigured access control away from total compromise.  
• Sharing signing credentials across teams — If all the teams in your organization use the same signing key, a single compromised developer account could lead to maliciously signed releases. 
• Signing at the wrong stage — Signing too early in the pipeline means you’re signing untested code. Signing too late can introduce gaps that allow unsigned artifacts to travel across systems. 
• No key rotation strategy — Signing keys should be rotated periodically (at a minimum annually and immediately following any suspected compromise). Many organizations set up signing infrastructure and never revisit it, leaving keys that are years old and potentially exposed. 
• No separation of duties — Separation of duties ensures that a compromised developer account cannot unilaterally sign and publish malicious code. For instance, the developer who writes the code should not be the same person who signs and releases it without review from another developer. 
• Lack of signing policy enforcement — Without enforced policies, signing becomes ad hoc. Teams may sign with the wrong certificates, skip timestamping, or sign at the wrong build stage. Centralized signing platforms such as our CodeSign Secure enforce policies programmatically and allow users to control their signing processes and environments. 
• No audit log correlation — Signing events should be logged, and those logs should be correlated with build system events. An unexpected signing event outside of a normal build pipeline is a strong signal of compromise. 

Now you might be thinking, ” Why CISOs, DevSecOps Leaders, and Security Executives should care about implementing Code Signing in their pipelines?” The modern software supply chain extends far beyond source code. It includes build systems, CI/CD pipelines, artifact repositories, package managers, update channels, certificates, and the infrastructure used to deliver software to customers and employees. This scope is precisely why code signing has become a focus of major regulatory and policy frameworks:  

• NIST SSDF (SP 800-218): The Secure Software Development Framework explicitly requires verifying the integrity of software components, protecting signing keys, and implementing processes to detect tampering in the build pipeline. It maps directly to code signing as a control. 
• CISA Secure by Design: CISA’s guidance pushes software manufacturers to take ownership of security outcomes, including ensuring that software delivered to customers can be verified as authentic and unmodified. Code signing is a core mechanism for this verifiable delivery. 
• Executive Order 14028 (Improving the Nation’s Cybersecurity): Signed in May 2021, EO 14028 mandated that federal agencies and their software suppliers meet specific software supply chain security requirements, including SBOM generation, secure build environments, and artifact integrity verification. This order effectively made supply chain security and code signing a compliance requirement for any organization doing business with the U.S. federal government. 

When attackers cannot break the application directly, they often target the pipeline that produces or distributes it. That makes code signing a strategic control, not a tactical afterthought. It gives platforms, security tools, and end users a way to verify that software came from the expected publisher and was not modified after release. In executive terms, code signing helps reduce the risk of tampered software, malicious updates, and trust breakdowns in the release pipeline. It supports both security outcomes and operational credibility. 

When including Code Signing in the Supply Chain, organizations and teams must follow the checklist below to keep their environments safe and secure: 

• Use EV certificates for all production-signed, publicly distributed software.
• Always timestamp every signed artifact using a trusted TSA.
• Store private keys in an HSM — never in files, environment variables, or developer machines.
• Integrate signing into CI/CD at the right stage (post-test, pre-release).
• Implement role-based access — not everyone needs signing privileges.
• Log every signing event and monitor for anomalies.
• Track certificate expiry and automate renewal reminders at 90, 60, and 30 days.
• Have a revocation plan — know exactly how to revoke and re-sign if a key is compromised.
• Rotate keys periodically — at minimum annually, and immediately after any suspected compromise or personnel change.
• Use separate signing keys per environment — dev, staging, and production keys should be distinct, limiting blast radius in the event of a compromise.
• Use short-lived signing certificates where possible — especially for keyless signing workflows which eliminate long-lived key management entirely.

Encryption Consulting’s CodeSign Secure 

CodeSign Secure is a centralized, secure, and scalable code signing platform built to help organizations sign code confidently without compromising on security or speed. It is designed for modern DevOps environments, integrating with popular CI/CD pipelines like Azure DevOps, Jenkins, and GitLab, while enforcing strict access controls and approval workflows to keep the signing process clean and compliant. 

Key Features

• HSM-Backed Key Security

  CodeSign Secure leverages a FIPS 140-2 Level 3 HSM for secure key storage, ensuring that private keys are always protected. The platform integrates with various Hardware Security Modules, including Entrust nCipher, Thales Luna, Utimaco, and Securosys, ensuring that cryptographic keys are always stored in a tamper-resistant, secure hardware device, whether you prefer on-premises hardware or cloud HSMs.

• Policy-Driven Access Control

  CodeSign Secure’s access control system integrates with Microsoft Active Directory and Keycloak to register users and allow centralized management of their credentials and permissions. The platform offers a detailed Role-Based Access Control (RBAC) system with customizable workflows to provide granular control over code-signing processes, preventing unauthorized access and minimizing security risks.

  Signing policies are enforced programmatically at the platform level, i.e., that no artifact can be signed unless it meets all pre-defined criteria: the correct certificate type, the correct signing stage, and the required approvals. Separation of duties is enforced through multi-step approval workflows: a developer can initiate a signing request, but release managers or security officers must approve it before the signature is applied. This eliminates the risk of a single compromised account unilaterally signing and releasing software without oversight. Also, audit trails and logs record every approval, denial, and signing event — giving security teams the evidence they need for compliance reporting and incident investigation.

• Seamless CI/CD Integration

  The platform enforces release security checks and integrity validation to prevent unsigned artifacts from reaching production and enables centralized tracking with instant alerts for unauthorized signing attempts. CodeSign Secure is designed to support rapid development cycles and continuous integration/continuous deployment (CI/CD) processes, including Azure DevOps, Jenkins, GitLab, and more.

• Broad Format and Platform Support

  The solution supports signing for various formats, including .exe, .dll, .jar, .apk, .dmg, Docker containers, firmware binaries, and more, ensuring that all software artifacts can be securely signed across multiple OS platforms, including Windows, Linux, and macOS. It integrates seamlessly with our custom PKCS11 Wrapper and many third-party signing tools such as Signtool, Jarsigner, JSign, and many more.

• Client-Side Hashing and Secure Timestamping

  The platform uses client-side hashing, that is, generating the code hash on your machine with the help of a custom Key Storage Provider (KSP) designed to work seamlessly with Microsoft’s Cryptography Next Generation (CNG) framework. Along with secure timestamps, it ensures the integrity and longevity of digital signatures, even after certificate expiration.

• Comprehensive Audit Trails

  The platform provides real-time visibility into all code-signing activities for security and compliance, maintaining detailed event logs and audit trails to track key usage, investigate incidents, and meet compliance requirements. It also provides plugin integration with many SIEM tools such as Grafana, Loki, and Splunk via OpenTelemetry.

• Flexible Deployment Models

  Organizations can leverage a fully managed, cloud-hosted solution with built-in HSM security offering all features via API access or deploy CodeSign Secure on-premises using physical servers while securely managing private keys in cloud HSMs, on-prem HSMs, or both for maximum flexibility.

• Post-Quantum Cryptography (PQC) Support

  CodeSign Secure supports Post-Quantum Cryptography signing, ML-DSA (Multivariate Lattice Digital Signature Algorithm), and LMS (Leighton-Micali Signatures), two NIST-recognized, quantum-resistant signature schemes, directly on the HSM itself. By offloading this process to a PQC-supported HSM, the massive cryptographic keys required are never exposed to the system, staying physically locked within a hardened environment.

  For organizations that need to transition gradually, CodeSign Secure also supports dual signature schemes, for example, using a classical RSA or ECDSA signature with an ML-DSA or LMS signature for different signing requirements. Dual Signing Setup allows different software to be signed by both classical and quantum-capable verification systems as per requirements, accepting forward post-quantum transition.

Whether you’re a growing business, a large enterprise, or operating in highly regulated sectors like automotive, healthcare, or fintech, CodeSign Secure is designed to meet your specific needs. If you’re managing dozens of signing identities across distributed teams, running high-velocity CI/CD pipelines, or operating under strict compliance mandates, CodeSign Secure was built with exactly your challenges in mind. 

Conclusion 

Code signing might seem like a narrow, technical concern, something you configure once and forget. But as the 2025 and 2026 threat data makes painfully clear, it’s one of the most consequential security controls in your arsenal. Software supply chain attacks more than doubled in 2025. Attackers are no longer waiting at the front door; they’re embedded inside the packages your developers download every morning, the CI/CD jobs your pipelines run automatically, and the build artifacts your teams trust without question. Cybersecurity Ventures projects that the global annual cost of these attacks will reach $138 billion by 2031. The question is whether your code signing posture is ready to meet it. 

Whether you’re standing up your first PKI, integrating code signing into a complex multi-cloud CI/CD environment, or trying to achieve compliance with frameworks like SLSA or NIST, Encryption Consulting is here to help you, whether it’s advisory, migration, or integration. The software supply chain is only as strong as its weakest link. Make sure code signing isn’t yours.