Dev.to Security 🔐 Cybersecurity 👁 0 📖 4 min read

The Provenance Layer — Or, You Can't Audit What You Can't Rebuild

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 Hack

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 latest is 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.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.