openskills.info
Course Preview

Artifact Signing

Artifact signing attaches a cryptographic signature to a software artifact so consumers can verify who produced it and that it has not been tampered with after creation. It establishes provenance and integrity across the software supply chain.

itSoftware supply chain security

Don't Panic — Artifact Signing

Artifact signing is the arrangement that ties exact software bytes to an approved signer. It exists because a release name is a surprisingly poor witness. A tag, version, or filename can remain polite and familiar while pointing at different content. A digest does not have that social flexibility.

The important move is to sign the digest, not the label. Change one byte and the digest changes, which means the old signature no longer fits. This is useful because software crosses several trust boundaries: publication, promotion, deployment, installation, and update. At each one, a verifier can ask whether these are the bytes somebody authorized, rather than admiring a version string and hoping it has been behaving.

Then comes the mildly inconvenient part: a valid signature is not a permission slip. Verification needs the signature, the exact artifact digest, signer evidence, trusted roots and time evidence, and a verification policy. The policy says which identity or key is allowed for this artifact and what happens when evidence is absent. Cryptography checks the relationship. Policy decides whether that relationship gets through the door.

There are two broad trust models. A long-lived private key asks you to protect, distribute, rotate, and revoke key material without turning it into an all-purpose release wand. Identity-based signing uses an ephemeral key and a short-lived certificate bound to an authenticated identity. It is often called keyless signing, which is a fine name provided nobody mistakes it for an absence of keys, roots, issuers, or administration.

A signature says that a signer approved this digest. An attestation says that an issuer made a structured claim about it, such as where and how it was built. Both need policy. Neither proves the software is safe, free of vulnerabilities, made from reviewed source, or acceptable in every environment. Security controls are not jealous; they each want their own question.

Start with the Intro for the full trust model and failure boundaries. Use Slides for the five inputs that lead to accept or reject. Keep the Cheatsheet nearby when writing policy or investigating a failed verification. The Reference tab leads into NIST, Sigstore, SLSA, in-toto, and OCI material when the friendly overview has run out of room.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources