TL;DR: The signer generates an ephemeral key pair, proves its identity with an OIDC token (a person or a CI workflow), and the Fulcio CA issues a certificate valid for about ten minutes binding the key to that identity. The signature and certificate are recorded in the Rekor transparency log, and the private key is discarded. Verifiers check the signature, the chain to Fulcio, the exact expected identity and issuer, and the log entry proving the signature was made while the certificate was valid. The log adds public visibility of every signing event, tamper-evident history and timestamping; the residual risks are identity-provider compromise and loose verification policies.
How to approach it
Name the problem Sigstore solves (long-lived keys), walk through the four actors (signer, OIDC provider, Fulcio, Rekor), explain verification including identity pinning, then the log's contributions and the risks that remain.
A strong answer
Signer (CI or person)
OIDC provider
Fulcio CA
Rekor log
- Prove identity
Signer (CI or person) to OIDC provider
1Get identity token
1. Get identity token
Person or specific CI workflow
Signing flow.
- The signer (often a CI job) creates an ephemeral key pair.
- It obtains an OIDC token from its identity provider; in CI this describes the repository, workflow and ref.
- Fulcio verifies the token and proof of key possession and issues a short-lived certificate embedding the identity.
- The signer signs the artifact, uploads the signature and certificate to Rekor, and receives a signed log entry with an inclusion proof.
- The private key is discarded.
Verification. Check the signature; verify the certificate chains to the Fulcio root; require that the certificate's identity and OIDC issuer match policy (for example: issuer GitHub Actions, workflow release.yml in acme/payments on a protected tag); and verify the Rekor entry, whose timestamp must fall inside the certificate's validity window.
What the transparency log adds.
- Monitoring: maintainers and organisations can watch the log for signatures made with their identities that they did not expect.
- Tamper evidence: Merkle-tree logs make it detectable if entries are altered or different histories are shown to different verifiers.
- Durable timestamps: a ten-minute certificate stays verifiable for years because the log proves when signing happened.
Remaining risks.
| Risk | Mitigation |
|---|---|
| Account or CI token compromise lets an attacker sign as you | Phishing-resistant MFA, restricted CI triggers, protected branches and tags |
| Verifiers accept any identity | Pin repository, workflow, ref and issuer in policy |
| Compromised build inputs | Pair with SLSA provenance and dependency pinning |
| Identity exposure in a public log | Use workload identities for automated releases |
Ecosystem (checked November 2026). Cosign for containers; npm provenance and PyPI attestations; Kubernetes admission policies; and OpenSSF model signing, which uses Sigstore by default.
What interviewers probe next
- "Can a fork of your repository produce a valid signature?" Yes, with its own identity; that is why policy must pin the exact repository and ref.
- "What if Rekor is unavailable?" Signing can be delayed or use offline bundles; verification can use the bundled inclusion proof without contacting the log.
- "Why is this better than a GPG key in CI secrets?" No long-lived secret to leak, identity tied to the workflow, and every signature publicly auditable.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A team adopts Sigstore keyless signing for container images and models built in CI, and asks what actually protects them.
Start here
How does keyless signing work?
What replaces a long-lived signing key?
The signer generates an ephemeral key pair and proves its identity with an OIDC token, from a person or a CI workflow. The Fulcio CA issues a certificate valid for about ten minutes binding the key to that identity. The signature and certificate are recorded in the Rekor transparency log, and the private key is discarded.
Carry it forwardShort-lived certificates bound to OIDC identities.
Weak answerThinking 'keyless' means no keys at all.
Constraint changes
Why does the transparency log matter?
How would you know someone signed as you?
It gives public, tamper-evident visibility of every signing event and proves when a signature was made, so verifiers can confirm it happened while the short-lived certificate was valid. It also lets you monitor for unexpected signatures under your identity.
Carry it forwardThe log timestamps signatures and exposes misuse.
Weak answerSkipping log verification.
Constraint changes
What must verifiers check?
Would any GitHub user's signature pass your check?
The signature, the chain to Fulcio, the exact expected identity (for example a specific repository and workflow) and issuer, and the log entry proving the signature was made during the certificate's validity. Checking only that 'some valid signature exists' accepts anyone's signature.
Carry it forwardVerification must pin exact identity and issuer.
Weak answerVerifying signature validity without identity.
Constraint changes
What are the residual risks?
What can an attacker do inside your release workflow?
Compromise of the identity provider or the CI workflow that holds the identity, and loose verification policies. If an attacker can run code in your release workflow, they can obtain a valid signature. Protect the workflow and pin identities tightly.
Carry it forwardKeyless shifts trust to identities and workflows.
Weak answerAssuming keyless signing makes build compromise harmless.
Constraint changes
How would you monitor for misuse?
Which log entries would surprise you?
Watch the transparency log for entries under your identities, alert on signatures from unexpected workflows, branches or times, and reconcile them with release records. Unexpected entries suggest a compromised workflow or identity.
Carry it forwardMonitor the log for unexpected signing under your identity.
Weak answerTreating the log as write-only.
Now defend it
How would you deploy keyless signing safely?
Sign from specific CI workflows with OIDC identities; verify signature, Fulcio chain, exact identity and issuer, and Rekor inclusion at every consumption point; harden the release workflows that hold signing identity; monitor the transparency log for unexpected entries; and combine signing with provenance so consumers know what was built, not only who signed.
How it's scored
Weak: Describes it as "signing without keys" with no mechanism.
Hire: Explains OIDC, Fulcio's short-lived certificates, Rekor, and how expiry is handled.
Strong Hire: Insists on identity-pinned policy, explains monitoring and tamper evidence, and lists residual risks with mitigations.
Common mistakes
- Verification that only checks "signed by Sigstore".
- Allowing pull-request workflows to sign releases.
- Assuming keyless signing makes the build trustworthy.