Native Artifact Signing and Release

Signing application binaries for Windows, macOS, and Linux: Authenticode and timestamping, hardware-backed keys after the 2023 CA/Browser Forum rules, codesign and notarization, and doing all of it in CI without a private key ever touching a build agent.

Overview

The difference between installing and not installing

Every desktop and embedded product hits this: the build works, tests pass, then SmartScreen warns users away from the installer, macOS refuses to open the app, or an enterprise customer demands the signing chain before deploying. On native software, signing is not a nicety; it decides whether the product installs.

Not the same problem as container signing

Verified by — An admission controller or policy engine you deployed — The operating system on a stranger's machine
When — At admission — Before your code runs
Your influence — You write the policy — None: no policy to deploy, no fallback path

> [!WARNING] Conflating the two is the most common way to answer this badly.

Each platform enforces differently

Windows — Authenticode: PKCS#7 signature embedded in the PE structure — At load and install; SmartScreen reputation warns on an unrecognized signer even with a valid signature
macOS — codesign, notarization, stapling — Gatekeeper on first launch; the hardened runtime constrains the process at runtime
Linux — Essentially no OS-enforced model for arbitrary binaries — Delegated to the package manager and signed repository metadata

The rules changed recently

June 1, 2023 — CA/Browser Forum Code Signing Baseline Requirements: private keys generated, stored and used in a hardware crypto module meeting FIPS 140-2 Level 2 or equivalent, for OV as well as EV
March 1, 2026 — Certificates issued on or after this date capped at 460 days

> [!IMPORTANT] The file-based certificate workflow is no longer available. Describing it as current practice describes something that stopped being issued years ago.

The architecture that was already correct

Build agents — Produce unsigned artifacts and request signatures
HSM or cloud KMS — Holds keys that never leave it
Short-lived federated credentials — Authentication, no stored secret
Policy — What may be signed, and by whom
Audit log — Every operation recorded

A signature is meaningful only if it states that a specific pipeline built a specific artifact, and that holds only if the key could not have been used by anything else.

Two adjacent practices

Reproducible builds — Identical inputs give identical output, so a third party can rebuild and compare instead of trusting you
SBOM (SPDX or CycloneDX) — What is inside this binary, and which of it is now known vulnerable: a question the signature cannot answer

> [!NOTE] UEFI Secure Boot and kernel module signing, and the SLSA, Sigstore and cosign container story, are covered in related topics. This one stays on application binaries shipped to end users.

Key concepts

Authenticode: The Windows code signing format. A PKCS#7 signature is embedded in the certificate table of a PE file — executables, DLLs, drivers, MSIs, catalogs, and PowerShell scripts. signtool.exe signs, timestamps, and verifies it, returning 0 on success, 1 on failure, and 2 on completion with warnings.
RFC 3161 timestamping: A countersignature asserting the signing time from a trusted authority, applied with signtool using the RFC 3161 timestamp URL option together with a timestamp digest algorithm. Without it the signature becomes invalid when the certificate expires, retroactively breaking every copy already shipped. The legacy timestamp option cannot be combined with it.
Hardware key storage requirement: Effective June 1, 2023, the CA/Browser Forum Code Signing Baseline Requirements require the subscriber private key to be generated, stored, and used in a suitable hardware crypto module meeting or exceeding FIPS 140-2 Level 2 or equivalent. Applies to OV and EV alike, and is satisfied by an HSM, a hardware token, or a qualified cloud signing service.
EV versus OV: Both now require hardware key protection. EV involves stricter organisation vetting and historically grants immediate SmartScreen reputation, whereas an OV signer must accumulate reputation through download volume. Kernel-mode driver signing is a separate regime requiring attestation signing through Microsoft Partner Center.
Hardened Runtime: A macOS opt-in enabled through a codesign option that restricts the process — no unsigned executable memory, no arbitrary dynamic-linker environment variables, library validation enforced. It is required for notarization, and narrow entitlements in the com.apple.security.cs namespace grant specific exceptions such as allowing a just-in-time compiler.
Notarization and stapling: The notarytool submit command uploads the artifact to Apple, which scans it and issues a ticket; a wait option blocks for the result and the log subcommand explains failures. The stapler tool then attaches the ticket to the app, disk image, or installer package so Gatekeeper can verify offline.
Digest signing: The client hashes the artifact and sends only the digest to the signing service, which returns a signature. The artifact never leaves the build machine and the key never leaves the HSM. On Windows this is what the signtool /dlib option performs, combining digest generation, signing, and ingestion into one atomic operation.
Reproducible build: A build producing bit-identical output from identical inputs, typically requiring a fixed source date for embedded timestamps, sorted inputs, stripped build paths, and a pinned toolchain. It lets an independent party rebuild and compare, turning a signature from a claim about identity into a verifiable claim about content.

When to use it

Shipping any desktop or command-line application to end users on Windows or macOS, where unsigned software is warned against or blocked by default
Distributing installers, updaters, or drivers where the operating system enforces signature checks before execution
Enterprise customers requiring a verifiable signing chain, an audit trail, and an SBOM before they will approve a deployment
Migrating from file-based certificates to HSM or cloud signing after the 2023 hardware key storage requirement
Building a release pipeline where the signing key must never be readable by a build agent or a compromised dependency

Interview questions

Walk through signing a Windows application end to end in CI, without the private key ever reaching a build agent.
Explain the full macOS chain: signing, Hardened Runtime, notarization, and stapling. What breaks at each stage?
Design a signing architecture for CI where no build agent can be trusted with a key. What does it enforce, and what does it log?
Why do reproducible builds make signatures meaningful, and how do SBOMs and embedded version metadata fit in?
How does Linux package signing differ, and why is there no Gatekeeper equivalent?