What does an image-signature verifier such as cosign or Notation need before it can verify anything?
answer
- Two inputs: what, and whose
- Signed by anyone is not a control
- Key, keyless identity, or CA trust store
- Identity rides in the certificate
- The digest is what gets vouched for
basics
~20 sA reference to the artifact, ideally its digest, plus a trust anchor: a public key, an accepted keyless identity and issuer, or an x.509 trust store. Without one, a verifier can only report that some signature exists.
solid answer
~50 sEvery verifier needs two inputs: which artifact to check, and whose signature counts. With cosign you either pass a public key, or, for a keyless Sigstore signature, state the certificate identity and OIDC issuer you expect, because the identity lives in the signing certificate. Sigstore's policy-controller says the same thing declaratively in a `ClusterImagePolicy`: an `authorities` entry is either a key or a `keyless` block listing accepted issuer and subject. Kyverno's `verifyImages` rule uses `attestors` in the same shape. Notation reads a trust policy instead: a trust store of x.509 CA certificates, the trusted certificate identities allowed under it, and a verification level. The underlying point is identical everywhere. `Is it signed?` is not a security question, because anyone can sign anything. The question is whether it is signed by the identity you expect, over the digest you are about to run.
go deeper
Be ready to say the two inputs out loud: which artifact, and whose signature counts. Know that a public key, an accepted keyless identity, and an x.509 trust store are three ways of supplying the second one.
Explain where identity lives in each model, keyless certificate versus CA-chained certificate subject, and be able to point to the field that carries it in a ClusterImagePolicy authority, a Kyverno attestor, and a Notation trust policy.
Show you separate no-signature-found from signature-by-wrong-identity in operations, and that you know a missing referrer on a mirror looks exactly like an unsigned image. Say what your policy does on each.
Own the argument that presence-only signature checks are theatre that costs real engineering effort, and be able to justify what the organisation gets for constraining identity versus what it costs in vendor and legacy image exceptions.
## The three claims, and which one a signature makes An artifact can carry three very different kinds of statement. An SBOM says **what is inside**. Provenance says **how it came to be**. A signature says **who vouches for it**. Verification implementations are built around the third claim, and everything below follows from that: a signature check can tell you an identity stood behind a specific set of bytes, and nothing else. ## Two inputs, always Whatever the implementation, a verifier needs: 1. **The subject** — which artifact. Ideally a digest (`sha256:...`), which is content-addressed: the digest *is* the bytes. A tag is a mutable pointer, so verifying a tag means verifying whatever that tag pointed at when the verifier looked. 2. **A trust anchor plus an expected identity** — the material that decides whose signature counts. Miss the second and you have built a control that passes for any attacker who can also sign. Getting a signing identity is not hard; obtaining *your* identity is the hard part, and that is exactly the part an unconstrained policy skips. ## How each implementation expresses the trust anchor **cosign (CLI).** With a key, you supply the public key. With Sigstore keyless signatures, the signer's identity is carried in a short-lived certificate, so you must tell cosign the certificate identity and the OIDC issuer you accept; verification also checks the signature was recorded in the transparency log, which is what establishes that signing happened while the certificate was valid. **Sigstore policy-controller.** A `ClusterImagePolicy` matches images by glob and lists `authorities`. Each authority is either a `key` or a `keyless` entry whose `identities` name the accepted issuer and subject (exact or regex). Multiple authorities let one policy accept more than one signer. **Kyverno.** A `verifyImages` rule matches `imageReferences` and lists `attestors`, whose entries hold public keys, a keyless issuer/subject pair, or certificate material. The rule can also select the signature style being verified, so both Sigstore-format and Notary-format signatures are expressible. **Notation.** Verification is driven by a trust policy: `registryScopes` say which repositories the rule applies to, `trustStores` name a store of x.509 CA certificates, `trustedIdentities` restrict which certificate subjects under that CA are acceptable, and a verification level decides how strictly the individual validations (integrity, authenticity, expiry, revocation) are enforced. There is no OIDC identity here at all — trust chains to a CA you installed. ## Where the signature is fetched from The verifier also has to *find* the signature. cosign has historically stored a signature as a separate artifact under a tag derived from the subject digest; Notation attaches signatures as OCI **referrers** of the subject manifest. That difference matters operationally: referrer-based discovery needs a registry that implements the referrers API, and a mirror or pull-through cache that silently drops referrers will make signed images look unsigned. ## What a passing check does and does not prove It proves: a signature over *this digest* validates against the trust material you supplied, and (where identity is constrained) the signer matched the identity you named. It does **not** prove the image is free of vulnerable components, that it was built on a hardened builder, or that the source was reviewed. Those are content and provenance claims, and answering them needs attestations plus a verifier able to read the attestation body — a different capability, which not every implementation has. ## The two failure modes to keep apart - **No signature found** — often infrastructure, not attack: the wrong repository, a registry that dropped referrers, a mirrored copy, or an image re-pushed without signing. - **Signature found but identity rejected** — the interesting one: someone signed, but not the identity you accept. Treat these differently in your logs, because collapsing them into one 'verification failed' makes an actual identity mismatch look like a flaky registry. Finally, none of this changes anything unless something refuses to run the artifact when the check fails. A verifier that logs a failure and admits the workload has produced a report, not a control.
- A policy accepts any image carrying a valid Sigstore signature, with no identity constraint. What has that bought you?Almost nothing against a real attacker. It proves a well-formed signature exists over the digest, but anyone can obtain a signing identity and sign their own image, so the control passes for the attacker too. It does still catch unsigned images and accidental drift from unsigned mirrors, which is why teams mistake it for progress.
- Where do these verifiers actually find the signature for an image?cosign has historically published a signature as a separate artifact under a tag derived from the subject digest; Notation attaches it as an OCI referrer of the subject manifest. Referrer-based discovery needs a registry that supports the referrers API, and a mirror or cache that does not copy referrers will make correctly signed images verify as unsigned.
- Can any of these verifiers tell you whether the image contains a vulnerable library?Not from the signature. A signature says who vouched for the bytes, not what is inside them. To answer a content question you need a component inventory attached as a signed attestation, and a verifier capable of reading the attestation body rather than only checking that it is signed by an acceptable identity.
A passport check has two halves: the document must be genuine, and the name on it must be the person you were expecting. A verifier with no identity constraint only does the first half.
saying these in an interview costs you the question
- Treats any valid signature as trustworthy without checking who signed
- Says the signature tells you what is inside the image
- Assumes Notation and cosign accept the same trust material
- Verifies a mutable tag and assumes the digest is covered
- Calls a verification failure that only logs and admits an enforced control