A firmware binary carries a valid vendor signature: what does that prove, and what can it not tell you?

## The three claims, one line each When an artifact is shipped with "security evidence", that evidence is almost always one of three different documents, each answering a different question: | Claim | The question it answers | Core content | |---|---|---| | Signature | Who vouches for **these exact bytes**? | A signer identity bound to a digest of the artifact | | SBOM (component inventory) | **What is inside** the artifact? | The components and versions it is composed of | | Build provenance | **How did it come to be**? | Source repository and revision, builder, build entry point | Every interview confusion in this area comes from asking one of them a question that belongs to another. ## What a signature actually asserts A signature is computed over a digest of specific bytes. Verifying it establishes two facts and no others: 1. **Integrity** - the bytes you have are the bytes that were signed. Change one bit and verification fails. 2. **Signer identity** - some identity (a release key, an organisation, a build system) put its name to those bytes. Notice what is missing from that list. The signature does not describe the artifact's contents, because it never inspected them; it treated the artifact as an opaque blob and hashed it. It does not describe the artifact's history either, because signing happens *after* the artifact exists and is indifferent to how it got there. ## The scenario that makes it concrete A medical-device supplier ships a firmware image to a hospital's biomedical engineering team. The download page shows a valid vendor signature, so integrity in transit is settled. Then the clinical-risk board asks two questions: - *"Which version of the cryptography library is inside this firmware?"* The signature cannot answer it. Nothing in the signature describes the composition of the image. Answering it requires an inventory of the firmware's components - an SBOM - produced by the supplier from the build (or, failing that, reconstructed by analysing the binary, which is far less reliable). - *"Which branch and revision of the vendor's source was this built from?"* The signature cannot answer that either. Answering it requires a build provenance statement: a claim, bound to the firmware's digest, that names the source repository and revision, the builder that executed the build, and the entry point it was invoked with. The device is safety-critical, so "the vendor signed it" is a perfectly good answer to *did anyone tamper with the file after the vendor produced it* and a non-answer to both of the board's actual questions. ## Why the confusion is so common Signing is the oldest and most visible of the three practices, so people generalise it into an all-purpose stamp of quality. Three habits reinforce that: - Release pages present the signature as *the* security artifact, with nothing next to it. - The word "verified" reads like a verdict about the artifact rather than a statement about bytes and an identity. - Signatures are often the only one of the three a consumer has ever been asked to check, so it becomes the mental default for every question. A useful correction: a signature is closer to a **wax seal on an envelope** than to a **packing list** or a **factory record**. The seal proves the envelope has not been opened and shows whose ring pressed it. It says nothing about what is inside or where it was assembled. ## What each of the three cannot answer - A **signature** cannot say what components are inside, and cannot say which source or build produced the artifact. - An **SBOM** cannot say that this inventory belongs to the bytes you actually hold unless it is bound to their digest and signed, and it cannot say where those bytes came from. - **Provenance** cannot enumerate the shipped contents; it describes the build that produced the artifact, not the artifact's composition. They are complementary, not competing, and they are usually distributed together: the inventory and the provenance are themselves signed and bound to the artifact's digest, so the signature is what makes the other two trustworthy rather than merely present. ## What to say in an interview State the three-way mapping first (who / what / how), then name the specific limit the question is probing. If someone hands you an artifact and says "it's signed", the right follow-up questions are *signed by whom, over which digest, and what else did they publish alongside it*.