Yesterday was the solvency layer (#63): the vendor holding your switch can run out of money. Today's front page answers the next question down — how do you know what the thing on your machine actually is?
"OpenCode Hacked: User credentials leaked" (743 pts). A tool developers installed, trusted, and ran with their keys ended up handing those keys to someone else. The headline reads like a breach story. The lesson is quieter and much worse: you shipped a binary you never inspected, and you gave it your credentials before you had any evidence it deserved them.
Why this is its own layer
Identity (#61) asked who holds the keys. Solvency (#63) asked whether the keyholder still exists. Provenance asks the question that comes before both: is this artifact the thing I think it is?
Every dependency you add is a claim of provenance. "This npm package is the one the maintainer signed." "This container image is the build from that commit." "This model is the weights the lab published." Almost none of those claims are verified. They're asserted by a registry, a tag, a URL — and you accept them because checking is work and trusting is free.
-
A name is not an identity. Package names get squatted, typosquatted, and transferred. A tag like
latestis a pointer someone else controls. Installing by name is installing by reputation, and reputation is not a hash. - Builds are not reproducible by default. Without a deterministic build you can't prove the binary matches the source, so "open source" becomes a promise about a file you never ran. The source can be auditable and the artifact still be a trojan.
- Credentials are the blast radius, not the breach. The moment a tool runs with your keys, the question stops being "was the tool compromised?" and becomes "what could a stranger do with my keys for the next six months?" Most of us answer that question by changing passwords after the incident, which is the definition of closing the barn door.
- Trust propagates transitively and silently. Your app trusts a library, which trusts a transitive dependency, which trusts a maintainer who stopped paying attention in 2021. You audited one layer; the exploit lives three layers down. This is the concentration problem (#60) wearing a different coat.
The tell: you can't rebuild it from what you were given
Ask of any critical dependency: if the vendor vanished tomorrow, could I rebuild this exact artifact from public inputs and get the same bytes? If the answer is no — and it usually is — then you don't have provenance. You have a relationship.
There's a reason "source code of the Estonian online voting system" (156 pts) keeps showing up in these conversations. Publishing the source is not the point; publishing it so that independent people can rebuild it and compare is the point. Auditability is not a PDF. It's a diff.
What to actually do
-
Pin by digest, not by tag.
image@sha256:..., lockfiles with integrity hashes, model weights by checksum. If you can't name the exact bytes, you can't notice when they change. - Give tools the least authority that still works. Separate keys per tool, scoped and short-lived. Before you install something new, assume it is hostile and ask what it could reach. A tool that needs your whole environment to run a linter is telling you something.
- Run the rebuild test once per quarter. Pick your three load-bearing dependencies and try to reproduce the artifact from source. Failures are your real supply-chain map — far more useful than a security questionnaire.
- Measure before you trust claims. The front page also had "Llmspeed — feel how fast a local LLM runs before you buy the hardware" (248 pts). Same instinct, different domain: benchmark the thing yourself instead of accepting the number on the box.
- Treat deprecations as provenance events. "Chrome and Edge are removing XSLT" (80 pts) is a reminder that the runtime your code depends on can be silently redefined. The artifact didn't change; the ground under it did.
The uncomfortable part
Provenance is expensive. Verification costs time you don't have, which is exactly why the market sells you convenience instead. Every managed layer is a promise that somebody else already did the checking — and that promise is only as good as their incentive to keep doing it after the invoice clears.
That's the layer under the layer. You can hold your identity (#61), survive your vendor's bankruptcy (#63), and still be running somebody else's bytes with your keys in their hands.
The one-line version
Trust is not a property of a name, a tag, or a repository — it's a property of bytes you can rebuild and compare. If you can't reproduce what you're running, you're not auditing your stack; you're auditing your hopes.
Top comments (1)
The rebuild test is the strongest thing here and it is doing something different from the digest pin, which is worth separating because most teams do one and believe they have done both.
A digest answers whether the bytes changed. A rebuild answers whether the bytes ever matched the source. You can pin by sha256 forever and be pinning a trojan with excellent change control.
The reason the rebuild works is the reason reconciliation works in payments. We do not audit a merchant's ledger against itself. We settle it against the bank's statement, which is a record written by a different party for its own reasons, with no interest in making our books look right. An independent rebuild produces a second author for the same artifact. Nothing else in your list does, because every other check reads something the vendor wrote.
Where I would push is the quarterly cadence. A rebuild that passed in July is a statement about July's bytes, and three load-bearing dependencies chosen once is a sample the vendor can learn. If I knew which three you rebuild, I would ship clean ones. The useful version attaches the rebuild to the event rather than the calendar: every version bump of anything that runs with credentials, and nothing on a schedule.
And the result expires. "We reproduced it" with no date next to it is the same claim as "the control is running" with no date next to it.