What Is Sigstore Rekor and How Do You Verify an Entry?

Rekor is a transparency log for software supply chain metadata, and it is the signature transparency component of Sigstore. When someone signs an artifact, a record of that signature can be written to Rekor. Anyone can then query the log, check an entry exists, and audit that the log has only ever grown.

What does Rekor actually store?

According to the Sigstore documentation, Rekor provides an immutable, tamper-resistant ledger of metadata. The records are signed metadata that maintainers and build systems write, which others can query to make trust decisions. The log does not hold your artifact itself. It holds a record that a signature over a given artifact digest was made, by which key or identity, and when it was logged.

The command line client can retrieve entries by public key or by artifact, create and verify entries, and check the log's integrity.

Why does a public log matter?

A signature alone says "someone with this key signed this." It does not say whether the signature was made last week or after the key leaked, and it does not let you notice that a different signature was quietly issued for the same name.

A public, append-only log changes that. If every signing event is recorded, a maintainer can watch the log for entries made with their own identity and notice ones they did not make. Consumers can require that a signature is present in the log before trusting it. The log is built on a verifiable data structure, so auditors can check consistency and confirm that entries were not changed or removed.

How does verification work?

Three separate checks sit behind the word "verify," and it helps to keep them apart.

1. The signature is valid for the artifact digest and key or certificate.
2. An entry exists in the log for that signature. The client can ask the log for an inclusion proof for the entry.
3. The log itself is behaving. Auditors check consistency over time so the log stays append-only.

Sigstore documentation says the public instance is rekor.sigstore.dev, with an availability objective of 99.5 percent and an on-call team. It also lists monitoring options: a reusable GitHub Actions workflow for the Rekor monitor, identity monitoring, which the docs describe as a work in progress with limited identities and entry types, and a tool called omniwitness for auditing the log.

What a log entry does not prove is that the code is safe. It proves that a specific signature was recorded. A malicious maintainer can sign malicious code and log it perfectly.

What is a realistic way to use it?

Here is a constructed scenario. Your team publishes an internal library and signs each release in CI. You set up identity monitoring so you are told whenever a new entry appears for your CI identity.

One morning there is an entry at a time no pipeline ran. That is exactly the signal a transparency log exists to give you: either a pipeline you forgot about, or a stolen credential. Without the log, that signing event would have left no public trace.

On the consuming side, your deploy step refuses an artifact unless it can show a valid signature and a matching log entry for the expected identity. That turns "is this the build we meant to ship?" from a hope into a check.

How to check or apply this

1. Decide which identity should sign your releases, and write it down.
2. Sign release artifacts in CI and let the signing tool record the entry in the log.
3. Set up monitoring for entries that use your identity and route alerts to the release owner.
4. In deployment, verify the signature and look up the entry, not only the signature.
5. For artifacts you consume, define which signer identities you accept for each dependency.
6. Keep a normal dependency inventory too. A log tells you who signed what; it does not tell you which of your dependencies have known vulnerabilities.

For that last point, Safeguard's dependency scanning and the free in-browser scan at gold.safeguard.sh/scan (up to 100 dependencies) cover the inventory side.

Quick check

Sources

• Sigstore documentation, Logging overview (Rekor)

Last reviewed: 18 October 2026.