Artifact Signing: Proving Your Code is Your Code

Why it exists

Unsigned software is vulnerable to supply chain attacks. An attacker can create a malicious package with a similar name (typosquatting), compromise the server where it's hosted, or tamper with it after it's published. Artifact signing exists to provide a verifiable chain of custody from the developer to the consumer, ensuring authenticity and integrity.

The mental model

Think of artifact signing as a digital wax seal on a letter. The seal proves two things: first, who sent the letter (authenticity), and second, that the letter hasn't been opened and changed in transit (integrity). A broken seal immediately signals that the contents cannot be trusted. In software, the "seal" is a cryptographic signature attached to a container image, binary, or release file.

How it works

The process uses public-key cryptography. A developer generates a key pair: a private key they keep secret and a public key they share. To sign an artifact, they create a cryptographic hash of the file and then encrypt that hash with their private key. This encrypted hash is the signature. A consumer verifies it by decrypting the signature with the developer's public key to reveal the original hash. The consumer then independently hashes the artifact and compares their hash to the decrypted one. If they match, the signature is valid.

When to use it

Use artifact signing in any automated software delivery pipeline (CI/CD), especially for public-facing software. Key use cases include: signing container images before pushing them to a registry, signing release binaries and packages (like JARs or executables), and signing metadata files like Software Bills of Materials (SBOMs).

When not to use it

Signing is less critical for internal-only, ephemeral artifacts that never leave a trusted environment, like a build artifact used in an intermediate CI job that is immediately discarded. The overhead might not be justified if the artifact has an extremely short lifespan and a limited blast radius. However, with modern tooling, the overhead is minimal, making it a good default practice.

One canonical example

Traditionally, developers used tools like GPG, which created a huge burden of managing and distributing keys. A modern example is Sigstore's cosign tool. A developer can run cosign sign <image> and authenticate using their existing OIDC identity (like a GitHub or Google account). Cosign generates a temporary key pair, signs the container image, and records the event in a public, tamper-resistant transparency log. This eliminates the need for developers to manage long-lived private keys.