How Code Signing Works

TL;DR: To sign, the publisher hashes the artifact and signs the hash with a private key; a certificate binds the matching public key to the publisher's identity, and a trusted timestamp records when it was signed. To verify, the installer recomputes the hash, checks the signature with the public key, validates the certificate chain to a trusted root, and checks the signing time. A valid signature proves integrity since signing and which key signed. It does not prove the code is safe: a compromised build pipeline produces signed malware, and a stolen key lets anyone sign as the publisher. That is why keys live in HSMs and why provenance of the build matters as much as the signature.

What signing does, step by step

Code signing applies digital signatures to software artifacts: executables, installers, app bundles, packages, container images, firmware and, increasingly, model files.

Signing (publisher side).

1. Build the artifact.
2. Compute a cryptographic hash of it (SHA-256 or stronger).
3. Sign the hash with the publisher's private key, which ideally never leaves a hardware security module.
4. Attach the signature and the publisher's certificate, issued by a certificate authority after verifying the publisher's identity.
5. Obtain a trusted timestamp (RFC 3161) proving the signature existed at a specific time.

Verification (installer side).

1. Recompute the artifact's hash.
2. Verify the signature over that hash using the public key in the certificate.
3. Validate the certificate chain to a root the platform trusts, the same process as TLS certificate validation, with code-signing usage.
4. Check the certificate was valid at the timestamped signing time and is not revoked.
5. Apply policy: is this publisher allowed? Is a notarisation or store review also required?

What a valid signature guarantees

• Integrity since signing. Not one byte has changed since the signature was made, wherever the artifact travelled: mirrors, CDNs, caches.
• Origin, as far as the key. The holder of a private key, which a CA has bound to a named publisher, signed it.

What it does not guarantee

• Safety. A publisher can sign buggy or malicious code. Platforms add separate checks (malware scanning, notarisation, store review) for that.
• Integrity of the build. If attackers modify source code or the build environment before signing, the result is validly signed. The SolarWinds Orion compromise (disclosed December 2020) shipped malicious code inside legitimately signed updates because the build process was compromised.
• That the key is still exclusively the publisher's. Stuxnet (discovered 2010) used drivers signed with certificates stolen from two hardware vendors. Signature checks passed because the signatures were real.

Protecting the key and the process

Because the signature is only as trustworthy as the key and the pipeline:

• Keep private keys in hardware. Since June 2023, the CA/Browser Forum's code signing requirements oblige publicly trusted code signing keys to be generated and stored in hardware (HSMs or hardware tokens).
• Sign in a controlled step. A dedicated release job, separate from general CI, with approval gates, signs only artifacts produced by the trusted build.
• Log and monitor signing. Every signing request should be attributable; unexpected signatures are an incident.
• Plan for compromise. If a key leaks: revoke the certificate (choosing the revocation date carefully so legitimately signed releases before the compromise stay valid), issue a new key, re-sign current releases, and tell customers which versions to trust.
• Add build provenance. Signed statements about how and from what source an artifact was built (SLSA provenance) address the gap signing leaves.

Newer systems such as Sigstore remove long-lived keys entirely by issuing short-lived certificates tied to an identity and recording every signature in a public transparency log.

Signing models

Model weights are executable in the sense that matters: loading a pickle-based checkpoint can run code, and even data-only weights decide what a system does. The same ideas apply. The OpenSSF model signing specification (version 1.0 released in 2025, checked November 2026) signs a manifest of every file in a model directory, typically using Sigstore, so consumers can verify who produced a model and that no file changed. As with software, a valid signature on a model says who released it, not that it is free of backdoors.

Signing models, precisely

Model files are now signed with the same machinery as code. The OpenSSF model signing specification reached version 1.0 in April 2025, developed by Google's open source security team with NVIDIA and HiddenLayer. What it signs is worth knowing exactly:

• A model is a directory of files, not one file: weights (often sharded), configuration, tokenizer and sometimes code. The tool hashes every file and builds a manifest of their digests.
• The manifest goes into an in-toto statement inside a signed envelope (DSSE), stored as a Sigstore bundle in JSON.
• Sigstore keyless signing is the default; organisations can use their own PKI or self-signed certificates instead.
• Version 1.0 explicitly leaves provenance (how the model was trained, from what) and datasets for later work. A signature says who released these exact files, not how they were made.

Hugging Face also lets authors sign commits with GPG keys, and its documentation is careful about the meaning: a signed commit does not guarantee the file is safe, only where it came from.

A name is not an identity

In September 2025 Unit 42 described model namespace reuse: when a Hugging Face organisation or user is deleted or transferred, someone else can register the same name. Any pipeline or model catalogue that refers to Author/ModelName by name then resolves to the newcomer's model. Unit 42 found such references in code and in cloud model catalogues; Google now scans for orphaned models daily and blocks them. The mitigations are the general lessons of signing: pin a specific commit (revision), mirror approved models into an internal registry, and treat model references in code as dependencies with owners.

Worked example: a vendor's organisation disappears

A team uses vendor/llm-7b. Its policy requires a model signing bundle whose certificate identity is the vendor's release workflow and whose issuer is the vendor's identity provider; every file digest must match the manifest; and the Hugging Face revision is pinned to a commit hash.

Six months later the vendor deletes its organisation and an unknown party registers the same name and uploads a model. The new files are unsigned, or signed by a different identity, so verification fails closed and nothing is deployed. Even without signing, the pinned commit would have protected the team, but only if the pin was a commit hash and not a branch name such as main.

Package ecosystems have moved the same way. npm added Sigstore-based package provenance in April 2023, binding each package to the CI workflow that built it, and users can check signatures with npm audit signatures. How keyless signing works is covered in Sigstore.

Misconceptions interviewers listen for

• "A signed model is a safe model." Signing proves origin and integrity, not the absence of a backdoor.
• "The model name is the identity." Names can change hands; identity is a signer or a digest.
• "Signing the weights file is enough." Configuration, tokenizers and code travel with the model, which is why model signing hashes every file.
• "A signed commit on the hub means the file was scanned." It shows origin only.

How this shows up in interviews

"How does code signing work, and what happens if the key is stolen?" is a fundamentals question that separates people who know the mechanism from people who know the term. Strong answers give the hash-sign-verify flow with certificates and timestamps, state exactly what a signature does and does not prove, cite a real case of build compromise or key theft, and describe key protection and a compromise response.

Say it in 30 seconds: "The publisher hashes the artifact, signs the hash with a private key kept in an HSM, attaches a certificate binding that key to their identity, and timestamps it. The installer rehashes, verifies the signature, validates the certificate chain and checks the timestamp. That proves the code hasn't changed since signing and which key signed it, not that it's safe. A compromised build gets signed anyway, as SolarWinds showed, and a stolen key signs malware, as Stuxnet showed, so you protect the key in hardware, gate the signing step, and add build provenance."