TL;DR: The publisher hashes the artifact, signs the hash with a private key (kept in an HSM), attaches a certificate binding that key to its identity, and adds a trusted timestamp. The verifier rehashes, checks the signature, validates the certificate chain and timestamp, and applies policy. A valid signature guarantees the artifact is unchanged since signing and which key signed it, not that it is safe or built from reviewed source. If the key is stolen, attackers can sign malware as you: revoke the certificate from the compromise date, rotate to a new key in hardware, re-sign current releases, investigate what was signed, and tell customers which versions to trust.
How to approach it
Walk through signing and verification, then state guarantees and non-guarantees precisely, with one real-world example of each failure mode. Finish with the incident response for key theft, which is the part interviewers most want to hear.
A strong answer
Publisher
HSM
Timestamp authority
Verifier
- Sign
Publisher to HSM
1Sign hash of artifact
1. Sign hash of artifact
Private key never leaves the HSM
Signing. Hash the artifact (SHA-256), sign the hash with the private key in an HSM, attach the code-signing certificate chain, and request an RFC 3161 timestamp so the signature remains verifiable after the certificate expires.
Verification. Recompute the hash; verify the signature with the certificate's public key; validate the chain to a trusted root with code-signing usage; confirm the certificate was valid at the timestamp and is not revoked; apply platform policy (allowed publishers, notarisation, store review).
Guarantees and non-guarantees.
| A valid signature proves | It does not prove |
|---|---|
| No byte changed since signing | The code is free of malware or bugs |
| The holder of a key bound to this publisher signed it | The build used reviewed source (SolarWinds Orion, 2020: compromised build, legitimately signed updates) |
| When it was signed (with timestamping) | The key was not stolen (Stuxnet, 2010: drivers signed with stolen vendor certificates) |
Key theft response.
- Contain: disable the key in the HSM or revoke access; stop all signing until the scope is known.
- Scope: review signing logs to find every artifact signed during the exposure window; identify which were not produced by your release pipeline.
- Revoke: ask the CA to revoke the certificate with a revocation date at the start of the compromise, so earlier legitimate releases remain valid thanks to their timestamps and later signatures become invalid.
- Rotate and re-sign: issue a new key in hardware, re-sign current supported releases, publish them.
- Communicate: tell customers which versions and hashes to trust, and what to do with anything signed in the window.
- Fix the cause: how did the key leave its protection? Move to HSM-only keys if they were exportable, add approval gates on signing, and consider short-lived keyless signing for CI releases.
Prevention. Public code-signing keys must live in hardware under CA/Browser Forum requirements in force since June 2023; sign only in a dedicated, gated release job; log and alert on every signing operation; and add build provenance so consumers can check how an artifact was built, not just who signed it.
What interviewers probe next
- "Why timestamping?" So signatures outlive certificate expiry, and so revocation can be dated to the compromise.
- "How would Sigstore change this?" No long-lived key to steal; short-lived certificates tied to a CI identity, with every signature in a public log you can monitor.
- "Does signing protect model files?" It proves who released them and that they are unchanged; it does not detect backdoored weights or unsafe pickle content.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
Your company ships a desktop agent signed with a code-signing certificate, and the signing key currently lives as a file on a build server.
Start here
What does signing actually do?
What is signed: the file or its hash?
The publisher hashes the artefact, signs the hash with a private key, attaches a certificate binding the key to its identity, and adds a trusted timestamp. The verifier rehashes, checks the signature, validates the certificate chain and timestamp, and applies its policy.
Carry it forwardSigning binds an artefact's hash to a key and identity.
Weak answerDescribing signing as encrypting the program.
Constraint changes
What does a valid signature guarantee?
Would a signature catch malicious code added before signing?
That the artefact is unchanged since signing and which key signed it. It does not guarantee the code is safe or was built from reviewed source: malicious code signed by a stolen key, or inserted before signing, verifies perfectly.
Carry it forwardSignatures prove integrity and origin, not safety.
Weak answerTreating signed as safe.
Constraint changes
What is wrong with the key living on a build server?
What can an attacker do with a copied key file?
Anyone who compromises the server, or a build job running on it, can copy the key and sign anything as you, indefinitely. Keep keys in an HSM or managed key service that signs without releasing the key, restrict which pipelines may request signatures, and log every signing operation.
Carry it forwardKeep signing keys in hardware and log every use.
Weak answerProtecting the key file with a password only.
Constraint changes
What if the key is stolen?
Which signatures should remain trusted?
Revoke the certificate from the compromise date, rotate to a new key in hardware, re-sign current releases, investigate everything signed since the compromise, and tell customers which versions to trust. Timestamps let signatures made before the compromise date stay valid.
Carry it forwardRevoke from the compromise date and re-sign.
Weak answerRevoking without telling customers which versions are good.
Constraint changes
What if malicious code was inserted during the build?
What does the signer actually vouch for?
The signature will be valid, because the build signed what it produced. Defend the build itself: hardened, isolated builders, provenance that records source and inputs, and reproducible builds or independent rebuilds where feasible to detect tampering.
Carry it forwardProtect the build, not only the key.
Weak answerAssuming signing detects build compromise.
Now defend it
How would you secure code signing for the agent?
Move the key into an HSM or managed signing service; allow only the release pipeline to request signatures, with logs and alerts; timestamp every signature; harden builders and record provenance so signed artefacts can be traced to source; and prepare a key-compromise plan: revoke from the compromise date, rotate, re-sign and tell customers which versions to trust.
How it's scored
Weak: Describes signing as encryption, or says signing proves software is safe.
Hire: Gives the hash-sign-verify flow with certificates, and separates integrity and origin from safety.
Strong Hire: Adds timestamping and its role in revocation, cites real build-compromise and key-theft cases, runs a complete key-compromise response, and connects to provenance and keyless signing.
Common mistakes
- Storing signing keys in CI secrets or on developer machines.
- Revoking a certificate without considering previously signed, legitimate releases.
- Treating "signed" as "trusted" in deployment policy without checking the signer identity.