Artifact Signing

Artifact signing lets you detect changed software and authenticate the identity that approved it. A signer uses a private key to create a digital signature over an artifact or its digest. A verifier uses trusted public information to check that signature.

The signature answers two narrow questions:

Do these bytes match the signed content?
Does the signature validate under an identity or key that policy trusts?

It does not prove that the artifact is safe, correct, current, or authorized for every environment. Those decisions belong to verification policy.

The mental model

Think of signing as a relationship among five things:

exact artifact digest
        +
cryptographic signature
        +
signer identity evidence
        +
trusted root and time evidence
        +
verification policy
        =
accept or reject decision

A valid signature without an expected identity is incomplete. An expected identity without a matching artifact digest is also incomplete. Verification needs both.

Sign immutable content

An artifact digest identifies exact content. Change one byte and the digest changes. A signature bound to that digest therefore fails against altered content.

A tag or filename is different. It is a human-friendly reference that may later select different content. Resolve a mutable reference to a digest before signing or verifying it. Record both when you need the friendly name for operations and the digest for evidence.

This rule applies to release archives, packages, firmware, executables, container images, and metadata. OCI registries make the distinction explicit: tags point to manifests, while digests identify content.

Choose a trust model

Traditional signing assigns a long-lived private key and distributes the corresponding public key or certificate chain. The verifier trusts that key directly or through a certification authority. This model can work well, but you must protect, rotate, revoke, and distribute trust for the key.

Identity-based signing uses a short-lived certificate to bind an ephemeral key to an authenticated identity. Sigstore calls this keyless signing. A verifier checks the certificate chain, the expected OpenID Connect identity and issuer, the artifact signature, and supporting time or transparency-log evidence.

Keyless does not mean trustless. It replaces long-lived signer-key distribution with trust in an identity provider, a certificate authority, transparency infrastructure, and the verifier's identity policy.

Treat verification as policy

Cryptographic validity is only one input. A useful policy also states:

the exact artifact digest;
the permitted signer identity or public key;
the trusted root and identity issuer;
acceptable signing time and revocation state;
required transparency or timestamp evidence;
required attestations, such as provenance;
the action to take when evidence is absent or invalid.

Run verification where an artifact crosses a trust boundary. Common boundaries include publication, promotion, deployment admission, installation, and software update. Fail closed for protected releases: missing evidence should not become implicit approval.

Separate signatures from attestations

An artifact signature binds a signer to artifact content. An attestation is a signed statement that also carries a structured claim. Build provenance, for example, can describe where, when, and how an artifact was produced.

The signature protects the statement from undetected change and authenticates its issuer. The verifier must still decide whether the claim is relevant and whether the issuer is authorized to make it. A signed claim is evidence, not an automatic policy decision.

Preserve the evidence set

Verification may require more than a detached signature file. Depending on the system, preserve the artifact, signature, certificate or public-key reference, trusted-root material, time evidence, transparency-log evidence, and policy inputs.

Sigstore bundles package signature content with verification material. For short-lived certificates, time evidence establishes that signing occurred during the certificate's validity window. A bundle can also carry transparency-log material for later or offline verification.

Keep evidence addressable by the subject digest. If a registry stores related signatures and attestations, the relationship must still lead back to the exact artifact being evaluated.

Protect the signing path

Anyone who controls an accepted signing identity can authorize malicious bytes. Isolate signing authority from ordinary build and developer credentials. Limit it to specific repositories, workflows, release channels, and artifact types.

Record signing events. Monitor identity use. Plan key rotation and revocation before an incident. Preserve release evidence for investigation. NIST guidance treats private-key protection, certificate lifecycle, and review of signing processes as core parts of code-signing security.

Know the limits

Artifact signing does not:

remove vulnerabilities or malware;
prove that source review occurred;
prove that a build used the expected inputs;
stop an authorized but compromised signer;
make a mutable tag immutable;
enforce policy unless consumers actually verify.

Combine signatures with provenance, scanning, access control, reproducible or controlled builds, and admission policy. Each control answers a different question.

A practical adoption path

Inventory artifact types, publishers, and consumption boundaries.
Define immutable artifact identity for each format.
Choose a signer trust model and protect its roots.
State expected identities and evidence in machine-enforced policy.
Sign after the release artifact reaches its final digest.
Store the signature and supporting evidence with a durable digest relationship.
Verify before promotion, deployment, installation, or update.
Test rotation, revocation, outage, and incident procedures.