Trusting what you ship

This site asks for 8 packages by name in its package.json. Installing them puts 346 packages on disk. You chose eight; strangers chose the other 338, and their dependencies chose some of those. Every one runs with your permissions when you build.

That’s what “supply chain” means here: everything between a stranger’s keyboard and your running code, and every place along that path where the code can quietly become something else.

Three times it really happened

The xz one deserves a second read. The repository held the payload only as two innocent-looking binary test files. The line that unpacked them into the build lived in the tarball - the thing people actually installed - and nowhere in the repository. Reviewing the source would not have shown you the switch.

Install day

Five incidents, modelled on the shapes above, against a toy project. Every package name starts with toy- - real names in a lesson about backdoors would accuse real maintainers. Switch controls on and off and read why each one does or doesn’t help.

What each control actually buys

A lockfile with npm ci. package-lock.json records the exact tree that was installed, and for each package an integrity field: a sha512 hash of the artifact. npm ci installs exactly that, and if the lockfile and package.json disagree it exits with an error instead of “fixing” anything. It never writes to either file. So bytes can’t change under you - but the lockfile hashes whatever you had when you locked. Lock a backdoored release and you’ve pinned the backdoor.

Pinning also has a cost you saw in the widget: a lockfile turns “the attacker’s version arrives today” into “arrives at your next routine update”. That’s a delay, not a defence. Security fixes arrive the same slow way, which is the trade-off the tags and digests lesson describes for images.

Dependency review. A person, or a tool such as a dependency-review check on pull requests, looks at every package name that’s new in the diff. It’s the only control here that notices you asked for the wrong thing. It’s blind to bytes changing under a name you already approved.

Provenance and signatures. SLSA defines provenance as a record of “what entity built the artifact, what process they used, and what the inputs were”. Its levels climb from “package has provenance” (easy to forge) to builds where forging it means exploiting a vulnerability. Sigstore makes signing practical without key management: a short-lived certificate is issued for the signer’s OIDC identity, the private key is discarded after one signature, and the record goes into a public append-only log, Rekor. Verifying then means checking that the identity in the certificate is the one you expected - for example, the project’s own release workflow.

Provenance only covers packages that publish it, and most of a real tree doesn’t yet. And it proves where something came from, not that it’s good: a typosquat can have flawless provenance from the attacker’s own repository.

An SBOM - a software bill of materials - blocks nothing. It’s the list of what’s inside each thing you ship. Its value shows on the morning a new vulnerability is announced: with SBOMs you can answer “are we affected?” by searching, instead of by guessing. That’s the same job the Trivy scanner does continuously in the policy and scanning lesson.

npm ci                  # refuses to "fix" a lockfile that disagrees with package.json
npm audit signatures    # verifies registry signatures and provenance attestations

kubectl get pods -A -o jsonpath='{range .items[*].spec.containers[*]}{.image}{"\n"}{end}' | sort -u > images.txt
wc -l < images.txt                  # distinct images
grep -c '@sha256:' images.txt       # pinned by digest