A .deb build's provenance carries no resolvedDependencies — what may a verifier conclude?

## What the field is for `resolvedDependencies` lives inside `buildDefinition` and holds an unordered collection of the artifacts a build needed while it ran. Each entry is a resource descriptor: a URI, a digest map, optionally a name or media type. For a pipeline producing an OS package, the natural candidates are the base image the build ran in, the compiler and packaging toolchain, the upstream source tarball that was fetched, and the package feeds consulted for build-time dependencies. The word *resolved* is the point. `externalParameters` may say "build the ref `release-3.2`" or "use the config at this path"; `resolvedDependencies` records what those references actually turned into — the concrete digest that was fetched. That is why a listed entry is genuinely useful evidence: it converts a mutable reference into a fixed identity that you can compare against an expectation. ## Why absence is not a claim The field is **optional**, and the specification is explicit that the collection **may be incomplete**. The build track does not oblige a platform to enumerate everything a build touched — doing so is genuinely hard, since a build can reach for files through paths no framework observes. So three states exist and only one of them is informative: | What you see | What it means | | --- | --- | | entries present | those specific artifacts were consumed; compare their digests | | empty array | nothing stated — not a claim that nothing was consumed | | key absent | nothing stated — identical practical meaning | The temptation to distinguish empty from absent is strong and should be resisted. Neither is a positive assertion, and a rule that accepts an empty array as "no third-party inputs" is inventing evidence. Every build consumes a toolchain at minimum; an empty list is a statement about the emitter's diligence, not about the build. ## What this costs you in a fleet scenario Suppose you operate a fleet that installs OS packages built by an internal distro pipeline, and you want to answer a question about a class of risk: could a compromised upstream mirror have fed a substituted source tarball into these builds? If `resolvedDependencies` lists the tarball's digest, you have a strong partial answer — you can compare that digest against the one the upstream project publishes. If the field is empty, you have nothing from the provenance and must fall back to other evidence: whether the fetch step verified a digest itself, whether the mirror was authenticated, whether the base image came from an approved registry. Notice the asymmetry, because interviewers probe it. Present entries can **falsify** an expectation — a base image digest that is not on your list is a hard fail. Absent entries can never **confirm** one. A verification design should therefore treat this field as a source of disqualifying evidence, not as a completeness proof. ## Direction and neighbours Two confusions are worth heading off. First, direction: `resolvedDependencies` is what went **into** the build; `byproducts` in `runDetails` is what came **out** alongside the artifact, such as logs and reports. Putting a build log in the dependency list is a common misreading of a real document. Second, scope: this is a record of what the build *consumed*, which is not the same as what the artifact *contains*. A compiler and a test harness are consumed but do not ship; vendored code may ship without appearing here at all. If your question is "what is inside this package", the provenance predicate is the wrong document to be reading, and treating the dependency list as an inventory of shipped components is how teams end up scanning the wrong set. ## What a good answer sounds like "Present entries I compare; missing entries I treat as unknown and note as a gap in what the platform states. If my policy actually requires knowing every input, that requirement has to be met by the build platform's documented guarantees for this build type, not inferred from an empty array."