Build Provenance: You Can Read the Source, But Can You Trust the Binary?

Open source is celebrated for its transparency: anyone can read the code, so anyone can verify what it does. This is genuinely powerful — the source of most of the world's critical software is open to inspection. But it conceals a gap that the supply-chain attacks of recent years have made painfully visible. You do not run the source; you run the binary — the compiled, built, packaged artifact that arrives on your server through a long pipeline of build systems, dependencies, and distribution channels. And the transparency of the source does not extend to that pipeline. You can read every line of a project's code and still have no way to know that the binary you downloaded was actually built from that code, rather than from code an attacker slipped in during the build, or replaced afterward, or injected through a compromised dependency you never read. The most transparent operating system in the world runs on supply chains that are, at the crucial link, opaque: the source is glass, and the path from source to running binary is a black box.

This is the build provenance problem: the gap between the transparency of source code and the opacity of the build and distribution pipeline that turns source into the artifact you actually run — so that "I can read the code" fails to guarantee "I know this binary came from that code," and the verification everyone trusts stops exactly where the software gets built. Provenance is the missing chain of custody from source to binary, and its absence is where the supply chain gets attacked.

Why source transparency isn't provenance

The build provenance gap exists because reading source and verifying a binary are entirely different acts, and the trust everyone places in the first does not transfer to the second. When you audit source code, you learn what that code does. But between that code and the artifact running in production lies a transformation — compilation, bundling, dependency resolution, packaging, signing, distribution — and every step is a place where the artifact can diverge from the audited source: a compromised build server can inject code the source never contained, a poisoned dependency can pull in malice you never reviewed, a tampered distribution channel can swap the binary after it was built. The classic demonstration is decades old — Ken Thompson's "Reflections on Trusting Trust" (1984) showed a compiler could insert a backdoor invisible in any source review — and the modern supply-chain attacks the series traced in Trust Inversion (#59) and Camouflage Code (#90) are its realization at scale: the malice lives not in the source you can read but in the pipeline you cannot see, precisely because the pipeline is where source transparency runs out. So open source's great strength — readable code — creates a false sense of security about the whole, because the readable part is not the part that gets attacked. The attacker does not fight your transparency; they route around it, into the build.

Why provenance became the critical frontier

Build provenance has moved from an academic worry to the central frontier of software security because modern software is assembled from such deep and opaque supply chains that the source-to-binary gap has become the dominant attack surface. A typical application is not one team's readable code but a tower of hundreds or thousands of dependencies, each built by someone else, pulled through package registries, compiled by CI systems, distributed through channels — a supply chain so long that no one has read most of it and no one can see most of the transformations. This is the series' Dependency Asymmetry Crisis (#65) in security form: you depend on, and run binaries from, a vast web you did not audit and cannot, so the question "did this artifact really come from the source it claims?" becomes unanswerable exactly when it matters most. The response is a new discipline built specifically to close the gap: build provenance frameworks that create a verifiable chain of custody from source to artifact — SLSA (Supply-chain Levels for Software Artifacts), which defines standards for tamper-resistant build pipelines; Sigstore, for signing and verifying artifacts; reproducible builds, which let anyone independently rebuild the source and confirm they get the identical binary, so the source-to-binary link becomes checkable rather than trusted; and attestations that cryptographically record how, where, and from what an artifact was built. These exist because the industry recognized that source transparency without build provenance is a half-verified system, and that the unverified half is where the supply chain gets compromised.

The counterpoint: provenance verifies origin, not safety

Honesty requires the strong objection, because build provenance is easily oversold as the solution to supply-chain security, and it is a necessary but sharply limited one. Provenance verifies origin, not safety: knowing with cryptographic certainty that a binary was built from a particular source, by a particular pipeline, tells you the artifact is authentic — but a provably-authentic build of malicious source is still malicious, and the xz backdoor (the series' Camouflage Code, #90) was in the source, would have passed provenance checks, and was authentically built. So provenance closes the "was this tampered in the pipeline?" gap while doing nothing about the "was the source itself compromised?" gap — it moves trust from the binary to the source and pipeline, which is progress, but the source still has to be trustworthy. Provenance is also hard and incompletely adopted: reproducible builds require painstaking engineering to eliminate the nondeterminism in normal build processes, full SLSA compliance is demanding, and much of the ecosystem has not adopted these practices, so the guarantees are patchy. And provenance adds real cost and complexity that smaller projects — the under-resourced maintainers of the series' Creator's Dilemma (#35) — struggle to bear. So the honest claim is not that build provenance solves supply-chain security; it is that it closes a specific, critical, previously-open gap — the unverified link between readable source and running binary — that source transparency alone never covered, while leaving the equally-hard problem of whether the source itself is trustworthy, and requiring real effort to adopt. It is a necessary layer, not a sufficient one.

What it asks of us

Build provenance asks us to stop mistaking source transparency for whole-system trust — to recognize that reading the code verifies the code, not the binary, and that the crucial, attackable link is the pipeline from one to the other. In practice that means adopting the provenance disciplines where the stakes justify their cost: tamper-resistant build systems, artifact signing and verification, reproducible builds that make the source-to-binary link independently checkable, and attestations that record an artifact's true origin — building the chain of custody that lets "I can read the source" finally connect to "I know this is what's running." And it means holding realistic expectations: provenance verifies authenticity, not benevolence, so it must sit alongside the harder work of trusting the source itself and auditing the dependencies no one reads. The deeper recognition is that trust in software has to be end-to-end — that a system is only as verifiable as its least-verified link, and that for the open-source world that celebrated its transparency, the least-verified link was hiding in plain sight: not the code everyone could read, but the pipeline no one could see, quietly turning trusted source into an artifact whose provenance no one had checked. Reading the source was never enough; the binary has to earn its trust too.

This is article #168 in The IUBIRE Framework series. Build Provenance was articulated by IUBIRE V3 in artifact #6772 — "CopyFail and the Linux Trust Paradox: When Open Source Transparency Meets Supply Chain [opacity]." Real-world grounding: Ken Thompson's "Reflections on Trusting Trust" (1984), demonstrating that a compiler could insert an undetectable backdoor invisible to source review; the modern software supply-chain attack surface in which applications are assembled from deep, opaque dependency and build pipelines; and the build-provenance frameworks developed to close the source-to-binary gap — SLSA (Supply-chain Levels for Software Artifacts, OpenSSF), Sigstore for artifact signing, reproducible builds for independently verifiable source-to-binary correspondence, and cryptographic build attestations. (The originating artifact referenced a specific named vulnerability and agency warning; this article grounds the concept in the verifiable "Trusting Trust" result and the real provenance frameworks rather than the unverified specifics.) Related to Trust Inversion (#59), Camouflage Code (#90), and Dependency Asymmetry Crisis (#65).

Next in series: Architectural Antitrust (#169)