Non-Repudiation

Establishes a cryptographically verifiable link between a digital artifact and the specific workload identity that created it. This is achieved through digital signatures generated with a private key held exclusively by the signing entity. Verification uses the corresponding public key, proving the artifact could only have been signed by the holder of the private key. In modern supply chains, this often leverages keyless signing via Fulcio, binding the signature to an ephemeral OIDC-backed identity.

Proves that the signature existed at a specific point in time, countering backdating attacks where a signer might later claim a key was compromised before signing. This is achieved by submitting the signed artifact's hash to a Time Stamping Authority (TSA) , which countersigns it with a trusted timestamp. In the Sigstore ecosystem, the Rekor transparency log provides this function by recording the signature in an immutable, append-only ledger with a verifiable timestamp.

The foundational requirement that the signing private key is generated, stored, and used in a manner that prevents unauthorized access and duplication. If a private key can be stolen, non-repudiation is broken. Best practices mandate the use of Hardware Security Modules (HSMs) or cloud-based Key Management Services (KMS) to protect root keys, and ephemeral keys generated within secure enclaves for short-lived signing operations.

A modern paradigm that eliminates long-lived private key management while preserving non-repudiation. Fulcio issues short-lived code-signing certificates bound to an OpenID Connect identity (e.g., a GitHub Actions workflow or Kubernetes workload). The signing event is recorded in Rekor, a transparency log, creating an immutable, auditable record. This approach provides stronger non-repudiation than traditional key-based signing because the identity binding is temporally scoped and publicly verifiable.

Cryptographically signed statements that assert verifiable facts about an artifact beyond simple origin. An in-toto attestation can declare the build process used, the SBOM contents, or vulnerability scan results. Each attestation carries its own non-repudiation property—the attester cannot deny making the claim. In model registries, attestations create a chain of custody from training data through model export, with each step independently verifiable and attributable to a specific actor or system.

A security framework that binds non-repudiation to the runtime enforcement of artifact integrity. Docker Content Trust and Notary use The Update Framework (TUF) to manage signing keys and delegate trust. When a model registry enforces content trust, only artifacts with valid, non-repudiable signatures from authorized publishers can be pulled and deployed. This closes the loop from forensic non-repudiation (proving who signed after the fact) to operational non-repudiation (preventing unsigned artifacts from running at all).