Rekor is the transparency log in the Sigstore project, described as an immutable, append-only ledger. After signing, the artifact's digest, signature and certificate are recorded there. An entry proves a signing event was logged and can be audited. It does not prove the software is safe or that the signer was honest.
If you have seen "transparency log" in verification output and nodded along, this post gives the plain meaning and the limits.
Where Rekor sits in keyless signing
The Sigstore overview describes three named parts. Cosign is the client that signs. Fulcio is the certificate authority that checks an OpenID Connect identity token and issues a short-lived certificate tied to that identity and a public key. Rekor is the log.
The flow runs like this:
- Cosign creates a temporary key pair and asks Fulcio for a certificate, sending the public key and an identity token.
- Fulcio verifies the token and returns a short-lived certificate bound to that identity and key.
- Cosign signs the artifact. The private key is discarded after this single use, so nobody manages a long-lived key.
- The digest, signature and certificate are recorded in Rekor.
- A verifier later checks the signature against the certificate, confirms the identity matches the expected signer, validates the certificate against Sigstore's root of trust, and confirms the entry's inclusion in Rekor.
Why an append-only log helps
A log that only grows makes silent rewriting hard. If someone signs something, the record exists for anyone to inspect. That supports two things.
Auditing. A project can look for signing events under its own identity. An unexpected entry is a signal to investigate, such as a stolen token used to sign something you did not build.
Verification. The verifier's check that an entry is included gives extra assurance that the signing event was public at the time, not made privately and presented later.
What a log entry does not tell you
| Question | Does an entry answer it? |
|---|---|
| Was this signed by the identity I expect? | Yes, through the certificate, if you check it |
| Was the signing event recorded publicly? | Yes |
| Is the software free of vulnerabilities? | No |
| Was the build environment clean? | No, that is a provenance question |
| Is the signer's identity itself secure? | No |
A malicious build by a legitimate identity can produce a perfectly valid entry. The log makes that event visible. It does not judge it.
Habits that make the log useful
- Decide which identity you expect for each artifact, and check it every time you verify.
- Monitor the log for entries under your own identities, if your tooling supports it.
- Treat verification that skips the log check as weaker, and note that in your documentation.
- Keep a record of what you verified and when.
For air gapped environments, ask whether your tooling supports offline verification of a bundle, and test it before you need it.
Putting it in a buyer conversation
Say what you sign, with which tool, and what identity a customer should expect. Avoid implying that signing equals safety. Safeguard offers dependency scanning, SBOMs and policy gates that cover the content side, and the free scan at https://gold.safeguard.sh/scan can start that review.
Quick check
Does Rekor store my artifact?
Per the Sigstore overview, it records the digest, signature and certificate, not the artifact itself.
Is a Rekor entry a certification?
No. It is a public record of a signing event.
Sources
Last reviewed: 19 October 2026.
