A binary passes every test. The build is clean, the scans are green, the signatures verify, and the SBOM is complete. The code deploys to production, and nobody has any reason to doubt it. There is exactly one question none of that evidence answers: how did this code get here? A clean compile is a statement about the present. Provenance is a statement about the past — and the past is where supply chain attacks live.
Code provenance is the forensic history of an artifact: the record of where its source came from, who committed it, what it was built from, by which process, and what was produced. It is the difference between knowing that a binary is authentic and knowing that it is honest. Modern supply chain security is, in large part, the discipline of reconstructing that history — and the archaeology of artifacts whose history was never recorded.
Why "It Compiles" Is Not Enough
The compile is the moment of trust in the software lifecycle. Before the compile, code is text. After it, code is software — signed, shipped, deployed, trusted. But the compile itself is a transformation, and transformations can be the attack:
- The compiler can be compromised. The classic Ken Thompson-style trust attack: a compiler that, when building a new compiler, injects itself — and its backdoor — into the output, surviving every recompilation and defeating any inspection of the source.
- The source can be replaced. A build from the wrong repository, the wrong branch, or a tampered checkout produces a clean, correct binary that is not the binary anyone reviewed.
- The toolchain can lie. Build scripts, build containers, and plugin ecosystems can transform one thing into another, and the transformation is invisible unless the build's inputs are recorded.
- The artifact can be swapped after the build. A signed artifact that was never the thing you tested, or a tested artifact that was never the thing you signed.
Every one of these attacks produces a perfectly compiling, perfectly signed, perfectly innocent artifact. The evidence that would catch them is not in the artifact. It is in the process — and the process is what provenance records.
The Layers of Provenance
Provenance is not a single fact. It is a stack of claims, each of which has to be established:
| Layer | Claim | How it's established |
|---|---|---|
| Source | This code came from this repository, this revision | Repository records, commit hashes, signed commits |
| Build | This artifact was produced by this build from those inputs | Build metadata, reproducible builds, attestations |
| Identity | This build was run by this system on behalf of this organization | Build server identity, CI configuration records, audit logs |
| Release | This artifact is what was approved and published | Signatures, release records, distribution manifests |
The frontier property is that each layer's claims are verifiable only if they were recorded at the time. Provenance cannot be reconstructed from a finished binary alone. It must be captured as the artifact travels through its lifecycle — which is why provenance is a build-time practice, not a post-incident investigation.
The Thought Experiment: The Perfectly Clean Backdoor
Thought experiment — the build that never happened
A contractor ships a library to a customer. The library compiles cleanly, passes the customer's scans, carries the contractor's signature, and includes an SBOM listing every dependency. The customer integrates it and ships it inside their product.
Months later, an incident. The forensics team asks the question provenance exists to answer: where did this code come from? The signature checks out. The SBOM checks out. The scans check out. But when the team tries to reproduce the build from the recorded inputs, it cannot — the build requires a step that was never documented, a flag that was never explained, a source file that does not exist in the repository. The artifact is authentic in every verifiable way, and none of the verifiable ways capture how it was actually made.
The investigation reaches a wall that is not a technical wall but a provenance wall: the artifact's history was never recorded, so the artifact's history is unknowable. The clean compile has told the truth and hidden the story simultaneously.
Reproducible Builds: The Archaeology of Trust
The strongest provenance practice available is the reproducible build. A build is reproducible when the same inputs, under the same conditions, produce a byte-identical output — verified by independent parties building independently. Reproducibility converts the claim "this is what the maintainers built" from an assertion into a property that can be checked by anyone, anywhere, at any time.
Reproducible builds are the closest thing software has to an archaeological method. They let a downstream consumer dig up the "fossil" of a release and confirm that it matches what was actually produced from the published source — no trust in the publisher's build process required. The technique has been applied successfully across entire operating system distributions, where every package in the repository is built independently by multiple parties and the results compared. It is slow, it is finicky, and it is the difference between "we believe this binary" and "we verified this binary."
The discipline is not total. Reproducibility verifies that the artifact matches its inputs; it does not independently verify that the inputs are honest. A reproducible backdoor is still a backdoor — but it is a backdoor that can be attributed, reviewed, and defended against with source-level scrutiny, which is where the security community is far more capable than it is at the binary level.
Attestations and the SLSA Framework
Provenance gained a formal language with the arrival of attestations and the Supply-chain Levels for Software Artifacts framework. SLSA is a graduated set of levels describing how strongly a software supply chain can prove its own history: from a basic level where provenance is simply declared, up to levels where the build is scripted, reproducible, isolated, and the provenance itself is generated by a separate system with its own access controls.
The framework matters because it converts "trust the source" into a set of concrete, auditable controls. An artifact with SLSA-provenance attestations carries a machine-readable account of how it was built, signed by the build system itself. Downstream consumers can verify not just the artifact but the credibility of its history. The trend toward "source-to-artifact" attestations — linking the exact commit to the exact build to the exact published artifact — is the practice that turns the provenance stack from theory into deployable evidence.
The Two Provenance Questions
It helps to separate provenance into two questions, because they have different answers and different defenses. The first is the integrity question: does this artifact correspond to the source and build I believe it corresponds to? This is answerable with hashes, signatures, and reproducibility — it is the domain of the practices described throughout this section. The second is the honesty question: was the source itself trustworthy, and were the people who wrote it acting in good faith? No artifact-level evidence answers this. It is a question about humans, incentives, and history, and it can only be approached with context — code review, community reputation, security audits, and the unglamorous record of how a project is actually maintained.
The two questions fail together in the most dangerous way: an artifact can pass the integrity question perfectly while failing the honesty question completely. The clean compile, the valid signature, and the reproducible build all say the artifact is authentic. None of them say it is safe. Provenance security is the discipline of refusing to let the first question's clean answer stand in for the second — of treating the verifiable past as necessary but never sufficient, and keeping the human history of the code as a live part of the trust decision.
Practicing Provenance Without Perfect Records
Most existing systems have no provenance records, and rewriting history is impossible. The practical path is forward-facing:
- Capture provenance from today forward. Every new build should emit a signed attestation recording inputs, process, and output — even if legacy artifacts have no history.
- Prefer reproducible builds for anything critical. The packages that guard your trust deserve the independent-verification treatment.
- Treat the build system as the record keeper. Its logs, its configuration, and its identity are provenance. Protect them like evidence, because that is what they are.
- Assume clean artifacts can lie. Scanning and signing are necessary, but they validate the present; pair them with a provenance question that asks about the past.
- Prepare for the archaeology. Have a plan for reconstructing the history of an artifact after the fact — because the next incident will not announce itself in time to start keeping records.
Key Takeaways
- A clean build proves the code compiles; provenance proves how it got here — the two are not the same question.
- Compilers, sources, toolchains, and post-build swaps can all produce authentic-looking, malicious artifacts.
- Provenance is a stack of claims — source, build, identity, release — that must be recorded at the time they are made.
- Reproducible builds and SLSA attestations turn "we trust the publisher" into independently checkable evidence.
- Provenance is a build-time practice, not an incident-time investigation; you cannot reconstruct a history that was never recorded.
Software is the only artifact in history whose manufacturing record is routinely treated as optional. A bridge carries the name of the engineer who signed its plans. A pharmaceutical carries the record of its production batch. A binary carries a signature, a scan result, and a clean compile — and nothing that says who really made it, or from what. The frontier of supply chain security is the slow, unglamorous work of making software as accountable as its artifact. The tools exist. The history, from today forward, is ours to record.