Code signing

Every code-signing scheme applies a digital signature over a digest of the artefact, but formats differ by platform. Microsoft Authenticode (introduced 1996) embeds a PKCS#7/CMS SignedData structure in the PE file's certificate table, hashing the file while excluding the checksum and the signature area itself; Apple's codesign stores a code directory of per-page hashes and requires notarisation for Gatekeeper; Java signs JAR manifests; Linux distributions sign repository metadata or packages with OpenPGP keys; Android uses the APK Signature Scheme v2 and later, which covers the whole archive. The signer's X.509 certificate must carry the codeSigning extended key usage (OID 1.3.6.1.5.5.7.3.3) and chain to a root in the verifier's trust store.

Timestamping solves the expiry problem. A signature is sent to a Time-Stamping Authority per RFC 3161, which countersigns the signature's hash with a trusted time; verifiers then accept the signature after the certificate expires, as long as it was valid at the timestamp. It also shapes revocation: when a key is compromised, the CA can revoke with an invalidity date so that only signatures timestamped after the compromise fail. Publicly trusted code-signing certificates are governed by the CA/Browser Forum's Code Signing Baseline Requirements, which since 1 June 2023 require the subscriber's private key to be generated and kept in a hardware crypto module (HSM, token or cloud HSM service) and since 1 March 2026 limit certificate validity to 460 days.

Sigstore, an OpenSSF project, provides "keyless" signing aimed at open-source and container supply chains: cosign obtains an OIDC token for the signer's identity (a person's email or a CI workflow identity), Fulcio issues a certificate for an ephemeral key valid for about ten minutes, the signature and certificate are recorded in the Rekor transparency log, and verifiers check both the expected identity and issuer and the log inclusion. Notary Project's notation offers a PKI-based alternative for OCI artefacts; npm, PyPI and Maven Central have adopted Sigstore-based provenance or signatures in various forms.

The key limitation is that a signature attests to who signed, not to what the code does. Stolen keys have signed malware (Stuxnet used certificates stolen from Realtek and JMicron), and compromised build systems produce perfectly valid signatures on malicious code, as with SolarWinds Orion in 2020 and the 3CX desktop client in 2023. Effective programmes therefore protect keys in HSMs with separate approval for each signing operation, sign only in hardened release pipelines rather than on developer machines, pair signatures with build provenance (SLSA) and SBOMs, and enforce verification at the consumer: Windows Defender Application Control or AppLocker policies, macOS Gatekeeper, package-manager signature checks and Kubernetes admission controllers that reject unsigned images.