Code Signing and Its Limits

Code signing is the cryptographic process by which a software vendor attaches a digital signature to a software artifact, using a private key whose corresponding public key is certified by a certificate authority. The signature allows the consumer of the software to verify that the artifact was signed by whoever holds the private key and that it has not been modified since signing. Code signing is a valuable supply chain integrity control , it prevents tampering with software in transit, ensures that artifacts can be attributed to the key holder, and provides a mechanism for detecting corruption during distribution. It does not protect against a scenario where the private signing key is compromised.

The key compromise threat model is the critical limitation. Code signing prevents tampering by parties who do not have access to the signing key. It provides no protection if the attacker has obtained the private key , because a key-compromised signature is cryptographically indistinguishable from a legitimate one. An attacker who steals a vendor's code signing private key can sign arbitrary software with that key, and any consumer who trusts the certificate will accept that signature as authentic. Valid signature means the private key signed the artifact , it does not mean the vendor's build process produced it.

The certificate revocation problem is the operational gap. When a code signing key is compromised, the appropriate response is to revoke the certificate , informing the ecosystem that signatures produced by that key after the point of compromise should no longer be trusted. Certificate revocation in practice is imperfect: revocation lists (CRLs) and OCSP responses have caching delays, software that checks revocation status may not do so in real time, and many systems accept signatures without checking revocation status at all. The window between key compromise and revocation is a period during which malicious signatures appear valid.

Why this matters

Code signing limits matter for TPRM because enterprises that require code signing as a supply chain security control may have a false sense of assurance about the authenticity of signed software. The enterprise that confirms a vendor signs their releases and verifies signatures before deployment has implemented a valuable control , but not a control that protects against the most sophisticated supply chain attacks, which typically involve key compromise rather than unsigned malicious artifacts.

• Code signing accepted as complete artifact authenticity control
• Key compromise threat model not considered , signed artifacts assumed authentic
• Certificate revocation status not checked in real time
• Vendor key management security not assessed alongside signing practice
• Transparency log verification absent , signatures not checked against public log

What good looks like

Mature code signing programmes combine signature verification with transparency log checking , specifically Sigstore's Rekor transparency log, which provides an immutable record of all signing events that allows detection of certificates used outside their expected parameters , and include key management security assessment alongside signing practice confirmation.

• Signature verification for all software artifacts
• Transparency log verification , Sigstore Rekor or equivalent for signing event audit
• Certificate revocation status checked at deployment time
• Vendor key management security assessed , how are private signing keys protected
• Signing key rotation policy , how frequently keys are rotated and how compromise is disclosed

Tooling

Transparency , Sigstore Rekor for transparency log verification; cosign for signature and attestation verification

Sigstore's Rekor transparency log provides an append-only record of signing events that allows verification that a signature was produced at a specific time by a certificate that was valid at that time. For TPRM practitioners, asking whether vendor releases are logged to Sigstore Rekor provides a transparency assurance question that goes beyond signature verification alone.

Key Management , HSM-based signing, AWS KMS, Azure Key Vault for signing key protection

Hardware security module-based key management ensures that private signing keys cannot be exported , providing the key protection that prevents the compromise scenario in the hook. For TPRM practitioners, asking whether vendor code signing keys are stored in HSMs or dedicated key management services provides a key protection question that addresses the core limitation of code signing.

Governance challenges

The governance challenge with code signing is the disclosure delay problem. Vendors who discover that their signing key has been compromised face significant pressure to delay disclosure , disclosure triggers immediate revocation requirements, customer notifications, and potentially significant remediation costs. The governance resolution is requiring vendors to commit to immediate disclosure of code signing key compromise and to provide transparency log verification as a standard practice.

• Require key compromise disclosure commitment in vendor contracts
• Assess vendor key management security , HSM or equivalent for signing keys
• Require transparency log verification for signed releases
• Check certificate revocation status at deployment time
• Include key rotation policy in vendor security assessment

If you are a small team

For your software vendors that provide signed releases, ask two questions that signature verification alone does not answer. First: are your code signing private keys stored in HSMs or dedicated key management services that prevent key export? Second: are your release signatures logged to Sigstore Rekor or an equivalent transparency log? The first question addresses key compromise prevention. The second addresses detection of compromised key usage , because a compromised key used to sign a malicious release will appear in the transparency log in ways that differ from the vendor's normal signing pattern.

• Ask whether signing keys are HSM-protected
• Ask whether releases are logged to Sigstore Rekor
• Check certificate revocation status at deployment
• Include key management security in vendor assessment

What to require

Ask directly:

"Are your code signing private keys stored in hardware security modules that prevent key export , and are your release signatures logged to Sigstore Rekor or an equivalent transparency log that would allow detection of compromise?"

Expect as evidence

• HSM or equivalent key protection confirmation
• Transparency log usage confirmation
• Signing key rotation policy
• Key compromise disclosure commitment

A vendor who confirms code signing should be asked about key protection and transparency logging. Signature verification confirms the key signed the artifact. Key protection prevents compromise. Transparency logging detects compromise. All three are required for meaningful code signing assurance.

How to evidence it

• Key management security assessment records
• Transparency log verification implementation
• Certificate revocation checking implementation
• Key compromise disclosure requirement in vendor contracts

Key Takeaway

Code signature: valid. Certificate: from recognised CA. Signing key: compromised 11 months prior. All releases since: signed by whoever held the compromised key. Signature verification throughout: correct. The signature confirmed the private key signed the artifact. It confirmed nothing about whether the vendor's build process produced what the private key signed. Code signing prevents tampering by parties without the key. It provides no protection against parties who have the key. HSM-protected keys prevent key export. Transparency logs detect compromised key usage patterns. Both are required to give code signing assurance that extends to the key compromise threat model.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security