Keyless Signing

Unlike traditional PKI, keyless signing generates a one-time-use key pair for each signing event. The private key is created, used to sign the artifact, and immediately destroyed within the same process. This eliminates the risk of long-term key exfiltration, as there is no persistent secret to steal. The public key is embedded in a certificate request and validated by a trusted authority.

The signing process is triggered by an OpenID Connect (OIDC) token issued by the workload's execution environment (e.g., GitHub Actions, Kubernetes). This token cryptographically proves the identity of the service requesting the signature. The Certificate Authority verifies this token and binds the ephemeral key to that specific identity, creating an auditable chain of custody from the signature back to the source code repository or deployment pipeline.

Every signature event is recorded in an append-only, cryptographically verifiable transparency log (such as Rekor). This log acts as a global witness, making the signing event publicly auditable and preventing retroactive forgery. A verifier can check the log to confirm that a signature was created during the certificate's validity window and that the certificate itself was properly issued, ensuring non-repudiation.

The Certificate Authority (e.g., Fulcio) issues an X.509 certificate valid for only a few minutes. This drastically reduces the window of vulnerability. Even if a private key were somehow recovered before its immediate destruction, the corresponding certificate would have already expired, rendering the key useless for future forgery. This design avoids the need for complex Certificate Revocation Lists (CRLs).

To verify a keyless signature, a policy engine does not check a static public key. Instead, it validates the chain: the artifact's signature matches the ephemeral key, the certificate chains to a trusted root, the embedded OIDC identity matches the expected workload (e.g., a specific GitHub repository), and a proof of inclusion exists in the transparency log. This shifts trust from key custody to platform identity verification.

The foundational concept that enables keyless signing by assigning a verifiable identity to a non-human process or service. Instead of managing static credentials, the identity is derived from the runtime environment's attributes.

• SPIFFE provides a universal identity control plane for heterogeneous environments
• OIDC tokens serve as the identity document, binding the signature to a specific CI/CD job or cloud workload
• Eliminates the need for long-lived service account keys that can be leaked or stolen

The open-source project that implements the keyless signing paradigm at scale. It combines three core components to replace traditional private key infrastructure:

• Fulcio: A certificate authority issuing short-lived code-signing certificates bound to an OIDC identity
• Rekor: An append-only transparency log that records every signature event, making the process publicly auditable
• Cosign: The CLI tool that signs and verifies container images and OCI artifacts using the Sigstore stack

An append-only, cryptographically verifiable ledger that records the issuance of digital signatures and certificates. This is the mechanism that prevents retroactive forgery in keyless signing.

• Every signature is publicly recorded, creating a non-repudiable audit trail
• Rekor is the reference implementation within the Sigstore ecosystem
• Enables offline verification: a verifier can confirm a signature was logged without trusting the signer
• Prevents an attacker from signing malicious artifacts and later claiming the signing key was compromised

A cryptographically signed statement that asserts a verifiable fact about a software artifact. In the context of keyless signing, attestations extend beyond simple signature verification to include rich metadata.

• Provenance attestations describe how, when, and where an artifact was built
• Vulnerability scan attestations certify that a specific scan passed against a specific artifact digest
• in-toto provides a framework for collecting signed attestations across every step of a supply chain
• Attestations are stored alongside the artifact in an OCI-compliant registry using ORAS

A machine-readable inventory of all components, libraries, and dependencies that constitute a software artifact. SBOMs are a critical companion to keyless signing for complete supply chain transparency.

• SPDX and CycloneDX are the dominant SBOM formats
• A signed SBOM attests that the inventory was generated by a trusted process and hasn't been tampered with
• Combined with a Model Bill of Materials (MBOM), this extends the same guarantees to AI model artifacts
• Enables precise vulnerability tracking by mapping known CVEs to specific component versions

A deploy-time security control that ensures only trusted, verified artifacts are allowed to run in production. Keyless signing provides the cryptographic evidence that binary authorization policies evaluate.

• Kubernetes admission controllers intercept deployment requests and validate signatures before allowing pods to schedule
• Policies can require signatures from specific identities, transparency log inclusion, or fresh attestations
• Open Policy Agent (OPA) enables flexible, context-aware authorization rules using the Rego language
• Creates a continuous verification chain from build to runtime, preventing unsigned or tampered artifacts from executing