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 | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
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
- https://csrc.nist.gov/pubs/cswp/5/security-considerations-for-code-signing/final
Supports
- Digital signatures as software integrity and source-authentication controls
- Code-signing architecture, use cases, security problems, and mitigations
- Applicability to firmware, operating systems, applications, and container images
- Private-key protection and signer security as core trust concerns
- Quiz answers about signature scope and signing-authority compromise
- https://csrc.nist.gov/pubs/sp/800/218/final
Supports
- Release-integrity verification information for software acquirers
- Code signing as one mechanism for release-integrity verification
- Review of certificate renewal, rotation, revocation, and protection
- Retention and protection of release files, integrity evidence, and provenance
- https://docs.sigstore.dev/cosign/signing/overview/
Supports
- Identity-based signing with ephemeral keys and short-lived certificates
- OpenID Connect identity binding through Fulcio
- Rekor transparency-log recording and auditing of signing events
- Verification using artifact, signature, certificate, and log evidence
- Monitoring unexpected use of a signing identity
- Quiz answers about keyless trust and workload identity
- https://docs.sigstore.dev/cosign/verifying/verify/
Supports
- Verification using a public key or certificate identity and issuer
- Cosign signature payloads containing container-image digests
- Default validation that the signed digest matches the verified container
- Bundle-based blob verification
- Transparency-log verification options
- Quiz answers about digest binding and exact identity constraints
- https://docs.sigstore.dev/about/bundle/
Supports
- Bundles as signature content plus required verification material
- Certificates and out-of-band public-key identifiers
- Signed entry timestamps and RFC 3161 timestamps for short-lived certificates
- Transparency-log entries, inclusion promises, and inclusion proofs
- Message signatures over artifact hashes and signed in-toto statements
- Quiz answers about historical and offline verification evidence
- https://slsa.dev/spec/v1.2/verifying-artifacts
Supports
- Verification of artifacts and provenance against expectations
- Artifact digest as the binding between provenance and subject
- Separation of evidence availability from consumer verification
- Package, builder, source, and build-process expectations
- Quiz answers about retaining digest-linked evidence
- https://slsa.dev/spec/v1.2/provenance
Supports
- Provenance as verifiable information about where, when, and how an artifact was produced
- Distinction between provenance claims and a plain artifact signature
- Quiz answer about the purpose of signed provenance
- https://in-toto.io/docs/specs/
Supports
- Stable in-toto supply-chain specification
- Stable in-toto Attestation Framework specification
- Standard formats for signed supply-chain metadata and statements
- https://in-toto.io/docs/getting-started/
Supports
- Signed layouts defining authorized supply-chain steps and functionaries
- Signed link metadata recording materials, products, commands, and functionaries
- Verification of step authorization, expected commands, and material or product rules
- Difference between signed metadata and the policy that evaluates it
- https://github.com/opencontainers/distribution-spec/blob/main/spec.md
Supports
- Blobs and manifests addressable by digest
- Tags as human-readable pointers to manifests
- Client verification of content against requested digests
- Subject relationships and referrers for attached evidence
- Quiz answers about immutable content identity and evidence relationships
- https://www.openpgp.org/about/history/
Supports
- PGP release in 1991 and the development of OpenPGP
- https://www.rfc-editor.org/rfc/rfc2440
Supports
- OpenPGP standardization in November 1998
- https://opencontainers.org/posts/announcements/2015-07-22-community-rallies-behind-open-container-initiative/
Supports
- OCI draft charter and specification in July 2015
- https://opencontainers.org/posts/announcements/2017-07-17-open-container-initiative-oci-releases-v1-0-of-container-standards/
Supports
- OCI Image Format and Runtime Specification version 1.0 in 2017
- https://in-toto.io/news/
Supports
- in-toto launch in 2016 and its Jenkins plugin release in 2019
- https://blog.sigstore.dev/a-new-kind-of-trust-root-f11eeeed92ef/
Supports
- Sigstore root-key ceremony in June 2021
- https://slsa.dev/blog/2023/04/slsa-v1-final
Supports
- SLSA version 1.0 final release and its verification guidance in 2023
- https://notaryproject.dev/
Supports
- Notation placement in the OCI registry-signing landscape
- https://jfrog.com/artifactory/
Supports
- Artifact repository placement in the signing evidence-retention landscape
- https://github.com/features/security/software-supply-chain
Supports
- GitHub artifact attestation placement in the CI provenance landscape
- https://azure.microsoft.com/products/trusted-signing
Supports
- Managed code-signing placement in the signing-authority landscape
- https://www.digicert.com/signing/software-trust-manager
Supports
- Managed certificate and code-signing placement in the long-lived-key landscape
