A firmware binary carries a valid vendor signature: what does that prove, and what can it not tell you?
answer
- Three different documents, three different questions
- Bytes and identity, nothing else
- Contents need an inventory instead
- Origin needs a provenance statement
- Wax seal, not a packing list
basics
~20 sA valid signature proves only that the bytes are unchanged since signing and that a named identity vouched for them. It says nothing about which components are inside the binary or which source revision and build produced it.
solid answer
~50 sA signature is a claim about *who* and about *these exact bytes*. Verifying it tells me the artifact has not been altered since it was signed and that a particular identity stood behind it. That is all. It does not enumerate what is inside the binary, so it cannot tell a hospital's clinical-risk board which cryptography library version ships in the firmware; that is what a component inventory, an SBOM, is for. It also does not describe how the artifact came to exist, so it cannot say which source repository, branch or revision was built, or which builder ran the build; that is what a build provenance statement records. The three claims answer different questions: a signature answers *who vouches for these bytes*, an SBOM answers *what is inside*, provenance answers *how it came to be*. Asking a signature the other two questions is the classic mistake.
go deeper
Be ready to state the two things a signature establishes - unchanged bytes and a signer identity - and to name the other two documents by the question they answer. Recalling the who / what / how split is the whole ask at this level.
An interviewer expects you to explain why a signature is blind to contents and origin: it is computed over a digest of finished bytes, after the fact. Explain how an inventory and a provenance statement are bound to that same digest so they describe the artifact you actually hold.
Show the operational reflex: when someone offers 'it's signed' as an answer, restate which question is being asked and name the document that answers it. Be able to say what you would demand from a supplier and what you would record as a finding when they cannot produce it.
Own the policy angle. Decide which artifact classes must carry which claims, who is accountable for producing them, and what happens at intake when one is missing. The tradeoff is supplier friction against the ability to answer composition and origin questions later under time pressure.
## 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*.
- So if the vendor also ships an SBOM, is the contents question settled?Only if the SBOM is tied to the artifact you hold. An inventory document on its own is a text file that could describe a different build. It becomes evidence when it is bound to the artifact's digest and signed, so you can check that this inventory belongs to these bytes. The signature is what gives the inventory weight; the inventory is what gives the signature something to say about contents.
- The vendor says a signed artifact is enough for a safety review. How do you push back?I would separate the questions. The signature answers integrity and authorship, and I accept it for that. The review's questions are composition and origin, and I would ask for the two documents that answer them: a component inventory so we can see which libraries and versions ship in the image, and a build provenance statement naming the source revision and builder. If the vendor cannot produce either, that gap itself is the review finding.
- Can you reconstruct the component list from the binary instead of asking for an SBOM?Partly, and unreliably. Analysing a binary can recover some embedded version strings and recognisable library fingerprints, but statically linked, stripped or vendored code frequently vanishes, and you learn nothing about build-time inputs. It is a fallback when a supplier will not produce an inventory, not a substitute for one generated by the build that has the full dependency graph in front of it.
A signature is a wax seal on an envelope: it shows whose ring pressed it and that nobody has opened the envelope since. It tells you nothing about what is inside or where it was packed.
saying these in an interview costs you the question
- Says a valid signature means the artifact is free of vulnerabilities
- Thinks the signature lists the components inside the artifact
- Believes a signature identifies the source repository or commit
- Treats signature, SBOM and provenance as three names for one thing
- Assumes an unsigned SBOM shipped nearby proves the contents