# Keyless Signing With Witness and Sigstore Source: https://www.testifysec.com/blog/keyless-signatures-sigstore/ Author: Cole Kennedy Published: 2023-01-20 Updated: 2026-10-06 How to implement keyless signing for better software supply chain security. Editorial update ยท October 6, 2026 Updated by TestifySec Editorial to clarify the trust boundaries and replace incomplete migrated instructions with maintained references. The original publication date and article URL are unchanged. - [Witness documentation โ†—](https://witness.dev/) - [Current TestifySec docs โ†’](https://www.testifysec.com/docs) - [Trust architecture โ†’](https://www.testifysec.com/docs/cilock/trust) Keyless signing reduces the need to distribute and retain long-lived private signing keys. It does not remove keys, identity management, or the need to decide which signers to trust. This article explains the trust decisions behind a Witness keyless-signing workflow. The original 2023 examples lost code during a content migration. The instructions below now point to maintained upstream examples rather than presenting incomplete commands as a working tutorial. ## What is a keyless signature, and how can we trust it? In a typical Sigstore keyless flow, a client creates an ephemeral key, authenticates through an identity provider, and obtains a short-lived certificate from Fulcio. A verifier must check the signature and certificate chain, and require the expected identity and issuer. Trusting a certificate authority without constraining who may sign is too broad for most release policies. Short-lived keys limit one form of persistent credential exposure. They do not protect a compromised identity provider, signing session, or evidence producer. ### Countersigning and timestamps An RFC 3161 timestamp can establish that the timestamped data existed by a particular time, subject to trust in the timestamp authority. When the timestamp covers a signature, a verifier can use that time when evaluating the signer's certificate validity. A timestamp does not shorten a certificate's lifetime. It does not establish that a test actually ran or that its result is true. Multiple timestamp authorities help only when the verifier enforces a defined trust and quorum policy. ### Signed Certificate Timestamp (SCT) An SCT is a log's signed promise to include a certificate. It is not, by itself, proof that an artifact signature existed at that time. Certificate transparency, artifact-signature transparency, and RFC 3161 timestamps serve different purposes. Use the verification requirements for the exact tool and bundle format being deployed. ## Technical description of Sigstore keyless signatures [Fulcio](https://docs.sigstore.dev/certificate_authority/overview/) issues short-lived certificates. [Rekor](https://docs.sigstore.dev/logging/overview/) provides transparency for signing events. Clients such as Cosign perform signing and verification and can package evidence for later verification. Sigstore also supports deployments beyond its public services. Offline verification requires the complete verification material and explicitly provisioned trust roots. It is not made safe by ignoring an expired trust-metadata check. Consult the [current Sigstore verification documentation](https://docs.sigstore.dev/cosign/verifying/verify/) for the selected client and format. ## The SPIFFE/SPIRE project [SPIFFE](https://spiffe.io/docs/latest/spiffe-about/overview/) defines workload identities; SPIRE is an implementation that attests nodes and workloads and issues identity documents. A workload identity, an OIDC signing identity, and a human's interactive approval are different kinds of evidence. Do not infer one from another. ## Overview of the Witness signing and verification flow The useful separation is capture, sign, retain, and verify: 1. A configured producer observes a command and the relevant inputs and outputs. 2. A signing mechanism binds the resulting statement to a key or certificate identity. 3. The signed envelope and required verification material are retained. 4. A verifier checks the approved policy, expected producer, artifact digest, required predicates, and applicable time evidence. Successful signature verification establishes integrity and attribution under that trust configuration. It does not establish that the producer reported the work honestly. ## Example: use Witness and Fulcio to create and verify an attestation Use the upstream [Witness Sigstore keyless tutorial](https://witness.dev/docs/docs/tutorials/sigstore-keyless/) with a pinned [Witness release](https://github.com/in-toto/witness/releases). Match the tutorial's flags and policy schema to that release before applying it in CI. For a meaningful trial, create a fresh output in the observed command, verify it under your expected signer identity, then repeat verification with a modified output and an unexpected identity. Both negative cases must be rejected by your configured policy. Keep private data out of public transparency or storage services. ### Create the artifact policy Require the actual artifact digest and the attestation types needed for your decision. Constrain the signing identity and issuer explicitly. A claimed username, environment variable, or observed agent label is not authentication. ### Sign the policy file The identity authorized to sign policy is separate from the identity producing build evidence. Use the policy-signing procedure supported by your selected Witness version. The old file-based key examples in this article are not instructions for the CI/lock and Pushgate policy lifecycle. ### Verify the attestation Treat verification as a decision point that must actually run before acceptance. Signing or uploading an attestation does not automatically configure an enforcement gate. ## Using CI/lock today Start with [your first CI/lock attestation](https://www.testifysec.com/docs/cilock/getting-started/first-attestation) and its [trust model](https://www.testifysec.com/docs/cilock/trust). Check the [support matrix](https://www.testifysec.com/docs/concepts/support-matrix) for capture limits in your execution environment. CI/lock captures the work; Pushgate checks the push; the platform manages gates and technical control evidence.