Under SLSA, why is provenance signed by the build job itself worth little to a consumer?

## The threat this rung exists to close Take a concrete case. A managed-service vendor publishes a container image for you to run in your cluster. Their pipeline builds the image and, in the same job step, generates a provenance statement describing the build and signs it with a key that the step can read from its own environment. They hand you both, and the signature verifies. Ask the only question that matters: **who could have produced that statement?** Anyone who could influence that build - a maintainer with commit rights over the build definition, an attacker who compromised the runner, a malicious step pulled in as a build-time plugin. All of them can write a provenance statement saying the artifact was built from a clean revision by a well-behaved definition, and sign it with the same key. The statement is cryptographically valid and evidentially worthless, because the adversary you are defending against sits inside the signing boundary. This is the **self-issued provenance** problem, and the build track is arranged around it. ## The ladder, read as threat closure | Rung | Requirement, in one line | What it closes | | --- | --- | --- | | Build L0 | Nothing | Nothing | | Build L1 | Provenance exists, describes the build, and is distributed | Mistakes and casual misdescription; gives you something to diff | | Build L2 | A hosted build platform generates and signs the provenance | Forgery by anyone outside the platform, and post-build tampering, once someone verifies | | Build L3 | Hardened builds: isolated runs; signing material unreachable by user-defined build steps | Forgery from **inside** a build run - a malicious build definition cannot lie about itself | Read top to bottom, the ladder moves the signing authority steadily further from the party who could benefit from lying. At L1 the producer asserts. At L2 the platform asserts, so an attacker must compromise the platform rather than the build. At L3 the platform asserts in a way that the build it is running cannot influence, so compromising a single build no longer buys forged provenance for that build. ## What a consumer can still do with L1 provenance Do not overcorrect into "L1 is useless". Self-issued provenance is documentation, and documentation has uses: it records the build definition and inputs the producer says they used, which is enough to attempt a rebuild, to diff one release's build definition against the previous one, or to give an investigation a starting point. What it cannot do is carry weight **against an adversary**, because nothing binds the claim to a party the adversary could not impersonate. Treat it as a producer's statement of intent, not as evidence. ## Where the signature sits A provenance statement is an in-toto statement - a `_type`, a `subject` array where each entry names an artifact and its digest, a `predicateType` URI naming the shape of the claim, and the `predicate` carrying the build definition and run details. That payload travels inside a signing envelope that is signed separately from the statement it wraps. Verification therefore has two independent halves: 1. Check the envelope: is the signature valid, and **whose identity** is behind it? 2. Check the statement: does the subject digest match the bytes I hold, and do the predicate's builder identity and build definition match my policy? The self-issued case fails at step 1 for a reason that has nothing to do with cryptography: the signature is valid, and the identity behind it is the same party whose honesty is in question. This is why "is it signed?" is the wrong interview answer and "who signed it, and could the build have influenced that signer?" is the right one. ## The related confusion: signing artifacts is not L2 Teams often say "we sign our releases, so we are covered". Signing an artifact binds an identity to those bytes; it carries no description of how they came to be. SLSA L2 is about a **description of the build process** being generated and signed by the platform that ran the build. The object being vouched for is different: a blob versus a claim about a process. You can have artifact signing and still be at Build L0, if nothing describes the build at all. ## Answering the question well Name the threat (the signer is inside the blast radius), place the practice on the ladder (self-issued and self-signed is L1 territory), and say what each rung moves: L2 moves the signer to the platform, L3 puts the signing material where the build cannot reach it. Then finish with the consumer's action: pin the builder identity you expect in your verification policy, and reject statements signed by anything else - including the producer's own key.