Your project signs releases with Sigstore keyless signing — how do you detect a Rekor entry made under your identity that you never created?

## Why monitoring is the point, not an extra Keyless signing binds a signature to an identity — a maintainer's account at an OIDC provider, or a specific CI workflow. Anyone who can obtain that identity for a few minutes can obtain a certificate and produce a signature that verifies perfectly. Stolen session cookies, a compromised runner, a misconfigured workflow that lets a fork trigger the release job, an IdP account without strong second-factor: all of these give an attacker a legitimate identity rather than a forged key. No cryptography stops that. What a transparency log changes is who can find out. Because every entry is public and permanent, the legitimate owner of an identity can watch for entries claiming it. Consider a maintainer of a widely-depended-on package who runs such a monitor: when an entry appears under her identity that corresponds to no release she made, she learns of the compromise within minutes — before the artifact has propagated, and hours before anyone downstream would have noticed anything wrong. Without the log, the first signal is a user report about strange behaviour, days later. This is the sense in which Sigstore's guarantee is **detective**. Signing prevents an unsigned artifact from being accepted. The log does not prevent a validly signed malicious artifact; it guarantees that one cannot be created *quietly*. ## Building the monitor A workable monitor has four parts. **1. Know your identities.** Write down the exact set of identities permitted to sign for your project: the release workflow of the release repository, and any human maintainers still allowed to sign directly. This list is small and should be under change control — an identity you forgot about is a blind spot, and it is also an argument for signing only from workload identities in CI rather than from personal accounts. **2. Consume new entries.** The log exposes its entries and lets you search them; Sigstore also publishes an open-source monitor for exactly this job, so most teams run that rather than writing their own. Whichever route, the monitor tails the log as it grows and filters for the identities on your list. Polling at release cadence is not enough — the value is in the latency, so run it continuously. **3. Reconcile against ground truth.** A hit on your identity is expected most of the time; it is your own releases. The alert condition is a *mismatch*, which means the monitor needs an authoritative record to compare against: the digests you published, the tags, the approximate times. In practice this is the release system's own database or your artifact registry. Any entry under your identity with a digest you cannot account for is the alert. **4. Watch the log itself.** Alongside identity monitoring, verify consistency proofs between the checkpoints you have seen. That catches a log that rewrote or omitted history, and it is why the ecosystem also depends on independent witnesses comparing checkpoints — a log that showed one view to you and a different view to your consumers would otherwise be undetectable from a single vantage point. ## Tuning it so it stays useful The failure mode of any such monitor is noise. Two things keep it quiet. First, keep the signing identity set narrow: one workflow signing everything beats six maintainers each able to sign, both for security and for the false-positive rate. Second, make reconciliation automatic against a system of record rather than a human eyeballing a feed — a manual review of a busy release train is abandoned within a month. Set the alert severity high. An unexplained entry under your release identity is not a ticket for the next sprint; it means someone else currently holds, or recently held, the ability to publish as you. ## The complementary use: the forensic record The same property that makes monitoring possible makes the log the best evidence in an incident review. When a build runner is found to have been compromised for a six-hour window, the question everyone asks is *what else was signed as us during that window?* The log answers it completely by construction: it is append-only, it is time-ordered, and the attacker cannot have removed their own entries from it. Internal build logs can be tampered with by whoever held the runner; the public log cannot. That property — audit truth that survives the compromise of the system being audited — is worth as much as the detection. ## What monitoring is not It is not access control, and it does not replace hardening the identity: strong authentication on maintainer accounts, narrow permissions on the release workflow, and restricting who can trigger it are the preventive layer. It is also not the response plan; finding a rogue entry is the beginning of an incident, and what you do next — containment, notifying consumers, re-issuing — is a separate discipline. Monitoring's job is to make sure the incident starts on your terms, in minutes, rather than on the attacker's, in weeks.