Rekor is the append-only transparency log at the center of the Sigstore project, and answering the question of what is Rekor starts with what it actually stores: not the software itself, but cryptographic proof that a signing event happened. Each time a developer or CI pipeline signs an artifact — a container image, a Python wheel, an npm package, an SBOM — the signature, the public key or certificate used, and a hash of the artifact can be submitted to Rekor as a timestamped entry. Once written, that entry is baked into a Merkle tree and cannot be silently altered or deleted; any attempt to rewrite history changes the tree's root hash, which is itself checkpointed and publicly auditable. In effect, Rekor turns "trust me, I signed this" into a verifiable, third-party-witnessed claim, giving anyone downstream a way to confirm exactly who signed what, and when, independent of the artifact's original publisher.
What Is Rekor and Why Does It Exist?
Rekor is an open-source, publicly hosted transparency log server, built and maintained under the Sigstore project (originally incubated at Red Hat and Google, now a Linux Foundation project), created to solve a problem that traditional code-signing has never handled well: detecting when a signing key is stolen, misused, or used by someone other than the expected owner. Classic code signing tells a verifier "this signature is cryptographically valid," but it says nothing about whether the signature should have existed in the first place. The 2017 CCleaner incident, where attackers used a compromised but entirely legitimate signing certificate to distribute malware for weeks, is the canonical example of why that gap matters — the signatures checked out perfectly, and no one noticed. Rekor closes that gap by making every signing event a public, timestamped, tamper-evident record that security teams, package registries, and auditors can monitor and cross-check, rather than trusting a signature in isolation.
How Does Rekor Fit Into the Sigstore Transparency Log Ecosystem?
Rekor is one of three core services that make up the Sigstore transparency log stack, working alongside Fulcio (a short-lived certificate authority) and client tooling like cosign and gitsign to enable what Sigstore calls "keyless signing." The flow works like this: a developer or CI job authenticates with an OpenID Connect identity (a GitHub Actions workflow token, a Google account, a corporate SSO login), Fulcio issues a code-signing certificate that's valid for about ten minutes and binds that OIDC identity to a freshly generated keypair, the artifact is signed with that ephemeral key, and the signature — along with the Fulcio certificate — is submitted to Rekor for permanent recording. Because the certificate expires almost immediately, there's no long-lived private key sitting in a CI secret store waiting to be exfiltrated. The Rekor entry is what makes the ten-minute certificate useful forever: it proves the certificate was valid and the signature was made at a specific point in time, long after the certificate itself has expired.
How Does Rekor Function as an Immutable Software Signing Ledger?
Rekor works as an immutable software signing ledger by structuring every entry into a Merkle tree, the same append-only data structure Google popularized for Certificate Transparency logs (Rekor is in fact built on Trillian, Google's Merkle-tree log storage engine). Each submitted entry receives a unique UUID, a monotonically increasing log index, and an "integrated time" showing when it was added, and it is hashed into a leaf of the tree. Periodically, Rekor publishes a Signed Tree Head — a cryptographically signed snapshot of the tree's current root hash and size — which acts as a checkpoint that anyone can compare against. Because each new leaf changes the root hash in a way that depends on every prior leaf, an attacker cannot quietly delete or edit a past entry without producing a root hash that no longer matches previously published checkpoints. This is what separates Rekor from a database with an audit column: the immutability is mathematically enforced and externally verifiable, not just a permissions setting an administrator could bypass.
What Is a Transparency Log Inclusion Proof and How Do You Verify One?
A transparency log inclusion proof is a compact set of Merkle tree hashes that lets you prove a specific entry exists at a specific position in the log without downloading or trusting the entire log. To verify one, a client takes the entry's leaf hash, walks the supplied audit path of sibling hashes up the tree, recomputes the resulting root hash, and checks that it matches a Signed Tree Head the log has published and signed. If it matches, the entry is provably part of the log's history; if the log operator tries to serve a forged or backdated entry, the recomputed root simply won't match any checkpoint anyone else has already seen. This is exactly what happens under the hood when npm's --provenance publishing flow or cosign verify runs: the tool doesn't just check that a signature is mathematically valid, it also fetches the Rekor entry and its inclusion proof from the public instance at rekor.sigstore.dev and confirms the entry is genuinely anchored in the log, not fabricated by a compromised registry or man-in-the-middle.
What Does Rekor Entry Verification Look Like in Practice?
Rekor entry verification means checking three things together: that the artifact's hash matches what's recorded in the log entry, that the signature is valid against the public key or Fulcio certificate stored in that entry, and that the entry itself carries a valid inclusion proof against the log's current checkpoint. The Kubernetes project is a concrete, widely cited example: since the 1.24 release cycle, official Kubernetes binaries and images have been signed with cosign, with every signature's metadata recorded as a Rekor entry. Anyone downloading kubectl or a kube-apiserver image can run cosign verify against the expected signing identity (the Kubernetes release service account) and get back a confirmed match against a specific, publicly queryable Rekor UUID — turning "we say this binary is official" into something a downstream consumer, auditor, or automated policy engine can independently check, rather than take on faith.
What Are Rekor's Limitations?
Rekor proves that a signing event happened and that its record hasn't been tampered with, but it does not prove the signer was trustworthy, that the OIDC identity behind the signature wasn't itself compromised, or that the signed artifact is free of vulnerabilities or malicious code. A stolen GitHub Actions token or a misconfigured OIDC trust policy can still produce a perfectly valid, perfectly logged Rekor entry for a malicious build — the log records what happened, not whether it should have happened. Rekor is also only as useful as the monitoring built around it: the log is public and append-only, but nothing forces an organization to watch it, so detecting an unexpected signing identity for your own packages requires actively querying and alerting on the log rather than assuming its existence alone provides protection. There are also practical considerations around log availability, retention, and the metadata exposure inherent in a public ledger, all of which matter for teams building verification into production pipelines.
How Safeguard Helps
Safeguard treats Rekor as a live signal, not a one-time checkbox. Instead of trusting that a Rekor entry exists and calling verification done, Safeguard continuously monitors the transparency log for the identities, repositories, and artifacts an organization actually owns, flagging signing events from unexpected OIDC identities, unfamiliar CI systems, or certificates that don't match approved release pipelines — the kind of anomaly that a stolen key or compromised build environment would produce. Safeguard also automates Rekor entry verification and inclusion proof checks as CI/CD gates, so a build can't be promoted to production unless its signature, certificate chain, and log inclusion all check out against the live tree checkpoint, not a cached assumption. Finally, Safeguard correlates Rekor signing metadata with SBOM and dependency data across the software supply chain, so security teams get a single view connecting what was signed, who signed it, when it was logged, and what's actually running — closing the gap between an immutable log entry existing somewhere and an organization actually knowing whether its software supply chain is behaving as expected.