Code Signing Strategy: A Supply Chain Decision, Not an IT Task

In the SolarWinds attack, the compromised Orion update was digitally signed with SolarWinds' own code signing certificate and shipped to roughly 18,000 customers as part of a routine software update. The signature was valid. The code was malicious. Over 30,000 public and private organisations — including U.S. government agencies, Fortune 500 companies, and critical infrastructure operators — were exposed.

The code signing process wasn't technically broken. SolarWinds' certificate was legitimate, the signing operation completed correctly, and the resulting binary passed signature verification on every customer system. What broke was everything upstream of the signing ceremony: the build pipeline was compromised, malicious code was injected before signing, and nobody caught it. The signature became a weapon because it transferred trust from SolarWinds to every customer who relied on it.

Code signing is fundamentally different from TLS. A compromised TLS certificate exposes traffic between two endpoints. A compromised code signing key — or a compromised build pipeline that feeds legitimate signing — exposes every customer, every partner, and every system that runs your software. The blast radius is not comparable.

Yet most organisations manage code signing certificates with the same processes, the same tooling, and the same governance as their web-facing TLS certificates. That's a strategic miscalibration.

Key Protection Architecture

The code signing private key is the crown jewel. Everything in your code signing strategy — governance, process, audit — exists to protect this key and ensure it's only used to sign code you've actually authorised.

HSM-based signing is the baseline for any organisation with production software. Hardware Security Modules store the private key in tamper-resistant hardware, ensuring the key never exists in extractable form. Signing operations are performed within the HSM. The key can be used but not copied, which means a compromised build server can potentially trigger signing operations but can't steal the key for use elsewhere.

Cloud KMS services (AWS CloudHSM, Azure Key Vault with HSM backing, Google Cloud HSM) provide HSM-grade protection without on-premises hardware. For CI/CD pipeline integration, cloud KMS is increasingly the default choice because the signing operation can be invoked via API from the pipeline while the key remains in the HSM.

Local keystore signing — where the private key lives on a developer's workstation, a build server's file system, or a USB drive — is where most code signing compromises originate. DigiCert has publicly documented common failures they've seen: keys loaded on thumb drives with no access controls, signing credentials shared across teams, keys stored in source control repositories. If your signing key is extractable and accessible to anyone beyond a tightly controlled set of authorised signers, your code signing provides a false sense of security.

The decision matrix for key protection depends on your risk tolerance and operational requirements. For organisations that distribute software to external customers — particularly if that software runs with elevated privileges or handles sensitive data — HSM-based signing is non-negotiable. For internal tools and scripts with limited distribution, cloud KMS provides a proportionate level of protection. Local keystore signing should be limited to development and testing, never production releases.

CI/CD Integration Without Key Exposure

The operational challenge of code signing is that signing must happen in the build pipeline (for automation and reproducibility) but the signing key must not be accessible to the pipeline (because pipelines are attack surfaces).

The architecture that resolves this tension uses a signing service — an intermediary that holds the signing key (or, more precisely, has access to the HSM that holds the key) and exposes a signing API. The CI/CD pipeline submits a hash of the binary to the signing service. The signing service authenticates the request (typically via service identity, short-lived tokens, or mTLS), verifies it against policy (is this pipeline authorised to sign this artifact type?), performs the signing operation in the HSM, and returns the signature.

At no point does the pipeline have access to the private key. The pipeline doesn't even need to know which HSM or key is being used — the signing service makes that decision based on policy.

Commercial signing service platforms include DigiCert Software Trust Manager, Venafi CodeSign Protect, and Keyfactor SignServer. Open-source options include SignServer (community edition) and Sigstore for container image and artifact signing. For Kubernetes-native workflows, Sigstore's Cosign tool is becoming the standard for container image signing, with keyless signing using ephemeral certificates from Fulcio.

The Sigstore ecosystem deserves particular attention. Rather than managing long-lived signing keys, Sigstore issues short-lived certificates tied to an OIDC identity (such as a CI/CD pipeline's service account). The certificate is valid only for the duration of the signing operation, and the signature is recorded in a transparency log (Rekor). This approach eliminates long-term key management entirely for certain use cases, at the cost of depending on Sigstore's infrastructure.

Third-Party Publisher Governance

When partners, contractors, or acquired companies sign software on your behalf — or when you distribute software that includes components signed by others — the governance model extends beyond your own key management.

For software you distribute that includes third-party signed components: verify the signing certificates of your dependencies. Software composition analysis (SCA) tools increasingly validate not just the presence of signatures but the trustworthiness of signing certificates. A signed dependency with a compromised or untrusted certificate is worse than an unsigned dependency because it provides false assurance.

For partners or contractors who sign software under your brand: the signing key and certificate should be under your control, not theirs. The signing service architecture described above supports this — your partners submit binaries for signing through an authenticated API, and the actual key never leaves your infrastructure. If partners must hold their own signing keys (for operational reasons), define certificate policies that constrain what they can sign, enforce short key lifetimes, and require regular attestation of key management practices.

Timestamping, Revocation, and Long-Term Validity

Code signing has a unique relationship with time that distinguishes it from all other certificate use cases.

A TLS certificate is validated at connection time. If the certificate has expired, the connection fails. Simple. A code signing certificate is validated when the signed software is installed or executed — which may be months or years after signing. If the signing certificate has expired by then, should the signature still be valid?

Timestamping resolves this. When you sign code, a timestamp authority (TSA) countersigns the operation with a trusted timestamp. This proves the code was signed while the certificate was valid, even if the certificate has since expired. Without timestamping, signed code becomes untrusted when the signing certificate expires — forcing you to re-sign all previously released software with a new certificate.

Timestamping is also critical for revocation scenarios. If a signing certificate is revoked but the revocation date is after the timestamp, the signature remains valid — the code was signed before the compromise. If the revocation date is before the timestamp (or there is no timestamp), the signature is invalidated. This is why revocation strategy matters for code signing in ways it doesn't for web TLS: revoking a code signing certificate can retroactively invalidate every piece of software signed with it, unless timestamps prove the signing predated the compromise.

The operational implications: timestamp every signature, use a reliable TSA, and maintain timestamp records as part of your software release audit trail. These are not optional practices for production software.

Building a Code Signing Governance Framework

A code signing strategy at the enterprise level addresses five dimensions.

Key lifecycle management. Define key generation procedures (HSM-based, with documented key ceremonies for production signing keys), rotation schedules (annual for production keys, with overlap periods for re-signing), and decommissioning processes (key destruction after transition, with timestamp-based validity preservation for previously signed software).

Signing authorisation. Define who and what can trigger a signing operation. Not every build should be signed with a production key. Development builds use development certificates. Staging builds use a separate signing identity. Only release builds, after passing defined quality and security gates, are signed with production certificates. The signing service enforces this policy.

Audit and compliance. Every signing operation should produce an audit record: what was signed, by whom (or which pipeline), when, with which key, and the associated build metadata. This audit trail is essential for incident response (determining what was signed with a potentially compromised key) and regulatory compliance.

Incident response. Document the procedure for a suspected key compromise: how to assess scope (what was signed with the affected key since the suspected compromise date), how to revoke the certificate, how to re-sign affected software, and how to communicate to customers and partners. Rehearse this procedure — a key compromise is not the time to figure out your revocation process.

Supply chain verification. Validate the signatures and signing certificates of your software dependencies. Integrate signature verification into your build pipeline and deployment process. A signed artifact from an untrusted or compromised certificate should fail your build.

Sector guide: Manufacturing — firmware signing & secure boot.

---

← Back to Certificate Strategy: The Framework Most Organisations Skip

Related guide: Matter device attestation & certificates.

External References

• SolarWinds Attack Analysis — CISA Advisory AA20-352A
• DigiCert: Code Signing Best Practices After SolarWinds — digicert.com
• Sigstore: Keyless Signing for Software Artifacts — sigstore.dev
• Keyfactor: X.509 Certificates in the SolarWinds Attack — keyfactor.com
• NIST SSDF: Secure Software Development Framework — nist.gov
• U.S. GAO: SolarWinds Cyberattack Response — gao.gov