Rekor is the most quietly important piece of the sigstore stack. Cosign gets the attention because developers interact with it directly, and Fulcio gets the explanation because keyless signing is the conceptual novelty. But the security property that makes the whole system worth running, that a signature cannot be repudiated or backdated, lives in Rekor's append-only transparency log.
This post walks through how Rekor works in 2026, the design decisions that have aged well, and the places where operating verification against Rekor at scale is more nuanced than the marketing diagrams suggest. We will assume you have signed something with cosign before but have not spent much time on what happens after the signature is uploaded.
What does Rekor actually store?
Rekor stores entries in a tamper-evident Merkle tree, with each leaf representing a signed statement: a hashed artifact, a signature, and the certificate or public key used to produce it. The tree is append-only and witnessed, which means that once an entry is included at index N, no operator can remove it, reorder it, or insert an earlier entry without producing a fork that external witnesses will detect. The cryptographic guarantee is strong, but it is worth being precise: Rekor does not store secrets, and it does not vouch for the meaning of the entry, only for the fact that it was published at a specific tree size and time.
The entry types Rekor accepts have grown from the original hashedrekord to include intoto, dsse, and several specialized formats for SBOM and VEX attestations. Each type has its own schema and validation rules, but they all reduce to the same primitive: a content hash plus a signature plus an identity, committed to the log.
How do inclusion proofs work in practice?
When you sign with cosign, the client uploads the bundle to Rekor and receives back a signed checkpoint plus an inclusion proof: a list of hashes that, combined with your entry's hash, reconstruct the root of the tree at a known size. The verifier later replays the proof to confirm your entry is part of the committed tree.
The subtlety that catches teams is that holding a valid inclusion proof at tree size N does not, by itself, prove that the tree has not been forked. To get that guarantee, you need a consistency proof between the tree size at which your entry was witnessed and the tree size at which you are verifying, and you need to trust that at least one external witness has signed off on both checkpoints. The current sigstore deployment uses multiple independent witnesses, and the standard verification flow now requires checking that the checkpoint you received is co-signed by a quorum. If you are running verification in production and not checking witness signatures, you are taking on a trust assumption that the design specifically tried to remove.
What changed with the 2025 witness diversity push?
Through 2025 the project pushed hard on witness diversity, motivated by the observation that a single-operator log is only as trustworthy as that operator. The result is a witness cohort with operators across multiple jurisdictions, multiple organizational types, and multiple software stacks. The verification policy in cosign 2.4 and later defaults to requiring a checkpoint signed by at least two witnesses, with the specific roots configured via the trust root file distributed through TUF.
This matters operationally because the failure mode shifted. In the single-witness era, witness downtime was a verification outage. With a quorum policy, you tolerate one or two witnesses being slow or unreachable, but you also have to be more careful about clock skew and witness lag. The current cohort typically witnesses within seconds, but bursty load can stretch that to tens of seconds, and verifiers that require very fresh checkpoints will see intermittent failures during traffic spikes.
How does Rekor scale to billions of entries?
The original Rekor was designed for hundreds of millions of entries, and the project has been migrating to a redesigned backend, sometimes called Rekor v2 in the community, to handle the billions of entries that cloud-native CI workloads produce. The design preserves the public Merkle tree property but separates the high-throughput append path from the query path, and it uses a tiled tree format that allows witnesses and verifiers to fetch only the slices they need rather than walking the full structure.
The migration has been carefully sequenced so that older signed bundles remain verifiable against both the legacy and new infrastructure. As an operator, the practical implication is that long-term verification of an artifact signed in 2023 should still work in 2030, but you should keep your verification client current and avoid pinning to old trust roots that may not include witnesses for the v2 deployment.
What does verification look like in a CI pipeline?
In a modern CI pipeline, verification is typically a single cosign verify call against the artifact, with policy expressing the required Fulcio certificate identity, the expected OIDC issuer, and the witness quorum. The verifier fetches the bundle from the registry, checks the certificate chain back to Fulcio, validates the signature, fetches the Rekor inclusion proof, replays it against a witnessed checkpoint, and confirms that the certificate's identity claims match the policy. All of that happens in well under a second for a single artifact.
The operational rough edge is policy authoring. The cosign policy language has matured, but expressing "this image must be signed by GitHub Actions running our specific reusable workflow on the main branch of our specific org" still takes some care, and the failure modes when the policy is too loose are not visible until something goes wrong. Treat policy files as load-bearing code, review them, and test them against intentionally bad inputs.
How Safeguard Helps
Safeguard treats Rekor entries as first-class evidence in the supply chain inventory. Every ingested artifact is checked for a corresponding signed attestation, the inclusion proof is replayed against a quorum of witnesses, and the Fulcio identity is matched against expected build identities for the project. Griffin AI correlates signing identity with reachability and CVE findings so you can quickly answer who built the affected component and from which source. Policy gates block deployments of artifacts without valid sigstore attestations, and our zero-CVE base image program ships everything signed and Rekor-witnessed by default. TPRM scoring incorporates supplier signing posture, surfacing vendors who have not yet adopted transparency-log-backed signing.