Rekor and the transparency log — what Rekor does, the public log

Rekor is the append-only transparency log that records every signed public statement in the Sigstore ecosystem. The log is the tamper-evident record. A signature without a Rekor entry has lost the tamper-evidence property: the verifier can check the cryptographic signature, but the verifier cannot prove that the signature was made at the time the signing identity claims, by the signing identity the certificate names.

What Rekor is and what it does

Rekor is a public, append-only ledger. Each entry is a signed public statement plus a Merkle tree inclusion proof. The properties:

• Append-only. The log never deletes an entry; the Merkle root advances as new entries are added. The log is the cryptographic record.
• Signed public statements. Every entry is a payload (the signature, the certificate, the artifact digest) that any party can verify against the log.
• Merkle tree inclusion proof. Each entry carries a proof that the entry is part of the current log root. The proof is the cryptographic anchor.
• Discoverable. The log is searchable by payload, by certificate fingerprint, by entry UUID, or by artifact digest. The search is the operational tool.

flowchart LR
    A["Signature"] --> B["Rekor entry"]
    B --> C["Merkle log"]
    C --> D["Inclusion proof"]
    D --> E["Verifier"]
    E --> F["Accept"]
    E --> G["Reject"]

The relationship to certificate transparency (CT) is direct. CT logs record every X.509 certificate issued by a CA; Rekor records every signed public statement made by a Sigstore key. The two log types share the same design pattern and the same monitoring discipline.

The signer side: what gets recorded

Every keyless signature (and every keypair signature that uses Rekor) results in a Rekor entry. The entry contains:

• The artifact digest. The signed digest is the subject.
• The public key. The signing key material (or the reference to the ephemeral key).
• The signature. The signed payload.
• The certificate. The Fulcio certificate (for keyless) or the metadata (for keypair).
• The timestamp. The time the entry was appended.

The entry is searchable by any of these fields. The search is the operational primitive the auditor uses: “what was signed by this workflow in the last 90 days?”.

The verifier side: the inclusion proof

The verifier checks the signature cryptographically and fetches the inclusion proof from Rekor. The proof is the answer to “is this signature in the log?”. The verifier performs the check:

1. Fetch the signature from the registry.
2. Fetch the certificate from the signature.
3. Fetch the Rekor entry from the public-good instance or the self-hosted instance.
4. Verify the inclusion proof against the current Merkle root.
5. Verify the certificate against the pinned OIDC identity.
6. Accept or reject.

The inclusion proof is the property that turns the log from a record into a proof. Without the proof, the log is a calendar; with the proof, the log is an attestation.

Rekor search and the public instance

The Rekor REST API is the operational interface. The most common operations:

rekor-cli get --uuid $ENTRY_UUID
rekor-cli search --artifact $DIGEST

The --artifact flag searches by the artifact digest; the output is the list of entries that reference the digest. The team uses the search to answer: “what was signed for this image?”, “which entries reference this digest?”, “what is the entry UUID for the signature?”.

The public-good Rekor instance is at https://rekor.sigstore.dev. The instance is searchable without authentication; the inclusion proof is verifiable against the public Merkle root.

Production failure modes

The transparency-log integration has four failure modes the production team must own:

• Inclusion proof missing. The CI job does not check the Rekor entry; the audit later cannot find the entry. The fix is to fail the CI job when the inclusion proof is absent.
• Rekor unavailable. The public-good instance is unreachable. The sign operation fails; the deploy is blocked. The fix is to point at a self-hosted instance or to cache the inclusion proof.
• Merkle root rotation. The log rotates the root; the cached inclusion proof is stale. The fix is to re-fetch the inclusion proof against the current root.
• Search latency. The search is slow; the audit query times out. The fix is to use the indexed search endpoint, not the full-log scan.

Production discipline

1. Fail the CI job if the Rekor inclusion proof is missing. The transparency log is the property; the property is not optional.
2. Use the public-good instance for the default; self-host for strict availability. The public-good instance has an SLA but not an SLO.
3. Search the log periodically from the audit pipeline. The audit queries are the operation; the log is the answer.
4. Document the Rekor URL in the runbook. The URL is the operational lever; the runbook is the operational deliverable.

Cross-course references

• Git, CI/CD & GitOps — Part LXIX-03 (Keyless Signing with Fulcio) is the signing side; LXIX-05 is the log side.
• Git, CI/CD & GitOps — Part LXVIII-04 (SBOM Distribution and Attestation) covers the OCI referrer model that Rekor entries also reference.
• Linux for Production Sysadmins — Part XXX (Audit Logging) is the broader operational discipline for tamper-evident logs.

Quiz